| Term | Definition |
|---|---|
| A2A (administration To Administration) | A2A refers to interactions between public administrations, such as those between Member States or EU Institutions. |
| A2A (administration To Administration) USE 1 | The section uses A2A to describe one of three types of interactions covered by the EIF's scope, referring to interactions between public administrations such as Member States or EU Institutions, which is consistent with the definition. |
| A2B (administration To Business) | A2B refers to interactions between public administrations (in a Member State or an EU Institution) and businesses. |
| A2B (administration To Business) USE 1 | The section uses A2B to describe one of three types of interactions covered by the EIF's scope, referring to interactions between public administrations and businesses, which is consistent with the definition. |
| A2C (administration To Citizen) | A2C refers to interactions between public administrations (in a Member State or an EU institution) and citizens. |
| A2C (administration To Citizen) USE 1 | The section uses A2C to describe one of three types of interactions covered by the EIF's scope, referring to interactions between public administrations and citizens, which is consistent with the definition. |
| Accessibility | Accessibility ensures that people with disabilities, the elderly and other disadvantaged groups can use public services at service levels comparable to those provided to other citizens. It must be part of the whole development lifecycle of a European public service and should comply with e-accessibility specifications widely recognised at European or international level. |
| Accessibility USE 1 | The section mentions an 'Accessibility statement' as a help resource, which is consistent with the principle of ensuring people with disabilities and disadvantaged groups can use public services, but does not add new information about the concept. |
| Accessibility USE 2 | The section uses accessibility in a manner fully consistent with its definition, restating that it ensures people with disabilities, the elderly and other disadvantaged groups can use public services at comparable levels, and that it must be part of the whole development lifecycle and comply with e-accessibility specifications. |
| Accessibility USE 3 | The section mentions that preserved records must be accessible as long as needed, which is consistent with the general concept of accessibility but does not add information specific to the definition's focus on disadvantaged groups. |
| Accessibility USE 4 | The section includes an 'Accessibility statement' link, which is consistent with the principle of ensuring people with disabilities and disadvantaged groups can use public services, but does not add new information about accessibility beyond its presence as a feature. |
| Accessibility USE 5 | The section mentions ensuring the accessibility of data by authorised users as part of the information steward's responsibilities, consistent with the definition though focused on authorized access rather than accessibility for disadvantaged groups. |
| Accessibility USE 6 | The section includes a link to an 'Accessibility statement', indicating that accessibility is being addressed in the portal, consistent with the principle that accessibility must be part of public service development. |
| Accessibility USE 7 | The section includes a link to an 'Accessibility statement', which is consistent with the concept of accessibility for people with disabilities and disadvantaged groups, but does not provide new information beyond acknowledging its presence. |
| Accessibility USE 8 | The section includes a link to an 'Accessibility statement', which is consistent with the concept of accessibility ensuring people with disabilities can use public services, but does not add new information beyond acknowledging its presence. |
| Administrative Simplification | Administrative simplification is the process by which public administrations streamline and simplify their administrative processes by improving them or eliminating any that does not provide public value. It helps businesses and citizens to reduce the administrative burden of complying with EU legislation or national obligations. |
| Administrative Simplification USE 1 | The section restates the definition of administrative simplification, explaining that public administrations should streamline processes, eliminate those without public value, and reduce administrative burden, without adding substantive new information. |
| Authoritative Data | Authoritative data is validated and managed information under the aegis of public authorities. It includes master data from base registries and other types of data that can be reused by public administrations. |
| Authoritative Data USE 1 | The section describes base registries as authoritative sources of information that are validated and managed, consistent with the definition of authoritative data. |
| Authoritative Data USE 2 | The section mentions authoritative data as validated and managed under the aegis of public authorities, consistent with the definition, without adding new information. |
| Authoritative Source | An authoritative source is a base registry that is considered to be the 'source' of information, meaning it shows the correct status, is up-to-date and is of the highest possible quality and integrity. It is the definitive reference point for specific types of data. |
| Authoritative Source USE 1 | The section describes authoritative sources as showing the correct status, being up-to-date and of the highest possible quality and integrity, which matches the definition. |
| Authoritative Source USE 2 | The section refers to 'authoritative sources of information' including base registries and other types of authoritative data, consistent with the definition. |
| Back-up And Recovery Plans | Back-up and recovery plans are procedures needed for functions to operate after a disastrous event and bring all functions back to normal the earliest possible. |
| Back-up And Recovery Plans USE 1 | The section describes back-up and recovery plans as procedures needed for functions to operate after a disastrous event and bring all functions back to normal the earliest possible, which matches the definition. |
| Base Registries | Base registries are authoritative sources that contain master data used by multiple applications and systems. They are a type of information source that public administrations store and that has potential for reuse. |
| Base Registry | A base registry is a trusted and authoritative source of information which can and should be digitally reused by others, where one organisation is responsible and accountable for the collection, use, updating and preservation of information. Base registries are reliable sources of basic information on data items such as people, companies, vehicles, licences, buildings, locations and roads, constituting the 'master data' for public administrations and European public service delivery. |
| Base Registry Framework | A base registry framework describes the agreements and infrastructure for operating base registries and the relationships with other entities. It provides the organizational and technical structure for how base registries function and interact. |
| Base Registry Framework USE 1 | The section quotes the definition directly, stating that a base registry framework 'describes the agreements and infrastructure for operating base registries and the relationships with other entities'. |
| Base Registry USE 1 | The section provides extensive detail about base registries, adding important distinctions between centralized and distributed registries, specifying organizational accountability requirements, introducing data quality assurance plans, and establishing citizen rights to check data accuracy—all of which extend beyond the basic definition. |
| Base Registry USE 2 | The section mentions base registries as authoritative sources of information and master data used by multiple applications, consistent with the definition. |
| Boundaryless Information Flow USE 1 | The section states that 'data and related services flow unimpeded, yet securely, across the IT landscape' and mentions 'a full view of all the information flowing through an organization,' which aligns with the concept of seamless information exchange across boundaries, though it doesn't explicitly use the term or add new information beyond what the definition implies. |
| Boundaryless Information Flow USE 2 | The section describes practical implementation of seamless information exchange through automated data management tools that sync automatically and unify data formats, extending the concept to include considerations about one-way versus two-way communication flows and real-time versus action-triggered synchronization. |
| Boundaryless Information Flow USE 3 | The section discusses data flows between systems and data democratization enabling access across the organization, but uses these concepts in a general operational sense rather than as the specific mission concept and trademark focused on collaborative standards development for seamless cross-boundary information exchange. |
| Building Blocks | Building blocks are information sources and services that can be used to create integrated public services. They should make their data or functionality accessible using service-oriented approaches and exhibit native capability of being combined ('interoperability by design') to be ready for mash-up in different environments with minimum customisation. |
| Building Blocks USE 1 | The section identifies building blocks as information sources (base registries, open data portals, and other authoritative sources) and services that should be aggregated to form integrated service provision processes, and emphasizes they should exhibit native capability of being combined with minimum customisation. |
| Building Blocks USE 2 | The section states that building blocks should be governed to ensure integration, seamless execution, reuse of services and data, and development of new services, and that governance should impose requirements for quality, scalability and availability of reusable building blocks including information sources. |
| Business Continuity Plans | Business continuity plans are procedures needed for functions to operate after a disastrous event and bring all functions back to normal the earliest possible. |
| Business Continuity Plans USE 1 | The section describes business continuity plans as procedures needed for functions to operate after a disastrous event and bring all functions back to normal the earliest possible, which matches the definition. |
| Business Process Alignment | Business process alignment is the process by which different administrative entities align their existing business processes or define and establish new ones to work together efficiently and effectively to provide European public services. It implies documenting processes in an agreed way with commonly accepted modelling techniques, including the associated information exchanged, so that all contributing public administrations can understand the overall end-to-end business process and their role in it. |
| Business Process Alignment USE 1 | The section restates the definition of business process alignment, explaining that administrative entities need to align existing or establish new business processes, document them using agreed modelling techniques, and ensure all contributing administrations understand the end-to-end process and their role. |
| Business Process Alignment USE 2 | The section refers to interconnected business processes as part of service provision, which aligns with the definition's concept of aligning processes to work together efficiently. |
| Business Process Alignment USE 3 | The section mentions documenting and integrating or aligning business processes, which is consistent with the definition of business process alignment, though it does not elaborate beyond what the definition implies. |
| Business Process Alignment USE 4 | The section refers to 'business processes' that need to be addressed in governance and mentions 'organisation business processes' as part of ensuring interoperability, consistent with the definition. |
| Business Process Alignment USE 5 | The section mentions incompatible business processes as one of the considerable barriers that administrations face, and alignment of business processes as an issue to be addressed, which adds information about current challenges. |
| Catalogues | Catalogues are resources that help others to find reusable resources such as services, data, software, and data models. Various types of catalogue exist, including directories of services, libraries of software components, open data portals, registries of base registries, metadata catalogues, and catalogues of standards, specifications and guidelines. Commonly agreed descriptions of the services, data, registries and interoperable solutions published in catalogues are needed to enable interoperability between catalogues. |
| Catalogues USE 1 | The section defines catalogues and provides examples of their types, which is consistent with the definition but does not add new information beyond what the definition already states. |
| Catalogues USE 2 | The section mentions catalogues describing reusable services and other assets to increase their findability and usage, which is consistent with the definition of catalogues as resources that help others find reusable resources. |
| Catalogues USE 3 | The section introduces the concept of a 'registry of registries' as important for administrations to obtain a high level overview of base registries and their data, adding a specific type of catalogue not explicitly mentioned in the general definition. |
| Catalogues USE 4 | The section indicates that catalogues are used during the planning phase to identify needed services and information sources, which adds new information about the practical application of catalogues in the service provision process. |
| Catalogues USE 5 | The section refers to catalogues of standards, specifications and guidelines at national and EU level that should be consulted, which is consistent with the definition of catalogues as resources for finding reusable resources. |
| Change Management | Change management is a set of processes and procedures included in interoperability agreements to ensure the accuracy, reliability, continuity and evolution of services delivered to other public administrations, businesses and citizens. A change management plan defines the procedures and processes needed to deal with and control changes in the environment, such as changes in legislation, needs of businesses or citizens, organisational structure, business processes, and emergence of new technologies. |
| Change Management USE 1 | The section describes change management processes as critical components to include in interoperability agreements to ensure accuracy, reliability, continuity and evolution of services, which aligns with the definition. |
| Change Management USE 2 | The section states that governance should include 'a change management plan, to define the procedures and processes needed to deal with and control changes,' consistent with the definition. |
| Checksum USE 1 | The section describes 'data validation and quality assurance' processes that check for 'errors, inconsistencies and data integrity issues,' which aligns with the checksum's purpose of validating message veracity and protecting integrity, though it does not specifically mention checksums as a technique. |
| Cloud Computing Interoperability USE 1 | The section describes various cloud services and products that work together within Google Cloud's ecosystem, consistent with the concept of cloud components interfacing and working together, though it focuses on Google Cloud's own interoperability rather than cross-cloud interoperability. |
| Cloud Computing Interoperability USE 10 | The section mentions that data integration and application integration are 'both cloud-based' and references 'benefits of cloud computing,' but uses these terms in a general descriptive sense rather than in relation to the interoperability concept of enabling different cloud components to interface and work together seamlessly across different cloud environments. |
| Cloud Computing Interoperability USE 11 | Data Cloud unlocks and harmonizes data from any system, which is consistent with the ability to interface and work together seamlessly across different environments. |
| Cloud Computing Interoperability USE 12 | The section discusses connecting systems and unifying data in a cloud environment (Data Cloud), which is consistent with the definition's concept of components working together seamlessly in cloud environments, but does not add new information about cloud computing interoperability itself. |
| Cloud Computing Interoperability USE 13 | The section describes iPaaS solutions as cloud-based data integration services used for hybrid cloud integration and connecting applications, which is consistent with the definition's description of cloud components interfacing and working together seamlessly across different cloud environments. |
| Cloud Computing Interoperability USE 2 | The section describes Google Cloud's data integration services that enable different components and services to work together, which is consistent with the definition of cloud computing interoperability as the ability of cloud-hosted components to interface and work together seamlessly. |
| Cloud Computing Interoperability USE 3 | The section discusses data integration as enabling cloud migration and business continuity through various tools (data transfer services, connectors, CDC tools, ETL tools), which is a specific application of Cloud Computing Interoperability. This adds the new insight that interoperability is essential for smooth cloud transitions and maintaining operational continuity during migration. |
| Cloud Computing Interoperability USE 4 | The section discusses data integration, which involves combining data from different sources and formats, but does not address the ability of cloud-hosted components to interface and work together across different cloud environments, which is what Cloud Computing Interoperability specifically refers to. |
| Cloud Computing Interoperability USE 5 | The section adds new information by specifying that data integration tools should have 'cloud capability for all levels' as a desirable feature, which extends the definition by suggesting that cloud interoperability should be accessible across different organizational or technical levels, not just between cloud components. |
| Cloud Computing Interoperability USE 6 | The section demonstrates Cloud Computing Interoperability through Informatica's pre-built cloud-native connectivity that enables integration across multi-cloud and on-premises environments, and through its consumption-driven platform that allows choosing cloud services as business requirements change, illustrating practical implementation of seamless interfacing across different cloud environments. |
| Cloud Computing Interoperability USE 7 | The section discusses 'cloud data integration' and 'multi-cloud and hybrid cloud environments' but focuses on bringing data together into a single destination rather than on the ability of cloud-hosted components to interface and work together seamlessly across different cloud environments. |
| Cloud Computing Interoperability USE 8 | The section demonstrates that cloud computing interoperability enables organizations to integrate data from multiple disparate sources (on-premises and cloud systems like Salesforce, SQL Server, Workday, CRM environments, financial tools) into unified cloud platforms (Snowflake, Google Cloud, Azure), allowing seamless data exchange and analysis across different infrastructures through cloud data integration tools and connectors. |
| Cloud Computing Interoperability USE 9 | The section mentions 'cloud' and 'cloud data integration solutions' in the context of financial services, but this refers to using cloud platforms for data integration rather than the ability of cloud-hosted components to interface across different cloud environments. |
| Compliance Monitoring | Compliance monitoring is the process of checking and verifying adherence to selected standards and specifications as part of their ongoing management and implementation. |
| Compliance Monitoring USE 1 | The section mentions monitoring compliance with standards and specifications as the fourth step in the management process, which is consistent with the definition but adds no new information beyond what is implied. |
| Conceptual Model For Integrated Public Services | The conceptual model for integrated public services is a framework to guide the planning, development, operation and maintenance of public services by Member States. The model is modular and comprises loosely coupled service components interconnected through shared infrastructure. It is relevant to all governmental levels, from local to EU, and is intended to be used when designing new services or reengineering existing ones. |
| Conceptual Model For Integrated Public Services USE 1 | The section introduces and describes the conceptual model for integrated public services, stating it guides planning, development, operation and maintenance, is modular with loosely coupled components, and is relevant to all governmental levels, which directly restates the definition. |
| Conceptual Model For Integrated Public Services USE 2 | The section describes a 'conceptual model' that features reuse of services and information, and mentions mapping solutions against conceptual building blocks of a reference architecture, providing specific implementation details about how the model operates. |
| Conceptual Model For Integrated Public Services USE 3 | The section title references the conceptual model for integrated public services provision, consistent with the definition's description of it as a framework for guiding public service planning, development, operation and maintenance. |
| Conceptual Model For Integrated Public Services USE 4 | The section title references the conceptual model for integrated public services provision, indicating this is the topic being discussed, consistent with its definition as a framework for guiding public service development. |
| Conceptual Model For Integrated Public Services USE 5 | The section references the conceptual model for public services as the basis for service orientation, consistent with the definition's purpose of guiding service planning and development. |
| Conceptual Model For Integrated Public Services USE 6 | The section states that the EIF conceptual model for public services covers the design, planning, development, operation and maintenance of integrated public services at all governmental levels from local to EU level, which is consistent with the definition. |
| Conceptual Model For Integrated Public Services USE 7 | Chapter 4 outlines a conceptual model for interoperable public services, which aligns with the definition as a framework to guide planning, development, operation and maintenance of public services. |
| Coordination Function | The coordination function ensures that needs are identified and appropriate services are invoked and orchestrated to provide a European public service. This function should select the appropriate sources and services and integrate them, and coordination can be automated or manual. |
| Coordination Function USE 1 | The section refers to a coordination function as the basis for integrated service delivery to remove complexity for the end-user, which is consistent with the definition. |
| Coordination Function USE 2 | The section restates the definition of the coordination function and lists the process phases it executes, which is consistent with but does not add new information beyond the definition. |
| Coordination Function USE 3 | The section mentions 'coordination and governance by the authorities with a mandate for planning, implementing and operating European public services,' consistent with the coordination function definition. |
| Cross-border-by-default | Cross-border-by-default means making services accessible for all citizens in the EU. This principle ensures that European public services are designed to function seamlessly across national boundaries. |
| Cross-border-by-default USE 1 | The section mentions cross-border actions in the context of agreements between administrations, but uses 'cross-border' in a general sense rather than referring to the principle of making services accessible for all EU citizens by default. |
| Cross-border-by-default USE 2 | The section describes European public service as having 'a cross-border dimension,' which is consistent with the definition's concept of making services accessible across the EU, though it does not add new information beyond what the definition implies. |
| Cross-border-by-default USE 3 | The section uses 'cross-border-by-default' as one of three design principles, defining it parenthetically as 'accessible for all citizens in the EU,' which is consistent with the given definition. |
| DIFs | DIFs (Domain Interoperability Frameworks) are domain-specific frameworks that should be consulted, along with the NIF, when procuring and developing ICT solutions to ensure proper selection of standards and specifications. |
| DIFs USE 1 | The section states that EU standards and specifications exist in the DIFs and should be applied more widely, and provides the INSPIRE Directive as an example of standards that can be used beyond their original domain, adding specificity about their broader application potential. |
| DIFs USE 2 | The section recommends consulting relevant DIFs when procuring and developing ICT solutions, which aligns precisely with the definition. |
| DIFs USE 3 | The section describes the relationship between EIF and DIFs, explaining that DIFs should remain compatible with and extend the EIF scope, and that some EIF elements can be directly copied while others need contextualisation for domain-specific needs. |
| Data Access And Authorisation Plan | A data access and authorisation plan is a document which determines who has access to what data and under what conditions, to ensure privacy. It requires that unauthorised access and security breaches should be monitored and appropriate actions should be taken to prevent any recurrence of breaches. |
| Data Access And Authorisation Plan USE 1 | The section describes a data access and authorisation plan as determining who has access to what data and under what conditions to ensure privacy, and states that unauthorised access and security breaches should be monitored with appropriate actions taken to prevent recurrence, which matches the definition. |
| Data Portability | Data portability is the ability to move and reuse data easily among different applications and systems. It requires data to be easily transferable among different systems to avoid lock-in and support the free movement of data. |
| Data Portability USE 1 | The section restates that data portability is the ability to move and reuse data easily among different applications and systems, and emphasizes its importance in cross-border scenarios and avoiding lock-in. |
| Data Portability USE 2 | The section states that unless standardisation efforts mature in the semantic interoperability layer, it is difficult to ensure data portability among Member States, indicating that semantic interoperability is a prerequisite for achieving data portability. |
| Digital Check | A digital check is an assessment that proposed legislation should undergo to ensure that it suits not only the physical but also the digital world (e.g. the internet), to identify any barriers to digital exchange, and to identify and assess its ICT impact on stakeholders. |
| Digital Check USE 1 | The section describes a digital check as an assessment of proposed legislation to ensure it suits the digital world, identifies barriers to digital exchange, and assesses ICT impact, which is consistent with the definition. |
| Digital Fragmentation | Digital fragmentation is the creation of isolated digital environments and electronic barriers that may prevent public administrations from connecting with each other, and citizens and businesses from identifying and using available digital public services in countries other than their own. |
| Digital Fragmentation USE 1 | The section uses the concept of digital fragmentation by warning that Member States risk creating isolated digital environments and electronic barriers when digitizing their public sectors, which aligns with the definition without adding new information. |
| Digital Public Services | Digital public services are modernized electronic services introduced by Member States to make interactions with public administrations efficient, effective, timely and of high quality, helping to cut red-tape and reduce the cost and effort involved in citizen and business interactions with government. |
| Digital Public Services USE 1 | The section mentions digitisation of public services and using electronic means for interactions, which is consistent with the definition's focus on modernized electronic services but does not add new information about their benefits or characteristics. |
| Digital Public Services USE 2 | The section mentions catalogues of public services, which relates to digital public services, but does not provide new information about digital public services themselves. |
| Digital Public Services USE 3 | The section discusses security and privacy as primary concerns in the provision of public services, adding specific requirements about how these services must be secured, protected from attacks, and compliant with legal requirements, which provides new context about the security aspects of digital public services. |
| Digital Public Services USE 4 | The section discusses 'public services' and 'integrated public services' but does not specifically address the digital or modernization aspects that characterize digital public services. |
| Digital Public Services USE 5 | The section states that the interoperability model 'is applicable to all digital public services', confirming that digital public services are the target domain for the interoperability framework. |
| Digital Public Services USE 6 | The section discusses governance to ensure business continuity of 'digital public services and their building blocks,' consistent with the definition. |
| Digital Public Services USE 7 | The section refers to interoperable digital public services at regional, national and EU level, which is consistent with the definition of digital public services as modernized electronic services. |
| Digital Public Services USE 8 | The section refers to 'European public services' and 'public services' throughout, which are consistent with the concept of digital public services being provided by public administrations. |
| Digital Public Services USE 9 | The section explains that Member States are introducing digital public services to modernize their public administrations and make interactions efficient, effective, timely and of high quality, adding the specific goal of helping cut red-tape and reduce cost and effort for citizens and businesses interacting with public administrations. |
| Digital Single Market | The digital single market is a strategy intended to ensure effective communication between digital components such as devices, networks and data repositories, and to provide more efficient connections across borders, between communities and between public services and authorities. |
| Digital Single Market | The digital single market is a goal that requires interoperability as a prerequisite for its achievement. It represents the vision of enabling seamless electronic services and communication across European public administrations at regional, national and EU level. |
| Digital Single Market USE 1 | The section mentions that reusability makes it a major contributor to the development of a digital single market in the EU, consistent with the definition's focus on seamless electronic services across borders. |
| Digital Single Market USE 2 | The section identifies that differences in policies resulting in heterogeneity and lack of interoperability put the digital single market at risk, establishing a threat relationship. |
| Digital Single Market USE 3 | The section adds that the functioning of the digital single market specifically requires data to be easily transferable among different systems to avoid lock-in and support the free movement of data, linking it directly to data portability requirements. |
| Digital Single Market USE 4 | The section indicates that semantic interoperability standardisation is necessary to support a digital single market in the EU, and that without it, seamless information exchange and free movement of data among Member States cannot be ensured. |
| Digital Single Market USE 5 | The section mentions that interoperability is a prerequisite for achieving a digital single market, which is consistent with the definition that the Digital Single Market requires interoperability. |
| Digital Single Market USE 6 | The section states that the EIF contributes to establishing the digital single market by fostering cross-border and cross-sectoral interoperability, and identifies lack of interoperability as a major obstacle to progress on the digital single market, adding new context about barriers and the EIF's role. |
| Digital Single Market USE 7 | The section mentions that the end result is supporting a digital single market in Europe through seamless information flow across borders, which is consistent with the definition. |
| Digital Single Market USE 8 | The section states that the digital single market strategy is intended to ensure effective communication between digital components and provide more efficient connections across borders, between communities and between public services and authorities, adding that interoperable systems are set up to support this strategy. |
| Digital-by-default | Digital-by-default is an approach to providing services and data preferably via digital channels. This principle guides the design and delivery of European public services to maximize digital accessibility. |
| Digital-by-default | Digital-by-default is a concept where there is at least one digital channel available for accessing and using a given European public service, whenever appropriate. |
| Digital-first | Digital-first is a concept that means priority is given to using public services via digital channels while applying the multi-channel delivery concept and the no-wrong-door policy, where physical and digital channels co-exist. |
| Digital-first USE 1 | The section defines digital-first as prioritizing digital channels while applying multi-channel delivery and no-wrong-door policy, which is consistent with the definition's description of prioritizing digital channels while maintaining physical channels. |
| Digital-first USE 2 | The section mentions securing the availability of digital channels (digital-by-default) as part of the no wrong door policy, which is consistent with the digital-first approach of prioritizing digital channels while maintaining alternatives. |
| Digital-first USE 3 | The section uses the similar term 'digital-by-default' to describe services that are 'providing services and data preferably via digital channels,' which aligns with the digital-first definition's prioritization of digital channels as the preferred means of service delivery. |
| Domain-specific Interoperability Frameworks (DIFs) | Domain-specific interoperability frameworks are frameworks that remain compatible with and extend the scope of the EIF to capture the specific interoperability requirements of a particular domain. DIFs address domain-specific needs while maintaining alignment with the core principles of the European Interoperability Framework. |
| Domain-specific Interoperability Frameworks (DIFs) USE 1 | The section provides the INSPIRE Directive as an important domain-specific illustration of an interoperability framework including legal interoperability, coordination structures and technical interoperability arrangements. |
| Domain-specific Interoperability Frameworks (DIFs) USE 2 | The section explains that DIFs should remain compatible with and extend the scope of the EIF to capture specific interoperability requirements of the domain, and that compliance with the EIF guarantees DIFs are developed in a coordinated way while addressing domain-specific requirements. |
| EIF (European Interoperability Framework) | The EIF is a key instrument that promotes electronic communication among European public administrations by providing a set of common models, principles and recommendations. It identifies four layers of interoperability challenges (legal, organisational, semantic and technical) and points out the essential role of governance to ensure coordination of relevant activities across all levels and sectors of administration. |
| EIRA | EIRA is a framework to which standards and specifications can be mapped within the European interoperability cartography. |
| EIRA USE 1 | The section mentions the European interoperability architecture (EIRA) as an important part of interoperability governance at the EU level, consistent with its role as a framework. |
| EIRA USE 2 | The section states that standards and specifications can be mapped to the EIRA, which is consistent with the definition but does not add new information. |
| European Interoperability Cartography | The European interoperability cartography (EIC) is a specific kind of catalogue of interoperability solutions available for reuse and sharing. |
| European Interoperability Cartography (EIC) | The European interoperability cartography (EIC) is a catalogue system where standards and specifications can be mapped to the EIRA and catalogued for reference and use. |
| European Interoperability Cartography (EIC) USE 1 | The section identifies the EIC as a specific kind of catalogue, which adds new information by positioning it within the broader category of catalogues and clarifying its relationship to other catalogue types. |
| European Interoperability Cartography (EIC) USE 2 | The section introduces the concept of 'cartography of solutions' that maps solutions and their building blocks against a reference architecture for reuse, which appears to be a practical application or instance of the EIC concept. |
| European Interoperability Cartography (EIC) USE 3 | The section mentions that standards and specifications can be catalogued in the EIC, which is consistent with the definition of EIC as a catalogue system. |
| European Interoperability Framework | The European interoperability framework is a commonly agreed approach to the delivery of European public services in an interoperable manner. It defines basic interoperability guidelines in the form of common principles, models and recommendations. |
| European Interoperability Framework | The European interoperability framework is an important part of interoperability governance at the EU level. It works together with the Interoperability Action Plan and the European interoperability architecture (EIRA) to provide governance structures for interoperability. |
| European Interoperability Framework (EIF) | The European Interoperability Framework is a guidance framework that provides recommendations to public administrations on how to improve governance of their interoperability activities, establish cross-organisational relationships, streamline processes supporting end-to-end digital services, and ensure that existing and new legislation do not compromise interoperability efforts. |
| European Interoperability Framework (EIF) | The European Interoperability Framework is the 'common denominator' of interoperability policies in Member States. It is envisaged as a European framework justified to overcome differences in policies that result in heterogeneity and lack of interoperability and that put at risk the digital single market. |
| European Interoperability Framework USE 1 | The section references the European Interoperability Framework through the mention of 'EIF Solutions Finder', indicating its use as a tool or resource, which is consistent with the framework's purpose of providing guidance for interoperable digital public services. |
| European Interoperability Framework USE 10 | The section references the European Interoperability Framework through the mention of 'EIF Solutions Finder', indicating its use as a tool or resource, which is consistent with the framework's purpose of providing guidance for interoperable digital public services. |
| European Interoperability Framework USE 11 | The section describes the revised EIF as a key instrument for establishing interoperable digital public services at regional, national and EU level, thereby contributing to making the digital single market a reality, which adds information about its instrumental role and strategic importance. |
| European Interoperability Framework USE 12 | The section references the European Interoperability Framework through the mention of 'EIF Solutions Finder', indicating its use as a tool or resource, which is consistent with the framework's purpose of providing guidance for interoperable digital public services. |
| European Interoperability Framework USE 13 | The section references 'the EIF' (European Interoperability Framework) as the context for defining interoperability, which is consistent with the definition that describes EIF as providing guidance and recommendations, but does not add new information about the framework itself. |
| European Interoperability Framework USE 14 | The section describes the EIF's content and structure, consistent with its definition as a guidance framework providing recommendations, principles, and models. |
| European Interoperability Framework USE 15 | The section states that the EIF's scope covers three specific types of interactions (A2A, A2B, and A2C), which adds new information about the framework's scope beyond what is stated in the definition. |
| European Interoperability Framework USE 16 | The section describes the European interoperability framework as a commonly agreed approach to delivering European public services in an interoperable manner, defining basic interoperability guidelines through common principles, models and recommendations, which is consistent with the definition. |
| European Interoperability Framework USE 17 | The section describes the EIF's specific purposes (inspiring public administrations, providing guidance on NIFs, contributing to the digital single market) and its legal basis in EU Treaty articles, adding new information about its operational role and legal foundation. |
| European Interoperability Framework USE 18 | The section explains that the EIF is a generic framework applicable to all EU public administrations, acts as a common denominator for initiatives at all levels, provides a common core of interoperability elements to NIFs and DIFs, and provides value in both bottom-up and top-down directions for creating interoperability conditions. |
| European Interoperability Framework USE 19 | The section states that the EIF gives guidance through recommendations to public administrations on improving governance of interoperability activities, establishing cross-organizational relationships, streamlining processes supporting end-to-end digital services, and ensuring that legislation does not compromise interoperability efforts, adding specific areas of guidance beyond the general definition. |
| European Interoperability Framework USE 2 | The section refers to the EIF and its twelve underlying principles, which is consistent with the definition of the EIF as a guidance framework, but does not add substantive new information beyond what is implied. |
| European Interoperability Framework USE 20 | The section title explicitly references the 'European Interoperability Framework' as an introduction topic, and the portal structure reflects the framework's components (Policy, Solutions, Governance, Academy), but does not provide new information about what the EIF is or does beyond its organizational structure. |
| European Interoperability Framework USE 3 | The section references the EIF's underlying principle on reusability and discusses openness as a principle within the EIF context. |
| European Interoperability Framework USE 4 | The section explicitly states it is discussing transparency 'in the EIF context,' indicating this is part of the European Interoperability Framework's guidance. |
| European Interoperability Framework USE 5 | The section characterizes the EIF as the 'common denominator' of interoperability policies in Member States and specifies that NIFs should be aligned with the EIF while being tailored and extended to address national specificities. |
| European Interoperability Framework USE 6 | The section references the European Interoperability Framework through the mention of 'EIF Solutions Finder', indicating its use as a tool or resource, which is consistent with the framework's purpose of providing guidance for interoperable digital public services. |
| European Interoperability Framework USE 7 | The section references the European Interoperability Framework through the mention of 'EIF Solutions Finder', indicating its use as a tool or resource, which is consistent with the framework's purpose of providing guidance for interoperable digital public services. |
| European Interoperability Framework USE 8 | The section is part of the EIF document itself, presenting semantic interoperability as one of the layers addressed by the framework, consistent with the definition that the EIF addresses four layers including semantic interoperability. |
| European Interoperability Framework USE 9 | The section identifies the European interoperability framework as an important part of interoperability governance at the EU level, consistent with its role as guidance for delivering interoperable digital public services. |
| European Public Service | A European public service comprises any public sector service exposed to a cross-border dimension and supplied by public administrations, either to one another or to businesses and citizens in the Union. These services are designed to operate across national boundaries within the European Union. |
| European Public Service | A European public service is a service provided from digital channels that is meant to be accessible across Member States. These services require interoperability between public administrations operating under different legal frameworks and require consideration of ICT as early as possible in the law-making process. |
| European Public Service USE 1 | The section refers to 'European public services' being designed and implemented, which is consistent with the definition of services operating across national boundaries, but does not provide new information about the concept. |
| European Public Service USE 10 | The section refers to 'European public services' in the context of establishing and maintaining them through common infrastructure and interconnected service components, consistent with the definition. |
| European Public Service USE 11 | The section describes base registries as the cornerstone of European public service delivery and mentions master data for European public service delivery, consistent with the definition. |
| European Public Service USE 12 | The section mentions that the coordination function provides a European public service, which is consistent with the definition but does not add new information about what constitutes such a service. |
| European Public Service USE 13 | The section uses the term 'European public services' in Recommendation 45, advising their development using external information sources and services, which is consistent with the definition but does not add new information about what European public services are. |
| European Public Service USE 14 | The section refers to 'European public services' as the context for applying the interoperability model, consistent with the definition of services operating across national boundaries. |
| European Public Service USE 15 | The section refers to European public services being provided from digital channels and requiring consideration of legal frameworks across Member States, consistent with the definition. |
| European Public Service USE 16 | The section mentions establishing European public services in the context of using open specifications for technical interoperability, consistent with the definition of cross-border public services. |
| European Public Service USE 17 | The section refers to European public services operating in a complex and changing environment and mentions that implementation and delivery of a given European public service often relies on common components. |
| European Public Service USE 18 | The section refers to European public services as the outcome that business process alignment enables administrative entities to deliver efficiently and effectively. |
| European Public Service USE 19 | The section refers to providing European public services as the aim of interoperability agreements and describes delivering such services as collective work, consistent with the definition of services operating across boundaries. |
| European Public Service USE 2 | The section refers to European public services in the context of introducing new services using open specifications and delivering services with openness principles. |
| European Public Service USE 20 | The section adds that for cross-border actions (which are characteristic of European public services), multilateral or global European agreements are preferable, providing specific guidance on the type of agreements needed. |
| European Public Service USE 21 | The section discusses 'European public services' and their governance requirements, consistent with the definition. |
| European Public Service USE 22 | The section refers to establishing interoperable European public services and providing fully fledged public services, which is consistent with the definition. |
| European Public Service USE 23 | The section mentions 'European public services' in the context of interoperability principles and design, consistent with the definition of services operating across national boundaries, but does not add new information about what constitutes such services. |
| European Public Service USE 24 | The section provides a broader definition that includes services supplied 'either to one another or to businesses and citizens in the Union,' explicitly mentioning the three types of recipients, whereas the given definition focuses on services 'provided through digital channels' and emphasizes design principles like multilingualism and security. |
| European Public Service USE 25 | The section refers to European public services as the subject of interoperable delivery, consistent with the definition's description of services operating across national boundaries within the EU. |
| European Public Service USE 26 | The section describes European public services as being 'seamless' and designed with principles of digital-by-default, cross-border-by-default, and open-by-default, adding new design characteristics beyond the basic definition. |
| European Public Service USE 27 | The section describes European public services as being designed, developed and delivered with interoperability requirements in mind, and explains that the EIF creates conditions for extending their scope across borders and developing a European public services ecosystem. |
| European Public Service USE 28 | The section refers to digital public services that citizens and businesses need to identify and use in countries other than their own, and mentions end-to-end digital services, adding the context that these services require coordination at European and national levels to avoid fragmentation and support the digital single market. |
| European Public Service USE 3 | The section's recommendations refer to implementing European public services through reuse and sharing of solutions and information, consistent with the definition of services operating across national boundaries. |
| European Public Service USE 4 | The section mentions European public services in Recommendation 5, which calls for ensuring internal visibility and providing external interfaces for them, consistent with the definition. |
| European Public Service USE 5 | The section elaborates on European public services by explaining how multilingualism should be implemented in practice, including balancing citizen expectations with administrative capacity and basing language support on user needs and service criticality. |
| European Public Service USE 6 | The section refers to European public services as the context for inclusion and accessibility requirements, consistent with the definition's scope of public sector services operating across the EU. |
| European Public Service USE 7 | The section mentions that public administrations should introduce European public services supported by electronic means, consistent with the definition but without adding new information about their characteristics or requirements. |
| European Public Service USE 8 | The section refers to European public services in the context of evaluating their effectiveness and efficiency, consistent with the definition of services operating across national boundaries. |
| European Public Service USE 9 | The section adds that when establishing European public services, public administrations should provide for access and reuse of their services and data irrespective of specific technologies or products, extending the concept beyond cross-border operation to include technology-agnostic access. |
| European Public Services | European public services are public services supported by electronic means, including interactions with other public administrations, citizens and businesses. |
| European Public Services | European public services are services that can potentially be used by anyone in any Member State. They must be designed with careful consideration of principles such as multilingualism, security and privacy, inclusion and accessibility, and preservation of information to ensure they are accessible and trustworthy for all citizens and businesses across Europe. |
| European Public Services | European public services are services that operate in a complex and changing environment and often rely on components that are common to many such services. The implementation and delivery of a given European public service requires cooperation between public administrations at different administrative levels. |
| Evaluation | Evaluation is a process phase where, after service provision, users' feedback is collected and evaluated. |
| Evaluation USE 1 | The section describes evaluation as collecting and evaluating users' feedback after service provision, which matches the given definition. |
| Execution | Execution is a process phase that entails collecting and exchanging information, applying business rules as required by the relevant legislation and policies to grant or reject access to a service and then providing the requested service to citizens or businesses. |
| Execution USE 1 | The section describes execution as collecting and exchanging information, applying business rules to grant or reject access, and providing the requested service, which matches the given definition. |
| Execution USE 2 | The section mentions 'seamless execution' as one of the aspects that services should be governed to ensure, consistent with the definition's focus on process execution. |
| External Information Sources | External information sources are data sources delivered outside organizational boundaries by third parties, such as open data, data from international organisations, chambers of commerce, the Internet of Things (e.g. sensors) and social web applications. |
| External Information Sources USE 1 | The section states that information sources are available 'not only inside the administrative system but also in the external environment' and can be used as building blocks, expanding on how external sources contribute to service creation. |
| External Information Sources USE 2 | The section expands on external information sources by providing specific examples beyond those in the definition, including payment services from financial institutions, connectivity services from telecommunications providers, and explicitly mentioning data collected through Internet of Things sensors and social web applications as useful sources. |
| Federated Service Interoperability USE 1 | The section describes data federation as creating a virtual database that fetches and organizes data from multiple sources using a standard data model, which is consistent with the concept of federated interoperability where systems work together across technical domains while maintaining their independence, though it doesn't add new information beyond what the definition implies about cross-domain service delivery. |
| Federated Service Interoperability USE 2 | The section describes federated solutions like data mesh where every business unit manages its data independently but presents it to others in a centrally defined format, which is consistent with the definition. What is new is the specific application to data management contexts where business units maintain autonomy over their data while participating in a unified framework, illustrating a practical implementation of federated interoperability in the data domain. |
| Federated Service Interoperability USE 3 | The section uses the term 'federated data integration' which refers to a technical data integration method where data remains in original source systems and queries are executed across disparate systems, but this is unrelated to the definition of Federated Service Interoperability which concerns cross-border/cross-domain service delivery with organizational responsibilities and governance. |
| Four Freedoms | The four freedoms are fundamental principles stipulated in the Treaties of the European Union that guarantee the free movement of goods, capital, services and people between the 28 Member States. These freedoms are assured by common policies supported by interconnected, interoperable networks and systems. |
| Four Freedoms USE 1 | The section describes the four freedoms as the free movement of goods, capital, services and people between the 28 Member States, assured by common policies supported by interconnected, interoperable networks and systems, which is consistent with the definition. |
| Four Layers Of Interoperability | The four layers of interoperability are legal, organisational, semantic and technical challenges that must be addressed to achieve interoperable public services. These layers represent the different dimensions of interoperability that go beyond purely technical considerations. |
| Four Layers Of Interoperability USE 1 | The section explicitly lists the 'four layers of interoperability: legal, organisational, semantic and technical' as part of the interoperability model, consistent with the definition. |
| Four Layers Of Interoperability USE 2 | The section states that addressing legal interoperability will facilitate interoperability at lower levels (semantic and technical), revealing that legal interoperability is positioned hierarchically above semantic and technical layers in the four-layer model. |
| Four Layers Of Interoperability USE 3 | The section refers to interoperability as a multi-dimensional issue that needs awareness and skills in legal, organisational, semantic and technical aspects, consistent with the four layers definition. |
| Four Layers Of Interoperability USE 4 | The section mentions semantic, technical, organisational and legal levels where interoperability agreements include standards and specifications, consistent with the four layers defined. |
| Four Layers Of Interoperability USE 5 | The section explicitly states that governance 'should cover all layers: legal, organisational, semantic and technical,' directly consistent with the definition. |
| Four Layers Of Interoperability USE 6 | The section identifies the four layers of interoperability challenges as legal, organisational, semantic and technical, which is consistent with the definition. |
| Four Layers Of Interoperability USE 7 | Chapter 3 presents a layered interoperability model which organises different interoperability aspects in layers, consistent with the definition of the four layers addressing legal, organisational, semantic and technical challenges. |
| Governance Interoperability USE 1 | The section mentions data governance and compliance with corporate policies in the context of data flows, which is consistent with governance ensuring compliance with legal requirements and policies, but does not add new information beyond what the definition implies. |
| Governance Interoperability USE 2 | The section uses 'governance' to refer to data governance policies for access control and data masking, which is a different concept from the defined Governance Interoperability framework that specifically addresses legal compliance and interoperability between different jurisdictional domains. |
| Governance Interoperability USE 3 | The section discusses data governance in the context of integration, emphasizing consistency, security, and compliance, which aligns with the definition's focus on compliance with legal requirements and policies, though it does not add new information beyond what the definition implies about governance frameworks ensuring compliance and security. |
| Governance Interoperability USE 4 | The section mentions data governance tools that ensure compliance with regulations and adherence to data governance policies, which aligns with the definition's focus on ensuring compliance with legal requirements and policies in interoperability solutions. |
| Governance Interoperability USE 5 | The section explicitly addresses 'data governance and security' in the context of integration, stating that 'data governance practices ensure that data is handled in compliance with regulations and privacy requirements' when integrating sensitive or regulated data, which extends the definition by showing how governance interoperability is applied specifically within data integration workflows. |
| Inclusion | Inclusion is about enabling everyone to take full advantage of the opportunities offered by new technologies to access and make use of European public services, overcoming social and economic divides and exclusion. It must be part of the whole development lifecycle of a European public service in terms of design, information content and delivery. |
| Inclusion USE 1 | The section uses inclusion consistently with its definition, restating that it enables everyone to take advantage of new technologies to access European public services and overcome social and economic divides, and that it must be part of the whole development lifecycle. |
| Information Management Strategy | An information management strategy is a coordinated approach drafted at the highest possible level (corporate or enterprise) to avoid fragmentation and set priorities in managing data and information as a public asset. Management of metadata, master data and reference data should be prioritised within this strategy. |
| Information Management Strategy USE 1 | The section recommends putting in place an information management strategy at the highest possible level to avoid fragmentation and duplication, with prioritisation of metadata, master data and reference data management, consistent with the definition. |
| Information Sources | Information sources are base registries, open data portals, and other authoritative sources of information that public administrations produce, maintain and manage. These sources are often unknown outside the boundaries of a particular administration and can be used to create integrated public services as building blocks. |
| Information Steward | The information steward is the body (or possibly individual) responsible and accountable for collecting, using, updating, maintaining and deleting information. This includes defining permissible information use, complying with privacy regulations and security policies, ensuring that information is current and ensuring the accessibility of data by authorised users. |
| Information Steward USE 1 | The section provides the exact definition of information steward, describing it as the body responsible for collecting, using, updating, maintaining and deleting information. |
| Integrated Public Service Governance | Integrated public service governance is the coordination and governance by authorities with a mandate for planning, implementing and operating European public services when multiple organisations are involved. It ensures integration, seamless execution, reuse of services and data, and development of new services and building blocks, covering all layers: legal, organisational, semantic and technical. It includes the definition of organisational structures, roles and responsibilities, decision-making processes, requirements for interoperability aspects, change management plans, and business continuity/disaster recovery plans. |
| Integrated Public Service Provision | Integrated public service provision is a process that includes need identification, planning, execution, and evaluation phases executed by the coordination function. This process involves identifying needs prompted by public service requests, planning by identifying and aggregating services, executing by collecting information and applying business rules, and evaluating by collecting user feedback. |
| Integrated Public Service Provision USE 1 | The section states that the process phases are part of 'integrated public service provision', which is consistent with the definition describing it as a coordinated process with phases including need identification, planning, execution, and evaluation. |
| Integrated Public Service Provision USE 2 | The section describes an 'integrated service provision process' formed by aggregating building blocks, and discusses avoiding duplication and interoperability problems while increasing service quality, providing practical operational context for the provision process. |
| Integrated Public Service Provision USE 3 | The section title directly uses the term 'integrated public services provision', consistent with the definition's description of it as a coordinated process for planning, implementing, and operating public services across multiple organizations. |
| Integrated Public Service Provision USE 4 | The section identifies 'integrated public service governance' as a 'cross-cutting component of the four layers', suggesting that governance is a distinct element that spans across all interoperability layers, adding specificity to how integrated public service provision is structured within the interoperability model. |
| Integrated Public Service Provision USE 5 | The section states that 'European public service provision often requires different public administrations to work together' and that governance should ensure 'integration, seamless execution, reuse of services and data, and development of new services,' and notes that 'more is said about the aspects of integrated public service provision in section 4.3.1,' indicating that this section focuses specifically on the governance aspect of integrated public service provision. |
| Integrated Public Services | Integrated public services are services created by aggregating appropriate services and information sources to form an integrated service provision process using building blocks from both internal and external sources. |
| Integrated Public Services | Integrated public services are fully fledged public services that require addressing governance, compatibility of legal regimes, alignment of business processes and secure access to data sources. The EIF conceptual model for public services covers the design, planning, development, operation and maintenance of integrated public services at all governmental levels from local to EU level. |
| Integrated Public Services USE 1 | The section refers to 'integrated public services' in the context of the conceptual model that guides their planning, development, operation and maintenance, consistent with the definition but not adding new information. |
| Integrated Public Services USE 2 | The section explains that integrated public services are created by aggregating building blocks (information sources and services) to form an integrated service provision process, providing operational detail about the aggregation mechanism. |
| Integrated Public Services USE 3 | The section title references integrated public services provision, consistent with the definition's description of services that aggregate and combine appropriate services and information sources across governmental levels. |
| Integrated Public Services USE 4 | The section discusses 'integrated public services' and the need for coordination and governance when multiple organizations are involved, consistent with the definition. |
| Integrated Public Services USE 5 | The section refers to integrated public services at all governmental levels from local to EU level in the context of the conceptual model, which is consistent with the definition. |
| Integrated Service Delivery | Integrated service delivery is a component of the conceptual model based on a coordination function to remove complexity for the end-user. It is one of the basic structural elements that enables public services to be provided in a unified manner. |
| Integrated Service Delivery USE 1 | The section lists integrated service delivery based on a coordination function to remove complexity for the end-user as a basic component of the model's structure, which is consistent with the definition. |
| Interoperability | Interoperability is the capability of systems to ensure effective communication between digital components such as devices, networks and data repositories, enabling public administrations to connect with each other and allowing citizens and businesses to identify and use available digital public services across different countries. |
| Interoperability | Interoperability is the ability of organisations to interact towards mutually beneficial goals, involving the sharing of information and knowledge between these organisations, through the business processes they support, by means of the exchange of data between their ICT systems. This concept is fundamental to enabling seamless collaboration and information exchange across different organizational boundaries. |
| Interoperability | Interoperability is the ability of information systems to exchange information and preserve meaning across language boundaries. The multilingual aspect of interoperability becomes relevant when a public service requires exchanges between information systems across language boundaries, as the meaning of the information exchanged must be preserved. |
| Interoperability | Interoperability is the ability of systems to work together, which is fundamentally enabled by standards and specifications. It requires structured processes for selecting, evaluating, monitoring, and testing standards and specifications to ensure systems can effectively communicate and function across different contexts and borders. |
| Interoperability | Interoperability is a prerequisite for enabling electronic communication and exchange of information between public administrations. It is not only an ICT matter, as it has layers of implications ranging from the legal to the technical. Interoperability addresses issues in a holistic approach across legal, organisational, semantic and technical layers at different administrative levels from local to EU. |
| Interoperability Agreements | Interoperability agreements are formal arrangements for cooperation between organisations involved in European public service provision. These agreements are detailed enough to achieve their aim of providing European public services while leaving each organisation maximum feasible internal and national autonomy. They usually include standards and specifications at semantic and technical levels, and in some cases at organisational level, and are made specific and binding via legislation at EU and/or national level or via bilateral and multilateral agreements. |
| Interoperability Agreements USE 1 | The section states that interoperability agreements are reached outside the scope of a particular European public service and their sustainability should be guaranteed over time, adding that they are results of work done by public administrations at different levels requiring coordination and monitoring through a holistic approach. |
| Interoperability Agreements USE 2 | The section describes interoperability agreements as formal arrangements for cooperation that include standards and specifications at various levels and are made binding through legislation or bilateral/multilateral agreements, which is consistent with the definition. |
| Interoperability Agreements USE 3 | The section discusses instruments to formalise cooperation (MoUs and agreements), consistent with the definition of interoperability agreements as formal arrangements for cooperation. |
| Interoperability Agreements USE 4 | The section mentions 'establishment and management of interoperability agreements' as part of what is required for ensuring interoperability, consistent with the definition. |
| Interoperability Architecture USE 1 | The section discusses integrating applications and data across systems, which is consistent with the framework concept, but does not address the security, compliance, confidentiality, or cross-border aspects that are central to the definition. |
| Interoperability By Design | Interoperability by design is a standard approach for the design and operation of European public services that is promoted by the EIF's conceptual model. This approach ensures that interoperability requirements are considered from the outset when designing public services. |
| Interoperability By Design | Interoperability by design is the native capability of building blocks to be combined and ready for mash-up in different environments with minimum customisation. |
| Interoperability By Design | Interoperability by design is an approach where European public services are designed in accordance with a proposed model and with certain interoperability and reusability requirements in mind. This means that interoperability is built into the service from the beginning rather than added later. |
| Interoperability By Design USE 1 | The section states that European public services should be designed in accordance with the conceptual model and with interoperability and reusability requirements in mind, which extends the definition by specifying that this design approach should follow a particular conceptual model and explicitly include reusability requirements. |
| Interoperability By Design USE 2 | The section uses the exact phrase 'interoperability by design' in quotation marks to describe building blocks' native capability of being combined, consistent with the definition. |
| Interoperability By Design USE 3 | The section describes interoperability-by-design as a 'paradigm' and states that the interoperability model 'may also be considered as an integral element' of it, suggesting that the interoperability model with its four layers is a concrete implementation or component of the broader interoperability-by-design approach. |
| Interoperability By Design USE 4 | The conceptual model promotes 'interoperability by design' as a standard approach for design and operation of European public services, consistent with its definition as an approach promoted by the EIF. |
| Interoperability Checks | Interoperability checks are a process of screening existing legislation to identify interoperability barriers such as sectoral or geographical restrictions in the use and storage of data, different and vague data licence models, over-restrictive obligations to use specific digital technologies or delivery modes to provide public services, contradictory requirements for the same or similar business processes, and outdated security and data protection needs. |
| Interoperability Checks USE 1 | The section describes interoperability checks as screening existing legislation to identify barriers, which matches the definition exactly. |
| Interoperability Governance | Interoperability governance refers to decisions on interoperability frameworks, institutional arrangements, organisational structures, roles and responsibilities, policies, agreements and other aspects of ensuring and monitoring interoperability at national and EU levels. It is the key to a holistic approach on interoperability, as it brings together all the instruments needed to apply it. |
| Interoperability Governance USE 1 | The section lists integrated public service governance as a structural component of the model, which aligns with the definition of interoperability governance covering decisions on frameworks, arrangements, and structures. |
| Interoperability Governance USE 2 | The section identifies 'interoperability governance' as a 'background layer' of the interoperability model, consistent with the definition of interoperability governance as addressing frameworks, arrangements, and policies. |
| Interoperability Governance USE 3 | The section states that interoperability governance is the key to a holistic approach on interoperability because it brings together all the instruments needed to apply it, and emphasizes that coordination, communication and monitoring are of utmost importance for successful governance. |
| Interoperability Governance USE 4 | The section states that setting up and managing interoperability agreements is part of public service governance, adding the specific insight that interoperability agreements are a component of the broader governance framework. |
| Interoperability Governance USE 5 | The section provides detailed requirements for what integrated public service governance should include as a minimum, specifying organizational structures, roles, decision-making processes, requirements for interoperability aspects, change management plans, and business continuity plans, thus elaborating on the practical implementation of interoperability governance. |
| Interoperability Governance USE 6 | The section states that the EIF points out the essential role of governance to ensure coordination of relevant activities across all levels and sectors of administration, adding that governance addresses the challenge of a holistic approach across layers and administrative levels. |
| Interoperability Governance USE 7 | The section includes navigation links to 'Governance' with subsections for Board, Community, and National competent authorities, which aligns with the definition's reference to institutional arrangements and organizational structures, but does not provide new insights. |
| Interoperability Governance USE 8 | The section mentions that the EIF gives guidance on how to improve governance of interoperability activities, which is consistent with the definition but does not elaborate on what interoperability governance encompasses. |
| Interoperability Governance USE 9 | The section includes 'Governance' as a main navigation category with subcategories including Board, Community, and National competent authorities, which is consistent with the concept of interoperability governance structures but does not elaborate on what interoperability governance entails. |
| Interoperability Principles | Interoperability principles are fundamental behavioural aspects to drive interoperability actions. They are relevant to the process of establishing interoperable European public services and describe the context in which European public services are designed and implemented. |
| Interoperability Principles USE 1 | The section provides new information about interoperability principles by specifying that there are twelve underlying principles grouped into four categories: principles setting context for EU actions, core interoperability principles, principles related to user needs and expectations, and foundation principles for cooperation among public administrations. |
| Interoperability Principles USE 2 | The section discusses openness as an underlying principle of the EIF, consistent with the concept of interoperability principles. |
| Interoperability Principles USE 3 | The section presents transparency as an underlying principle (principle 3) of the EIF, which is consistent with the definition of interoperability principles as fundamental behavioral aspects. |
| Interoperability Principles USE 4 | The section mentions that principles set out in the EIF guide decision-making on establishing interoperable European public services, which is consistent with the definition that principles are relevant to the process of establishing such services. |
| Interoperability Principles USE 5 | The section references interoperability principles in navigation elements and policy briefs, consistent with the definition as fundamental behavioral aspects, but does not elaborate on what these principles are or how they are applied. |
| Interoperability Principles USE 6 | Chapter 2 presents principles intended to establish general behaviours on interoperability, which is consistent with the definition of interoperability principles as fundamental behavioural aspects. |
| Interoperability Principles USE 7 | The section mentions common principles as part of the basic interoperability guidelines defined by the framework, consistent with the definition describing principles as fundamental behavioral aspects driving interoperability actions. |
| Interoperability USE 1 | The section uses 'interoperability' and 'interoperable' multiple times in a manner consistent with the definition, referring to establishing interoperable European public services and interoperability actions, but does not add substantive new information beyond what is implied by the definition. |
| Interoperability USE 1 | The section describes data integration as bringing together data from different sources to create a unified view, which is a specific application of interoperability focused on data systems, and adds that this enables faster business decisions and supports uses from basic querying to complex predictive analytics. |
| Interoperability USE 10 | The section mentions that implementing technical solutions at EU level will require common or compatible models, standards and agreements on common infrastructure, which is consistent with the definition of interoperability as enabling systems to work together through standards and specifications. |
| Interoperability USE 10 | The section describes data integration as creating defined pathways to move data between systems, which is a specific implementation approach to achieving interoperability. It provides concrete methods (ETL, ELT, data replication, virtualization) that enable systems to exchange data and work together, adding practical detail about how interoperability is accomplished in data-driven organizations. |
| Interoperability USE 11 | The section discusses interoperability problems arising from duplication and lack of reuse, and emphasizes that building blocks should exhibit interoperability capabilities, adding practical context about how lack of interoperability creates operational challenges. |
| Interoperability USE 11 | The section describes data integration as creating a unified system from disparate sources, which is consistent with interoperability's goal of systems working together seamlessly, and adds that this specifically involves 'stitching together different data subsystems' and 'consolidate all types of data' to enable unified insights and business decisions. |
| Interoperability USE 12 | The section describes an 'interoperability model' applicable to digital public services, consistent with the concept of interoperability as enabling systems and organizations to work together. |
| Interoperability USE 12 | The section describes data integration as connecting software to establish continuous data flow across organizations, which is consistent with interoperability's definition of systems communicating and working together seamlessly. |
| Interoperability USE 13 | The section discusses interoperability barriers and the need to ensure interoperability between public services, consistent with the general definition of enabling systems and organizations to work together. |
| Interoperability USE 13 | The section uses 'integration' and 'combining data from different sources' throughout, but does not address interoperability in the sense of systems communicating seamlessly or establishing common protocols and standards. The focus is on data consolidation rather than system-to-system communication capabilities. |
| Interoperability USE 14 | The section discusses semantic interoperability as one aspect of overall interoperability, consistent with the broader definition that interoperability addresses technical, semantic, organizational, and legal boundaries. |
| Interoperability USE 14 | The section discusses data integration and connectivity between systems, but uses these concepts in a general sense focused on technical data movement rather than in the specific sense of interoperability as defined—the seamless collaboration of different systems through common protocols and standards. |
| Interoperability USE 15 | The section discusses interoperability barriers and the need to ensure interoperability, consistent with the general definition of enabling systems to exchange and share information. |
| Interoperability USE 15 | The section describes data integration as enabling transfer and sync of data from different systems, types and formats, which is consistent with interoperability's definition of systems communicating and exchanging data. However, it adds that data integration is not a one-time event but a continuous, evolving process that adapts to changing business requirements, technologies and frameworks, which extends beyond the static definition of interoperability. |
| Interoperability USE 16 | The section emphasizes that interoperability should be guaranteed in a sustainable way and not as a one-off target or project, and that interoperability between public administrations at different administrative levels will only be successful if governments give sufficient priority and assign resources to their respective interoperability efforts. |
| Interoperability USE 16 | The section describes data integration patterns operating across diverse IT landscapes spanning multiple clouds and on-premises environments with several data sources and targets, which demonstrates interoperability in practice by showing how different systems communicate and exchange data through ETL, ELT, and data ingestion patterns. |
| Interoperability USE 17 | The section implicitly refers to interoperability as the broader concept that organisational interoperability is a component of, consistent with the definition's holistic approach. |
| Interoperability USE 17 | The section discusses real-time data integration and seamless scalability, which are practical implementations of interoperability principles, allowing different systems to work together to ingest and process data. |
| Interoperability USE 18 | The section states that 'interoperability is regularly disrupted by changes to the environment' including legislation, user needs, organizational structure, business processes, and new technologies, adding the insight that interoperability requires continuous maintenance due to environmental changes. |
| Interoperability USE 18 | The section describes data integration tools as enabling interoperability by facilitating communication and data exchange between diverse source and target systems through standardized formats, integration hubs, and automated pipelines, which operationalizes the concept of interoperability in the specific context of data integration technology. |
| Interoperability USE 19 | The section states that standards and specifications are fundamental to interoperability and mentions testing interoperability, which is consistent with the definition but does not provide new insights. |
| Interoperability USE 19 | The section describes integration connecting departments and enabling shared dashboards, which is consistent with interoperability's definition of systems working together seamlessly, and adds the specific benefit that this creates cohesive customer experiences and prevents organizational silos. |
| Interoperability USE 2 | The section discusses interoperability in the context of openness, noting that open specifications have a positive effect on interoperability and that openness is an enabler of reusability. |
| Interoperability USE 2 | The section describes specific technical tools that enable interoperability in practice, including data connectors that move data between databases and ETL tools that extract, transform, and load data across systems, demonstrating concrete implementations of the capability to exchange data and work together seamlessly. |
| Interoperability USE 20 | The section states that interoperability is a prerequisite for enabling electronic communication and exchange of information between public administrations, and specifically that it is a prerequisite for achieving a digital single market, which adds new information about its foundational role in EU digital strategy. |
| Interoperability USE 20 | The section describes interoperability in practice by explaining how disconnected systems that don't talk to each other cause problems (service agents can't see purchase histories, marketers miss audiences), and how data integration bridges systems to create seamless experiences, which adds concrete business context and outcomes to the definition's concept of systems communicating and working together. |
| Interoperability USE 21 | The section is part of the 'Interoperable Europe Portal' and references monitoring and solutions related to interoperability, consistent with the definition of enabling systems and organizations to exchange information, but does not add substantive new information about the concept. |
| Interoperability USE 21 | The section describes integration software that connects applications and allows data flow between systems, which is consistent with the definition of interoperability as systems working together seamlessly. |
| Interoperability USE 22 | The section provides a specific definition of interoperability for the purpose of the EIF, emphasizing the ability of organisations to interact toward mutually beneficial goals through sharing information and knowledge via business processes and ICT systems, which adds specificity about the organizational and goal-oriented aspects beyond the general definition provided. |
| Interoperability USE 22 | The section reveals that despite enterprises managing over 1,000 applications on average, 70% remain unconnected, indicating a significant interoperability gap in practice where systems are not communicating or working together seamlessly. |
| Interoperability USE 23 | The section uses 'interoperability' in the phrase 'interoperability areas' as a general descriptor for the types of interactions, but does not engage with the concept of exchanging and sharing information while preserving meaning or addressing the technical, semantic, organizational, and legal dimensions described in the definition. |
| Interoperability USE 23 | The section emphasizes that interoperability enables real-time action on unified data, such as AI-driven customer identification and instant response triggering, which extends beyond the definition's focus on communication and data exchange to include actionable intelligence and automated responses. |
| Interoperability USE 24 | The section uses the concept of interoperability as the core purpose of the framework, consistent with the definition's emphasis on enabling systems and organizations to exchange and share information effectively. |
| Interoperability USE 24 | The section describes data integration tools that enable different systems to communicate and exchange data, which is consistent with the definition of interoperability as the capability of different systems to communicate and work together seamlessly. |
| Interoperability USE 25 | The section emphasizes that lack of interoperability is a major obstacle to the digital single market and that the EIF steers European interoperability initiatives to create a coherent interoperable environment, adding new information about interoperability's strategic importance and the EIF's steering role. |
| Interoperability USE 25 | The section identifies data integration as a solution to overcome challenges of data silos and inconsistencies by bringing together data from disparate sources, which is a specific application context for interoperability in the data management domain, adding that it transforms data into consistent structure for analysis and decision making. |
| Interoperability USE 26 | The section explains that the EIF lays out basic conditions for achieving interoperability and creates interoperability conditions for extending services across borders, adding that it increases the interoperability potential of national actions and that owners and designers become aware of interoperability requirements. |
| Interoperability USE 26 | The section uses 'integration' throughout to describe combining data from different sources, but this refers to data consolidation and movement rather than the capability of systems to communicate and work together seamlessly as defined for interoperability. |
| Interoperability USE 27 | The section describes interoperability as necessary for ensuring effective communication between digital components and for establishing cross-organizational relationships and streamlining processes, adding that the EIF provides guidance on improving governance of interoperability activities and ensuring legislation does not compromise interoperability efforts. |
| Interoperability USE 27 | The section describes data integration as bringing together information from various sources and systems to provide a unified view, which is a practical application and benefit of interoperability. It extends beyond the definition by specifying concrete organizational benefits such as reduced silos, improved data quality, increased efficiency, and faster insights that result from systems working together seamlessly. |
| Interoperability USE 28 | The section is part of the 'Interoperable Europe Portal' and mentions various interoperability-related features and services, using the term in a manner consistent with its definition as enabling exchange and collaboration, but without adding new information about the concept. |
| Interoperability USE 28 | The section uses interoperability in the context of application integration (API), stating that it ensures seamless data flow and interoperability between different software applications that need to share data and work together, providing a concrete use case example with HR and finance systems. |
| Interoperability USE 3 | The section states that reusability is an enabler of interoperability, which is consistent with the definition that interoperability enables systems to exchange information effectively. |
| Interoperability USE 3 | The section describes data integration solutions that enable different systems to work together and exchange data, which is consistent with the definition of interoperability as the capability of different systems to communicate and exchange data seamlessly. |
| Interoperability USE 4 | The section adds that transparency is a prerequisite for interoperability, specifically stating that 'interoperability depends on ensuring the availability of interfaces to these systems and the data they handle' and that 'interoperability facilitates reuse of systems and data.' |
| Interoperability USE 4 | The section describes data integration processes that connect applications and systems through configuration management, which is a practical implementation mechanism for achieving interoperability. It adds that effective interoperability requires automated configuration management across multiple environments rather than manual processes, and that proper variable management in scripts or deployment interfaces enables the seamless cross-system operations that interoperability aims to achieve. |
| Interoperability USE 5 | The section extends the concept of interoperability by specifically addressing its multilingual dimension, noting that interoperability becomes relevant when information systems exchange data across language boundaries and that the meaning of information must be preserved in such exchanges. |
| Interoperability USE 5 | The section describes data integration as enabling data to 'flow unimpeded, yet securely, across the IT landscape,' which extends the interoperability concept by emphasizing the security dimension and the practical outcome of seamless data flow within organizations, going beyond the definition's focus on communication protocols and standards. |
| Interoperability USE 6 | The section adds that a European framework for interoperability is justified to overcome policy differences that result in heterogeneity and lack of interoperability, which put the digital single market at risk. |
| Interoperability USE 6 | The section discusses integration processes and systems working together through a common data model, which is consistent with the definition of interoperability but does not add new information beyond what the definition implies about systems communicating and working together. |
| Interoperability USE 7 | The section discusses interoperability solutions in the context of European public services, consistent with the definition's focus on enabling systems and organizations to exchange information effectively. |
| Interoperability USE 7 | The section describes interoperability in practice through the integration of SaaS, custom, and partner applications, emphasizing that modern organizations must enable these diverse systems to work together, which extends the definition by highlighting that interoperability is now a business requirement driven by the need to differentiate through unique combinations of business capabilities. |
| Interoperability USE 8 | The section states that data must be interoperable so it can be found, discovered and processed to ensure non-discriminatory opening and reuse, adding the specific requirement that interoperability is necessary for a level playing field in open data contexts. |
| Interoperability USE 8 | The section discusses data integration tools that ingest, consolidate, transform, and transfer data between systems with features like pre-built connectors and portability, which aligns with the definition's concept of systems communicating and exchanging data, but does not extend beyond the basic notion of cross-system data exchange. |
| Interoperability USE 9 | The section mentions that commonly agreed descriptions are needed to enable interoperability between catalogues, which is consistent with the general definition of interoperability as the ability to exchange and share information while preserving meaning. |
| Interoperability USE 9 | The section identifies improved collaboration and reduced errors through seamless knowledge transfer between systems as a specific benefit or outcome of interoperability, which extends beyond the definition's focus on the capability itself. |
| Interoperable European Public Services | Interoperable European public services are digital public services established at regional, national and EU level that enable electronic communication and collaboration between public administrations. The EIF principles guide decision-making on establishing these services. |
| IoT Network Interoperability USE 1 | The section mentions 'Integrating data from Internet of Things (IoT) devices' but focuses on data integration for monitoring, analysis, and automation purposes, not on the network-level communication capabilities between IoT devices considering their constraints as defined. |
| Jurisdictional Interoperability Layer USE 1 | The section mentions compliance with 'regulations and privacy requirements' in data governance, which is consistent with the jurisdictional layer's role in managing legal and regulatory requirements, but does not add new information beyond what the definition implies. |
| Legacy Systems | Legacy systems are applications and information systems in public administrations that were developed in a bottom-up fashion to solve domain-specific and local problems. This resulted in fragmented ICT islands which are difficult to interoperate and create an additional interoperability barrier in the technical layer. |
| Legacy Systems USE 1 | The section adds that legacy systems create a major obstacle to interoperability and that their plethora creates an additional interoperability barrier specifically in the technical layer due to the size of public administration and fragmentation of ICT solutions. |
| Legacy Systems USE 2 | The section states that information systems were set up in the public sector independently of each other and not in a coordinated way, which explains the historical origin of legacy systems and their contribution to interoperability barriers. |
| Legal Interoperability | Legal interoperability is about ensuring that organisations operating under different legal frameworks, policies and strategies are able to work together. This requires that legislation does not block the establishment of European public services within and between Member States and that there are clear agreements about how to deal with differences in legislation across borders, including the option of putting in place new legislation. |
| Legal Interoperability USE 1 | The section emphasizes that legal interoperability and certainty is essential for open data reuse to reach its full potential, and that legal regimes such as licenses should be standardized, adding the specific context that legal interoperability is critical for the open data domain. |
| Legal Interoperability USE 2 | The section defines legal interoperability as ensuring organisations under different legal frameworks can work together, which is consistent with the provided definition. |
| Legal Interoperability USE 3 | The section mentions 'legal' as one of the layers that governance should cover and refers to 'legislation' as one of the environmental factors affecting interoperability, consistent with the definition. |
| Legal Interoperability USE 4 | The section mentions compatibility of legal regimes as one of the issues to be addressed next to provide fully fledged public services, indicating it is a current challenge area. |
| Loosely Coupled Service Components | Loosely coupled service components are modular parts of public services that are interconnected through shared infrastructure. Access boundaries for services and information are defined through interfaces and conditions of access. Public administrations need to identify, negotiate and agree on a common approach to interconnecting these service components, which requires common or compatible models, standards and agreements on common infrastructure. |
| Loosely Coupled Service Components USE 1 | The section states that public administrations need to identify, negotiate and agree on a common approach to interconnecting service components at different national administrative levels according to each country's organisational set-up, adding the new detail that this coordination happens at varying administrative levels based on national structures. |
| Master Data | Master data is the type of information constituted by base registries for public administrations and European public service delivery. It consists of basic information on data items such as people, companies, vehicles, licences, buildings, locations and roads that serves as the foundational data for public services. |
| Master Data Management USE 1 | The section identifies Master Data Management tools as having a 'transform' element that addresses the challenge of organizing and formatting multiple versions of data that mean the same thing, such as different date formats, which extends beyond the definition's focus on governance strategy and master/slave relationships. |
| Master Data Management USE 2 | The section mentions 'traditional master and transactional data' as types of data that organizations maintain across multiple sources, using the term 'master' in a way consistent with the concept of master data but without adding new information about Master Data Management itself. |
| Master Data Management USE 3 | The section discusses data governance tools that ensure data availability, security, usability, and integrity, but does not address the master/slave relationships between information elements or system collaboration aspects that define Master Data Management. |
| Master Data Management USE 4 | The section describes middleware as a mediator that normalizes data and helps transfer data from legacy applications, which is consistent with MDM's role in managing information elements and governance, but does not add new information beyond what the definition implies about data governance and system collaboration. |
| Master Data Management USE 5 | The section describes a specific implementation approach for Master Data Management that involves using taxonomy to enforce standard data definitions, classifications, and categories to establish a single source of truth, which adds practical detail about how MDM achieves its governance objectives beyond what the definition states about master/slave relationships. |
| Master Data Management USE 6 | The section lists 'MDM & 360 Applications' as one of the product offerings, using MDM as an abbreviation for Master Data Management in a product context, which is consistent with its definition as a governance strategy for managing master information elements. |
| Master Data Management USE 7 | The section describes MDM tools as focusing on managing and ensuring consistency and accuracy of master data across the organization, and notes they include data integration capabilities to consolidate and synchronize master data from various systems—adding specific implementation details about consolidation and synchronization that extend beyond the definition's focus on governance strategy and master/slave relationships. |
| Master Data USE 1 | The section states that master data constitutes basic information on people, companies, vehicles, licences, buildings, locations and roads for public administrations and European public service delivery, consistent with the definition. |
| Master Data USE 2 | The section mentions 'master data from base registries as authoritative data used by multiple applications and systems,' consistent with the definition. |
| Master Data USE 3 | The section mentions that management of master data should be prioritised within an information management strategy, consistent with its role as foundational data for public services. |
| Memoranda Of Understanding (MoUs) | Memoranda of understanding are agreements that complement interoperability agreements by addressing operational matters such as support/escalation procedures and contact details. They are instruments used to formalise mutual assistance, joint action and interconnected business processes between participating public administrations. |
| Memoranda Of Understanding (MoUs) USE 1 | The section describes MoUs as agreements that complement interoperability agreements by addressing operational matters such as support/escalation procedures and contact details, consistent with the definition. |
| Multi-channel Service Delivery | Multi-channel service delivery is the availability of alternative channels, physical and digital, to access a service. It is an important part of public service design, as users may prefer different channels depending on the circumstances and their needs. |
| Multi-channel Service Delivery USE 1 | The section describes multi-channel service delivery as the availability of alternative channels (physical and digital) to access services based on user preferences, which is consistent with the definition. |
| Multi-channel Service Delivery USE 2 | The section states that inclusion and accessibility usually involve multi-channel delivery and that traditional paper-based or face-to-face service delivery may need to co-exist with electronic delivery, adding the new insight that multi-channel delivery is particularly important for achieving inclusion and accessibility goals. |
| Multi-channel Service Delivery USE 3 | The section introduces the 'no-wrong-door policy' as a specific principle within multi-channel delivery, adding the new concept that physical and digital channels should coexist in a way that ensures users can access services regardless of their entry point. |
| Multilingualism | Multilingualism is the consideration and implementation of multiple language support in the design and delivery of European public services. It comes into play not just in the user interface, but at all levels in the design of European public services, including data representation in electronic databases and information exchanges across language boundaries. The level of multilingualism support should be based on the needs of expected users, such as the criticality of the service for the digital single market or the size of the relevant audience. |
| Multilingualism USE 1 | The section describes multilingualism consistently with its definition, explaining that it applies at all design levels, affects data representation and information exchanges, and should be based on user needs. |
| NIF | NIF (National Interoperability Framework) is a national-level framework that should be consulted, along with relevant DIFs, when procuring and developing ICT solutions to ensure alignment with standards and specifications. |
| NIF USE 1 | The section (using the full term 'National Interoperability Frameworks') recommends that national interoperability frameworks and interoperability strategies should be aligned with the EIF and, if needed, tailored and extended to address national context and needs. |
| NIF USE 2 | The section recommends consulting the NIF when procuring and developing ICT solutions, which is exactly consistent with the definition provided. |
| NIF USE 3 | The section uses 'NIFs' as an abbreviation for National Interoperability Frameworks when discussing the EIF's guidance role, consistent with the definition. |
| NIF USE 4 | The section explains the relationship between EIF and NIFs, stating that NIFs are expected to build upon the EIF and that compliance with the EIF guarantees NIFs are developed in a coordinated and aligned way while providing flexibility for national requirements. |
| National Interoperability Framework | A National Interoperability Framework (NIF) is one or more documents that define frameworks, policies, strategies, guidelines and action plans on interoperability in a Member State. The European Commission supports a National Interoperability Framework Observatory (NIFO) to provide information about NIFs and help public administrations share and reuse experiences. |
| National Interoperability Framework USE 1 | The section (using the plural form 'National Interoperability Frameworks') recommends that national interoperability frameworks and interoperability strategies should be aligned with the EIF and, if needed, tailored and extended to address national context and needs. |
| National Interoperability Framework USE 2 | The section refers to NIFs as objects of EIF guidance for design and update, consistent with the definition of NIFs as national-level frameworks. |
| National Interoperability Framework USE 3 | The section explains that national specificities must be taken into account when transposing the EIF into the national context, and that when a NIF aligned with the EIF is used for implementing public services at all national administration levels, it creates interoperability conditions for extending services across borders. |
| National Interoperability Framework USE 4 | The section mentions 'National competent authorities' under governance, which relates to NIFs but does not provide additional information about what a National Interoperability Framework is or how it functions. |
| National Interoperability Frameworks (NIFs) | National interoperability frameworks are national policies, strategies and guidelines promoting interoperability that are designed and updated based on guidance from the European Interoperability Framework. NIFs are expected to build upon the EIF by adding new or fine-tuning existing elements while taking into account national specificities of different administrative and political systems. |
| National Interoperability Frameworks (NIFs) | National Interoperability Frameworks are frameworks expected to be tailored and extended in such a way that national specificities are properly addressed, while being aligned with the EIF (European Interoperability Framework). |
| National Interoperability Frameworks (NIFs) USE 1 | The section adds that Member States should enjoy sufficient freedom to develop their NIFs with respect to EIF recommendations, and that NIFs are expected to be tailored and extended to properly address national specificities. |
| National Interoperability Frameworks (NIFs) USE 2 | The section explains that a NIF can be one or more documents that define frameworks, policies, strategies, guidelines and action plans on interoperability in a Member State, and describes the National Interoperability Framework Observatory (NIFO) which helps public administrations share experiences and supports the 'transposition' of the EIF nationally. |
| National Interoperability Frameworks (NIFs) USE 3 | The section states that the EIF provides guidance to public administrations on the design and update of NIFs, adding the new information that NIFs can also be 'national policies, strategies and guidelines promoting interoperability' beyond just frameworks. |
| National Interoperability Frameworks (NIFs) USE 4 | The section explains that NIFs should build upon the EIF by adding new or fine-tuning existing elements, and that some EIF elements can be directly copied into a NIF while others need to be contextualised and tailored to cover particular national needs. |
| National Interoperability Frameworks (NIFs) USE 5 | The section mentions 'National competent authorities' under governance, which relates to the implementation of NIFs but does not provide new information about what NIFs are or how they function. |
| Need Identification | Need identification is a process phase prompted by a public service request by a citizen or business. |
| Need Identification USE 1 | The section defines need identification as prompted by a public service request by a citizen or business, which exactly matches the given definition. |
| Network & Media Layer USE 1 | The section lists networking products including Cloud CDN, Cloud DNS, Cloud Load Balancing, Virtual Private Cloud, and various connectivity options, which are consistent with foundational infrastructure for data exchange and communication, though without elaborating on the layer concept itself. |
| No Wrong Door Policy | A no wrong door service delivery policy is an approach to provide alternative options and channels for service delivery, while securing the availability of digital channels (digital-by-default). This ensures that users can access services through multiple entry points without being turned away. |
| No Wrong Door Policy USE 1 | The section describes a no wrong door service delivery policy to provide alternative options and channels for service delivery while securing the availability of digital channels (digital-by-default), which is consistent with the definition. |
| Once-only Principle | The once-only principle is the concept that, as far as possible under the legislation in force, users should be able to provide data once only, and administrations should be able to retrieve and share this data to serve the user, in accordance with data protection rules. |
| Once-only Principle USE 1 | The section describes that users should be able to provide data once only and administrations should retrieve and share this data in accordance with data protection rules, consistent with the definition. |
| Open Data | Open data is information published by public organisations under open use licences. It represents large amounts of information stored by public administrations with potential for reuse and can be exploited as external information sources. |
| Open Data | Open data is public sector data that is released in machine-readable formats for use by others to stimulate transparency, fair competition, innovation and a data-driven economy. The opening and reuse of this data must be non-discriminatory, meaning that data must be interoperable so that it can be found, discovered and processed. Open data should be accompanied by high quality, machine-readable metadata in non-proprietary formats, including descriptions of content, collection methods, quality levels, and licence terms. |
| Open Data USE 1 | The section describes open data as public data that should be freely available for use and reuse with clear licences, consistent with the definition. |
| Open Data USE 2 | The section provides detailed implementation guidance for open data, specifying that it should include feedback loops for users to comment on quality and suggest improvements, and that the right to reuse should be communicated clearly with standardized legal regimes, adding practical operational details beyond the basic definition. |
| Open Data USE 3 | The section mentions open data portals as a type of catalogue, which is consistent with the definition but does not provide new information about open data itself. |
| Open Data USE 4 | The section mentions 'open data under open use licences published by public organisations' as an example of information with potential for reuse, consistent with the definition. |
| Open Data USE 5 | The section mentions open data as one type of external information source that public administrations need to exploit, consistent with the definition's characterization of open data as public sector information released for unrestricted use. |
| Open Government Data | Open government data (or open data) refers to the idea that all public data should be freely available for use and reuse by others, unless restrictions apply e.g. for protection of personal data, confidentiality, or intellectual property rights. This data should be published with as few restrictions as possible and clear licences for its use to allow better scrutiny of administrations' decision-making processes and realise transparency in practice. |
| Open Government Data USE 1 | The section explicitly defines and discusses open government data (referred to as 'open data') as public data that should be freely available for use and reuse unless restrictions apply. |
| Open Government Data USE 2 | The section discusses open data from public sector information with clear licensing terms, consistent with the definition's emphasis on freely available public data with clear licenses for use. |
| Open Source Software | Open source software is software whose source code is available for use, modification, and distribution. The use of open source software technologies and products can help save development cost, avoid a lock-in effect and allow fast adaptation to specific business needs because the developer communities that support them are constantly adapting them. |
| Open Source Software USE 1 | The section describes open source software as helping to save development cost, avoid lock-in, and allow fast adaptation to business needs, and recommends its active and fair consideration. |
| Open Specifications | Open specifications are specifications where all stakeholders have the opportunity to contribute to development and a public review is part of the decision-making process, the specification is available for everyone to study, and intellectual property rights are licensed on FRAND terms in a way that allows implementation in both proprietary and open source software, preferably on a royalty-free basis. Due to their positive effect on interoperability, the use of open specifications has been promoted in many policy statements and is encouraged for European public service delivery. |
| Open Specifications USE 1 | The section restates the definition of open specifications and recommends giving preference to them while considering functional needs, maturity, market support and innovation. |
| Open Specifications USE 2 | The section mentions 'specifications' as part of what should be shared and reused, but does not discuss them in the specific sense of open specifications with stakeholder contribution and FRAND licensing terms. |
| Open Specifications USE 3 | The section recommends using open specifications to ensure technical interoperability when establishing European public services, and states they should be used whenever possible via formal technical specifications. |
| Open-by-default | Open-by-default is an approach enabling reuse, participation/access and transparency in the delivery of public services. This principle promotes openness in the design and operation of European public services. |
| Open-by-default USE 1 | The section uses 'open-by-default' as one of three design principles for European public services, defining it parenthetically as 'enabling reuse, participation/access and transparency,' which is consistent with the given definition. |
| Openness | In the context of interoperable public services, openness mainly relates to data, specifications and software. It encompasses the principle that public data should be freely available, open source software should be considered, and open specifications should be preferred to enable reusability and avoid lock-in effects. |
| Openness USE 1 | The section elaborates on the definition by explaining that openness relates to data, specifications and software, and also includes empowering citizens and businesses in service design. |
| Openness USE 2 | The section states that several public administrations promote sharing and reuse by adopting new business models and promoting the use of open source software for key ICT services, providing concrete examples of how openness is being implemented in practice. |
| Openness USE 3 | The section discusses opening data and publishing open data in machine-readable, non-proprietary formats, which aligns with the definition's principle that public data should be freely available. |
| Openness USE 4 | The section mentions 'open data portals' and 'open use licences' but uses these terms in a descriptive context about data availability rather than discussing the broader principle of openness as defined. |
| Organisational Interoperability | Organisational interoperability refers to the way in which public administrations align their business processes, responsibilities and expectations to achieve commonly agreed and mutually beneficial goals. In practice, it means documenting and integrating or aligning business processes and relevant information exchanged, and aims to meet the requirements of the user community by making services available, easily identifiable, accessible and user-focused. |
| Organisational Interoperability USE 1 | The section describes business process alignment as part of organisational interoperability, involving the alignment of business processes and documentation using commonly accepted modelling techniques. |
| Organisational Interoperability USE 2 | The section emphasizes that organizational relationships must be clarified and formalized for establishing and operating European public services, adding the practical requirement of formalization to the concept of aligning business processes and responsibilities. |
| Organisational Interoperability USE 3 | The section provides the definition of organisational interoperability itself, restating how public administrations align business processes, responsibilities and expectations, document and integrate processes, and make services user-focused. |
| Organisational Interoperability USE 4 | The section mentions 'organisational structures and roles and responsibilities for the delivery and operation of public services' as part of governance requirements, consistent with the definition's focus on aligning business processes and responsibilities. |
| Organisational Interoperability USE 5 | The section mentions alignment of business processes as one of the issues to be addressed next to provide fully fledged public services, which relates to organisational interoperability challenges. |
| Organizational Interoperability USE 1 | The section mentions organizations working with a rich ecosystem of partners to leverage and expose information, which is consistent with the definition of structured arrangements enabling different organizations to work together, though it does not add new insights beyond what the definition implies. |
| Organizational Interoperability USE 2 | The section discusses departments working together through data integration and shared dashboards, which is consistent with organizational interoperability as structured arrangements enabling different organizational units to work together effectively, but does not add new information beyond what the definition implies. |
| Planning | Planning is a process phase that entails identifying the services and information sources needed, using the available catalogues, and aggregating them in a single process, considering specific user needs such as personalisation. |
| Planning USE 1 | The section describes planning as identifying services and information sources using catalogues and aggregating them considering user needs, which matches the given definition. |
| Planning USE 2 | The section mentions 'planning' as one of the activities that authorities with a mandate are responsible for, consistent with the definition. |
| Planning USE 3 | The section mentions planning as part of the conceptual model that covers the design, planning, development, operation and maintenance of integrated public services, which is consistent with the definition. |
| Preservation Of Information | Preservation of information is the requirement that records and information in electronic form held by public administrations must be preserved and converted to new media when old media become obsolete. The goal is to ensure that records and other forms of information keep their legibility, reliability and integrity and can be accessed as long as needed subject to security and privacy provisions. |
| Preservation Of Information USE 1 | The section restates the core definition of preservation of information, explaining that records must be preserved, converted to new media, and maintain legibility, reliability and integrity, without adding substantive new information beyond the definition itself. |
| Preservation Of Information USE 2 | The section mentions that the information steward is responsible for maintaining information, which aligns with the preservation concept, though it does not elaborate on media conversion or long-term preservation. |
| Preservation Policy | A preservation policy is an appropriate policy that should be applied by Member States to cope with difficulties arising when relevant information is used under different jurisdictions. It should be formulated for information related to European public services and especially for information that is exchanged across borders to ensure long-term preservation. |
| Preservation Policy USE 1 | The section distinguishes between national preservation (for nationally-owned information) and European preservation policy (for cross-border information), adding the new insight that preservation policy scope depends on whether information is strictly national or used across jurisdictions. |
| Privacy-by-design | Privacy-by-design is an approach to secure infrastructure and building blocks by embedding privacy considerations from the outset of system development. This approach ensures that privacy protections are built into the technical architecture and operational processes rather than added as an afterthought. |
| Privacy-by-design USE 1 | The section mentions that public administrations should follow the privacy-by-design approach to secure their infrastructure and building blocks, which is consistent with the definition. |
| Property USE 1 | The section uses 'property' in the legal sense referring to intellectual property rights, which is unrelated to the definition of property as a characteristic of object class members in data modeling. |
| Proportionality Principle | The proportionality principle limits EU actions to what is necessary to achieve the objectives of the Treaties. |
| Proportionality Principle USE 1 | The section restates the proportionality principle definition, explaining that it limits EU actions to what is necessary to achieve Treaty objectives. |
| Qualified Trust Services | Qualified trust services are services used in line with the eIDAS regulation to ensure the integrity, authenticity, confidentiality and non-repudiation of data. |
| Qualified Trust Services USE 1 | The section mentions ensuring 'confidentiality, authenticity, integrity and non-repudiation of information' which are the same properties that Qualified Trust Services provide, but does not explicitly mention Qualified Trust Services or add new information about them. |
| Qualified Trust Services USE 2 | The section introduces qualified preservation services as a specific application of qualified trust services under Regulation (EU) 910/2014 (eIDAS) for ensuring long-term preservation of information, extending the concept beyond its general definition to include preservation of associated electronic signatures or seals. |
| Qualified Trust Services USE 3 | The section states that qualified trust services should be used in line with the eIDAS regulation to ensure integrity, authenticity, confidentiality and non-repudiation of data, which is consistent with the definition. |
| RESTful APIs USE 1 | The section identifies API integration as a specific method for data integration, where APIs are used to extract data from source systems and load it into target systems, which extends the definition by providing a concrete use case for how RESTful APIs function in practice within data integration workflows. |
| RESTful APIs USE 2 | The section mentions API (Application Programming Interface) as an intermediary software that allows software programs to communicate with each other, which is consistent with the definition of RESTful APIs as a standard for web-based applications to exchange data, but does not add new information beyond what the definition implies. |
| RESTful APIs USE 3 | The section mentions APIs (Application Programming Interfaces) as a means to achieve application integration for sharing data between software applications, which is consistent with RESTful APIs being a standard for web-based applications to exchange data, though it does not specifically mention REST or add new information about the RESTful API concept itself. |
| RESTful APIs USE 4 | The section mentions that data integration APIs provide developers with flexibility, simplicity and speed, which is consistent with APIs being a standard for data exchange, though it does not specifically mention RESTful APIs or add new information beyond what the definition implies about APIs enabling data exchange. |
| RESTful APIs USE 5 | The section mentions that integration software connects applications using APIs, which is consistent with RESTful APIs being a standard for data exchange, though it does not specify REST or add new information about the term. |
| Relationship USE 1 | The section mentions 'relationships across tools and teams' in the context of data integration, using the term in a manner consistent with its definition as connections between entities, though it doesn't add new information beyond what the definition implies about connections. |
| Relationship USE 2 | The term 'relationships' is used in a marketing context to refer to customer relationships in a CRM system, which is unrelated to the technical definition of relationships as connections between object classes or subclasses in a data model. |
| Relationship USE 3 | The term 'relationships' is used to refer to interpersonal or organizational connections in a nonprofit context (fundraising, engagement, etc.), which is unrelated to the technical definition of relationships as connections between object classes or subclasses in a data model. |
| Relationship USE 4 | The section uses 'Subscriber Relationships' in a business context referring to connections with customers/subscribers, which is unrelated to the technical definition of relationships as connections between object classes or subclasses in a data model. |
| Relationship USE 5 | The section uses 'customer relationships' in a business context referring to interactions and connections with customers, which is unrelated to the technical definition of relationships as connections between object classes or subclasses within a domain. |
| Relationship USE 6 | The section uses 'relationships' to refer to social or business connections between people and communities, which is unrelated to the technical definition of connections between object classes or subclasses in a domain model. |
| Relationship USE 7 | The section uses 'relationships' to refer to social or business connections between people and communities, which is unrelated to the technical definition of connections between object classes or subclasses in a domain model. |
| Relationship USE 8 | The section extends the concept of relationships beyond object classes to include relationships between data points from different systems, specifically describing how logical integration maps these relationships to maintain consistency across disparate data sources. |
| Reusability | Reusability is the practice where public administrations confronted with a specific problem seek to benefit from the work of others by looking at what is available, assessing its usefulness or relevance to the problem at hand, and where appropriate, adopting solutions that have proven their value elsewhere. It is an enabler of interoperability that improves quality by extending operational use, as well as saving money and time. This makes it a major contributor to the development of a digital single market in the EU. |
| Reuse | Reuse is the practice of investigating whether existing services and information sources can be used when designing new services or revising existing ones. It applies to both services (such as basic public services and shared services) and information (such as master data from base registries, open data, and other authoritative data). |
| Reuse USE 1 | The section states that openness is an enabler of the underlying EIF principle on reusability, establishing a causal relationship between openness and reuse that extends beyond the definition of reuse itself. |
| Reuse USE 10 | The section states that considering ICT early in law-making will increase the potential for reusing existing ICT solutions, thereby reducing cost and implementation time, adding specific benefits of reuse in the legislative context. |
| Reuse USE 11 | The section mentions 'reuse of services and data' as one of the aspects that services should be governed to ensure, consistent with the definition. |
| Reuse USE 12 | The section mentions reuse as one aspect of the open-by-default principle, consistent with the definition's inclusion of reuse as part of openness. |
| Reuse USE 2 | The section elaborates that reuse requires public administrations to be open to sharing their interoperability solutions, concepts, frameworks, specifications, tools and components with others, and that it is enabled by collaborative platforms and supported by the ISA² sharing and reuse framework. |
| Reuse USE 3 | The section adds that transparency 'facilitates reuse of systems and data, and enables these to be integrated into larger systems,' connecting transparency directly to the reuse principle. |
| Reuse USE 4 | The section extensively discusses reuse of public sector data and information, emphasizing that legal interoperability and certainty through standardized licenses is essential for reuse to reach its full potential, adding specific requirements about legal frameworks and licensing that go beyond the general definition. |
| Reuse USE 5 | The section states that catalogues help others find reusable resources, which is consistent with the definition of reuse as investigating and adopting existing solutions. |
| Reuse USE 6 | Recommendation 34 advises to 'reuse, whenever possible, existing service and data components' when designing new services or reengineering existing ones, adding the specific context that reuse should be applied in the design and reengineering phases of service development. |
| Reuse USE 7 | The section identifies reuse as a driver for interoperability and specifies that European public services should reuse information and services from various sources inside or beyond organizational boundaries, with information and services being retrievable and available in interoperable formats, adding operational details about how reuse should be implemented. |
| Reuse USE 8 | The section emphasizes that base registries are designed to be 'digitally reused by others' and recommends developing interfaces for others to connect and reuse available information, adding specific implementation guidance about how reuse should be facilitated through technical interfaces and documentation. |
| Reuse USE 9 | The section elaborates on reuse as a three-part policy approach: investigating existing services for reuse when designing new ones, publishing new services for others to reuse, and aggregating identified services, providing a comprehensive operational framework beyond the basic definition. |
| Risk Management Plans | Risk management plans are documents that identify risks, assess their potential impact and plan responses with appropriate technical and organisational measures. Based on the latest technological developments, those measures must ensure that the level of security is commensurate with the degree of risk. |
| Risk Management Plans USE 1 | The section describes risk management plans as identifying risks, assessing their potential impact and planning responses with appropriate technical and organisational measures, ensuring the level of security is commensurate with the degree of risk, which is consistent with the definition. |
| Security And Privacy | Security and privacy is the guarantee that citizens and businesses interact with public authorities in a secure and trustworthy environment in full compliance with relevant regulations. Public administrations must guarantee citizens' privacy and the confidentiality, authenticity, integrity and non-repudiation of information provided by citizens and businesses. |
| Security And Privacy USE 1 | The section mentions that restrictions on open data may apply for protection of personal data, which is consistent with the security and privacy principle. |
| Security And Privacy USE 2 | The section mentions securing the right to protection of personal data and respecting the applicable legal framework for personal data held by public administrations, which is consistent with the security and privacy definition. |
| Security And Privacy USE 3 | The section uses the term 'security and privacy' and restates the definition almost verbatim, requiring that citizens and businesses interact with public authorities in a secure and trustworthy environment with guarantees of privacy, confidentiality, authenticity, integrity and non-repudiation. |
| Security And Privacy USE 4 | The section states that records must be accessed subject to security and privacy provisions, which is consistent with the definition's requirement for secure and trustworthy interaction but does not elaborate beyond this general principle. |
| Security And Privacy USE 5 | The section mentions that access to base registries should be regulated to comply with privacy and other regulations, and references security policies, consistent with the definition. |
| Security And Privacy USE 6 | The section expands on security and privacy by detailing specific implementation requirements including risk management plans, business continuity plans, data access controls, secure transfer mechanisms with encryption and time stamping, security processes during transmission and storage, and management functions for secure data exchange. |
| Security And Privacy USE 7 | The section mentions secure access to data sources as one of the issues to be addressed next to provide fully fledged public services, indicating it is a current challenge area. |
| Security Requirements USE 1 | The section mentions various security-related products and features (Cloud IAM, Security Command Center, security policies, access restrictions) but does not discuss security requirements in the specific sense of explicitly defined read/write access restrictions on object class and property pairs. |
| Security Requirements USE 2 | The section mentions implementing 'security measures to safeguard data during integration and storage,' which is consistent with the concept of security requirements as access restrictions, though it does not specifically detail read/write restrictions on object class and property pairs. |
| Security-by-design | Security-by-design is an approach to secure infrastructure and building blocks by incorporating security measures from the initial stages of system development. This approach ensures that security is an integral part of the design and implementation process rather than being retrofitted later. |
| Security-by-design USE 1 | The section mentions that public administrations should follow the security-by-design approach to secure their infrastructure and building blocks, which is consistent with the definition. |
| Semantic Interoperability | Semantic interoperability ensures that the precise format and meaning of exchanged data and information is preserved and understood throughout exchanges between parties, in other words 'what is sent is what is understood'. It covers both semantic and syntactic aspects: the semantic aspect refers to the meaning of data elements and the relationship between them, while the syntactic aspect refers to describing the exact format of the information to be exchanged in terms of grammar and format. |
| Semantic Interoperability Layer USE 1 | The section discusses semantic issues related to data organization and formatting differences, which is a related concept, but does not actually use or reference the Semantic Interoperability Layer as a specific capability or solution. |
| Semantic Interoperability Layer USE 10 | The section describes data transformation as a core feature that converts data for consumption by target applications and presents data in standardized formats, which is consistent with the concept of preserving meaning and format during data exchange, though it does not explicitly identify this as a semantic interoperability layer or add new insights about this specific architectural component. |
| Semantic Interoperability Layer USE 11 | The section describes creating rules to align customer IDs and maintain data consistency across systems, which aligns with preserving precise meaning and format of data when exchanged between different systems. |
| Semantic Interoperability Layer USE 12 | The section describes data mapping and transformation processes that align with semantic interoperability functions, specifically noting that 'different data sources may use different terminologies, codes or structures' and require 'mapping schema' and 'data transformation' to ensure 'consistency, accuracy and compatibility' - extending the concept by detailing the practical implementation steps of creating mappings and transformations to preserve meaning across systems. |
| Semantic Interoperability Layer USE 2 | The section's mention of consolidating different kinds of data (structured, unstructured, batch, and streaming) implies the need for systems to understand data formats and meanings consistently, which aligns with the definition but does not add new information about semantic interoperability itself. |
| Semantic Interoperability Layer USE 3 | The section identifies master data management tools as mechanisms that help achieve semantic interoperability by ensuring adherence to common data definitions and establishing a single source of truth, which directly supports the preservation of precise meaning when data is exchanged between systems. |
| Semantic Interoperability Layer USE 4 | The section mentions that federated solutions like data mesh require business units to present data in a centrally defined format, which aligns with the concept of ensuring data format and meaning are preserved and understood across systems, though the term itself is not explicitly used. |
| Semantic Interoperability Layer USE 5 | The section describes practical problems that the Semantic Interoperability Layer addresses, specifically the challenges of diverse data formats requiring cleaning, filtering, and reformatting before analysis, and the need for consistent access to siloed data across different business processes and applications. |
| Semantic Interoperability Layer USE 6 | The section describes a common data model that enables all integration processes to 'speak the same language' and allows services involving business objects to be easily created, which extends the definition by providing a specific implementation approach (common data model) and concrete business benefits (increased business visibility through event subscription) that are not explicitly stated in the definition. |
| Semantic Interoperability Layer USE 7 | The section describes data transformation processes that convert and reorganize data into suitable formats, and mentions cleansing, sorting, and enrichment to make data ready for use. These transformation activities serve the function of preserving meaning and ensuring correct interpretation across systems, which is the core purpose of a semantic interoperability layer, though the section presents these as discrete integration steps rather than as a unified layer. |
| Semantic Interoperability Layer USE 8 | The section describes data integration as a process where a main server intakes, aggregates, enhances and combines data from various sources into a unified set. While this involves data exchange between systems, the text focuses on technical data aggregation mechanics rather than addressing how the precise meaning and format of data is preserved and correctly understood across different systems, which is the core concern of the Semantic Interoperability Layer. |
| Semantic Interoperability Layer USE 9 | The section discusses data standardization and quality assurance before making data available to consuming applications, but this refers to general data quality processes rather than the specific capability of preserving precise meaning and format through shared data models or semantic transposition mechanisms. |
| Semantic Interoperability USE 1 | The section adds that semantic interoperability (preserving meaning) is particularly relevant in multilingual contexts where information is exchanged across language boundaries, extending the concept to include language translation challenges. |
| Semantic Interoperability USE 2 | The section provides the definition of semantic interoperability itself, explaining that it ensures precise format and meaning of exchanged data is preserved and understood, covering both semantic aspects (meaning of data elements) and syntactic aspects (exact format in terms of grammar and format). |
| Semantic Interoperability USE 3 | The section mentions 'semantic' as one of the layers that governance should cover, consistent with the definition. |
| Semantic Interoperability USE 4 | The section notes that interoperability programmes have started to address interoperability at the semantic level more recently, indicating a temporal evolution in addressing this layer. |
| Semantic Interoperability USE 5 | The section lists 'SEMIC' (Semantic Interoperability Centre) as one of the support centre options available on the portal, which is consistent with the concept of semantic interoperability but does not add new information about the term itself. |
| Service Level Agreements (SLAs) | Service level agreements are agreements that complement interoperability agreements by addressing operational matters. They are instruments used to formalise mutual assistance, joint action and interconnected business processes as part of service provision, and impose requirements for aspects of interoperability including quality, scalability and availability of reusable building blocks. |
| Service Level Agreements (SLAs) USE 1 | The section mentions SLAs as agreements that complement interoperability agreements and address operational matters, consistent with the definition. |
| Service Level Agreements (SLAs) USE 2 | The section mentions SLAs as instruments to formalise mutual assistance, joint action and interconnected business processes, which is consistent with the definition. |
| Service Level Agreements (SLAs) USE 3 | The section states that governance should impose requirements for aspects of interoperability 'translated into clear service level agreements (including on interoperability),' adding specificity that SLAs should explicitly address interoperability. |
| Service Orientation | Service orientation is the conceptual model upon which public services are conceived, meaning that the relationship between service providers and service consumers must be clearly defined. It involves finding instruments to formalise mutual assistance, joint action and interconnected business processes as part of service provision. |
| Service Orientation USE 1 | The section directly restates that service orientation is the conceptual model upon which public services are conceived and requires clearly defined relationships between service providers and consumers. |
| Shared Services | Shared services are reusable services like electronic identification and electronic signature that may be provided by the public sector, the private sector or in public-private partnership (PPP) models. |
| Shared Services USE 1 | The section identifies shared services as a type of reusable service, providing examples like electronic identification and electronic signature, and specifies they may be provided by public sector, private sector, or public-private partnership models, adding detail about provision models. |
| Single Point Of Contact | A single point of contact is an access point made available to users to hide internal administrative complexity and facilitate access to public services, for example when multiple bodies have to work together to provide a public service. |
| Single Point Of Contact USE 1 | The section states that a single point of contact should be made available to hide internal administrative complexity and facilitate access to public services, which matches the definition. |
| Standardisation Process | The standardisation process is the formal procedure for developing and establishing standards and specifications. Active participation in this process by public administrations helps mitigate concerns about delays, improves alignment of standards with public sector needs, and enables governments to keep pace with technological innovation, particularly when no suitable standards exist for specific domain needs. |
| Standardisation Process USE 1 | The section adds new information by explaining that active participation in the standardisation process is particularly important when no suitable standards exist for specific domain needs, and that such participation helps public administrations keep pace with technological innovation. |
| Standards And Specifications | Standards and specifications are fundamental requirements and technical documents that enable interoperability between systems. They must be identified based on specific needs, assessed using standardized and transparent methods, implemented according to plans, monitored for compliance, and documented in open catalogues. Their management involves six key steps: identifying candidates, assessing them fairly, implementing them with guidelines, monitoring compliance, managing changes, and documenting them systematically. |
| Standards And Specifications USE 1 | The section discusses specifications in terms of their openness and maturity, consistent with the need to assess and select appropriate standards and specifications. |
| Standards And Specifications USE 2 | The section mentions that EU standards and specifications exist in DIFs and should be applied more widely, consistent with their role as fundamental requirements enabling interoperability. |
| Standards And Specifications USE 3 | The section mentions catalogues of standards, specifications and guidelines as a type of catalogue, which is consistent with the definition but does not add new information about standards and specifications. |
| Standards And Specifications USE 4 | The section emphasizes that robust, coherent and universally applicable information standards and specifications are needed to enable meaningful information exchange among European public organisations, drawing a parallel to how technical standards fostered technical interoperability. |
| Standards And Specifications USE 5 | The section states that interoperability agreements usually include standards and specifications at semantic, technical, and sometimes organisational levels, consistent with the definition. |
| Standards And Specifications USE 6 | The section provides new operational details about managing standards and specifications, specifically outlining six concrete steps for their lifecycle management: identifying candidates, assessing them using standardized methods, implementing according to plans, monitoring compliance, managing change, and documenting in open catalogues. |
| Subsidiarity Principle | The subsidiarity principle is a requirement that EU decisions be taken as closely as possible to the citizen. In other words, the EU does not take action unless this is more effective than the same action taken at national level. |
| Subsidiarity Principle USE 1 | The section restates the subsidiarity principle definition, explaining that EU decisions should be taken as closely as possible to the citizen and that the EU does not take action unless more effective than national action. |
| Technical Gateway USE 1 | The section mentions 'API Gateway' as a product for developing, deploying, securing, and managing APIs with a fully managed gateway, but this refers to an API management tool rather than a gateway that performs data conversions between different systems as defined. |
| Technical Interoperability | Technical interoperability covers the applications and infrastructures linking systems and services. It includes interface specifications, interconnection services, data integration services, data presentation and exchange, and secure communication protocols. |
| Technical Interoperability USE 1 | The section specifies that technical design choices, such as data representation in electronic databases, should not limit the ability to support different languages, adding a multilingual requirement to technical interoperability considerations. |
| Technical Interoperability USE 2 | The section recommends developing interfaces with base registries and publishing semantic and technical means for others to connect, providing specific implementation guidance for achieving technical interoperability through interface development and documentation. |
| Technical Interoperability USE 3 | The section draws an analogy between technical interoperability and semantic interoperability, noting that just as technical standards fostered technical interoperability (e.g., network connectivity) for decades, information standards are now needed for semantic interoperability. |
| Technical Interoperability USE 4 | The section restates the definition by listing the same components: interface specifications, interconnection services, data integration services, data presentation and exchange, and secure communication protocols. |
| Technical Interoperability USE 5 | The section mentions 'technical' as one of the layers that governance should cover, consistent with the definition. |
| Technical Interoperability USE 6 | The section mentions the diversity of technologies used as one of the barriers to exchanging information and collaborating electronically, which relates to technical interoperability challenges. |
| Technological Neutrality | Technological neutrality is an approach where public administrations focus on functional needs and defer decisions on technology as long as possible in order to minimise technological dependencies, to avoid imposing specific technical implementations or products on their constituents and to be able to adapt to the rapidly evolving technological environment. |
| Technological Neutrality USE 1 | The section restates the definition of technological neutrality, emphasizing that public administrations should focus on functional needs, defer technology decisions, minimize dependencies, avoid imposing specific implementations, and adapt to technological evolution. |
| Test System Environment USE 1 | The section describes test environments that are 'very much like the production environment' and are used for testing critical data integration processes and non-regression testing, adding that these environments require test scenarios to be written and may need specialized integration testing solutions or APIs to inject data and record test scenarios, which extends beyond the basic definition by specifying the technical requirements and tooling needed for such environments in the context of data integration. |
| Transparency | Transparency in the EIF context refers to enabling visibility inside the administrative environment of a public administration, ensuring availability of interfaces with internal information systems, and securing the right to the protection of personal data. It is about allowing other public administrations, citizens and businesses to view and understand administrative rules, processes, data, services and decision-making. Interoperability depends on ensuring the availability of interfaces to systems and the data they handle. |
| Transparency USE 1 | The section adds that open data should be published with clear licences to allow better scrutiny of administrations' decision-making processes and realise transparency in practice. |
| Transparency USE 2 | The section provides the full definition of transparency in the EIF context, explaining its three components: enabling visibility, ensuring interface availability, and securing data protection rights. |
| Transparency USE 3 | The section lists transparency as one of the ways to assess the value of interoperable European public services, consistent with the definition's emphasis on visibility and understanding. |
| Transparency USE 4 | The section mentions transparency as one of the goals stimulated by releasing machine-readable data for reuse, consistent with the definition's emphasis on visibility and openness. |
| Transparency USE 5 | The section mentions transparency as one aspect of the open-by-default principle, consistent with the definition's inclusion of transparency as part of openness in public service delivery. |
| User-centricity | User-centricity is the principle that users' needs and requirements should guide the design and development of public services. Users of European public services are meant to be any public administration, citizen or businesses accessing and benefiting from the use of these services, and their needs should be considered when determining which public services should be provided and how they should be delivered. |
| User-centricity USE 1 | The section extends the concept of user-centricity by stating that openness means empowering citizens and businesses to get involved in the design of new services, contribute to service improvement, and give feedback about quality of existing public services. |
| User-centricity USE 2 | The section restates that user-centricity means users' needs and requirements should guide the design and development of public services, consistent with the definition. |
| User-centricity USE 3 | The section states that the number of languages should be decided based on users' needs, which is consistent with the user-centricity principle of considering users' needs in service design. |
| User-centricity USE 4 | The section states that simplification should respond promptly and with high quality to users' requests, adding the new dimension that administrative simplification is a means of achieving user-centric service delivery through responsiveness and quality. |
| User-centricity USE 5 | The section refers to 'end users' needs' that must be met through integrated public service provision, consistent with the user-centricity principle. |
Key Concepts in Chapter 3 of Knowledge Representation Logical, Philosophical, and Computational Foundations
Key Concepts in Chapter 3 of Knowledge Representation Logical, Philosophical, and Computational Foundations