Architecture and Data Model¶

Structural Overview¶

The DEQAR data model has been designed around four main entities: registered quality assurance agencies, higher education providers, their educational programmes, and external quality assurance reports.

Registered agency users are invited to submit and manage information on external quality assurance reports, including information about the particular programme described in the report, if applicable.

Information on higher education providers is managed by the EQAR Secretariat. The information on higher education institutions is largely based on data from ETER/OrgReg. The information on other providers is provided by QA agencies and managed by the EQAR Secretariat.

EQAR continues to collect and manage agency data, through its register, as well as country data in its knowledge base. These will be linked to report and provider data in DEQAR. To support this, DEQAR also includes a country entity, which contains information on the official external quality assurance regime in the countries/higher education systems of the European Higher Education Area (EHEA).

Functional Overview¶

DEQAR supports three core activities:

• Submission of report records: agencies submit report records and PDF files, meeting defined criteria, using one of three methods:

  • as individual records via webform
  • as batch CSV file via webform
  • as JSON using an API

• Administration of records: data is ingested and records are created, stored and managed by EQAR staff and agencies over the longer term. Agencies may update report records already in the system and track their own activity.

• Search and discovery of information: records are published on a public web interface for search, retrieval and export or download by end users. There is also a public API available to all registered users; this allows users to embed DEQAR search interface in their local site.

Role of Standards and Identifiers¶

As DEQAR aggregates data from different sources, several challenges are faced:

1. to keep the same data from different sources synchronised (e.g. the same provider may be described differently by different agencies);
2. to try to avoid duplication;
3. to identify already existing records for update if necessary.

Hence, to ensure consistency and stability, DEQAR uses a set of standard identifiers, which are provided by the system for each object. In several cases, agencies are able to provide their local or national identifiers for objects in order to ease their internal workflows. Objects are identified in the following ways:

As a rule, objects already in the system should be identified to facilitate linking up. In other words:

1. The agency responsible for the report and the activity to which it belongs must be identified with any submission.
2. An identifier must be provided for each provider (higher education institution or other provider) covered by the report. If provider records do not yet exist in DEQAR, information on them must be provided separately before reports can be submitted.

3. In the case of reports and programmes, agencies are encouraged to provide local identifiers with each new submission of data in order to facilitate subsequent linking:

   • For reports, the agency can provide a local identifier with each new report submitted; the local identifier may be used to later update the report using CSV or JSON and may also help each agency to synchronise its local system with DEQAR.
   • For programmes, the first time an agency provides information on a programme to DEQAR, a local (or national) identifier can be submitted along with data on the programme; the identifier can later be used by the agency for any report on the same programme.

The identification of each type of object is explained in detail below.

Agency Identifiers¶

Authentication is required before the submission and update of data and files. Thus, the agency responsible for each report can be identified automatically by the system. In some cases, an agency may serve as a proxy agency for a creating agency, submitting and managing data on its behalf (as in the case of umbrella organisations). In this case, the creating agency’s unique acronym or DEQAR Agency ID (which can be found in the administrative interface) must be provided as the source of identification. For this reason, identification of the creating agency is required for each object when using CSV and JSON.

(See Submission Object Data Elements: Agency.)

Activity Identifiers¶

DEQAR also assigns IDs to each agency's activities (see list on the agency's public register entry under Activities within the scope of ESG). These identifiers, which can be found through the administrative interface, should be used to indicate the type of report in each CSV or JSON object.

Alternatively, an agency may wish to use its own local activity identifiers; in this case, the agency should supply through their local identifiers through the administrative interface before using them for submission.

Note: Only one identifier should be provided for the assigned activity.

Please note that any changes to the agency's activities, other than purely editorial or technical changes, must be made through Substantive Change Reports.

(See Submission Object Data Elements: Activity.)

Report Identifiers¶

We strongly recommend that agencies provide a local identifier with each report submitted. This will allow for subsequent updates to the record and will ease synchronisation with the agency's local system. Report local identifiers will be stored and can serve to identify records for updates/resubmissions. DEQAR will also automatically generate a DEQAR ID for each newly submitted report; this will be returned to agencies as part of the response object. The DEQAR ID can be used for updates/resubmission as an alternative to local identifiers.

(See Submission Object Data Elements: Report Identifier.)

Provider Identifiers¶

Providersi must be identified in report submissions using one of the following identifiers. This allows the system to automatically link report data to existing institution records.

• DEQARINST IDs: DEQAR automatically generates a so-called "DEQARINST ID" for each provider record that is created in the system. These can be found through the administrative interface. (They are also returned to the agency as part of the response object after each successful submission.) Ideally, each registered agency will store the DEQARINST IDs for providers treated in their reports. These are recommended for use in each submission.

• ETER IDs: DEQAR creates and updates records on higher education institutions from many European countries from the ETER/OrgReg database every 24 hours. The ETER ID for these institutions can be found through the administrative interface. The ETER IDs may be stored and used by agencies for submission as an alternative to the DEQARINST IDs.

• Local identifiers: Agencies may also create and store local identifiers for providers. These can be used for submission as an alternative to the DEQARINST IDs if supplied in advance. Each agency can provide these individually through the administrative interface or these can be provided in bulk to the EQAR Secretariat. Local identifiers are managed by one agency independently and can only be used by that agency.

• Other identifiers: DEQAR allows to store additional national, European or other identifiers. These can be used for submission as an alternative to the DEQARINST IDs and are available to all agencies; other identifiers available in the system can be consulted through the administrative interface. In order to ensure uniqueness and stability these are managed by the EQAR secretariat, but agencies are invited to provide identifiers to EQAR that might be useful to other agencies.

  Other identifiers are always used in combination with a resource indication, denoting the type of identifier, in combination with which they are unique. EQAR maintains a background list of other trusted identifiers. Agencies and other stakeholders can contact EQAR if they want to provide other identifiers.

Note: If an agency cannot locate an existing provider record in DEQAR (and therefore cannot provide either the DEQARINST ID, ETER ID or local identifier), then it will need to provide data separately before being able to submit reports on that provider.

(See Provider Data and Submission Object Data Elements: Provider(s).)

Programme Identifiers¶

DEQAR will not synchronise data on programmes; however, if a local or national identifier is provided at the time of submission, this will be stored in the system. The agency can use the programme identifier if it would like to simply re-use the existing programme data for subsequent reports. It is thus recommended to provide a unique programme identifier if available.

(See Submission Object Data Elements: Programme Identification.)

Other Identifiers and Codes¶

Countries are identified via the ISO 3166-1 standard. Both two-letter (alpha-2) or three-letter (alpha-3) codes can be used.

As some EHEA countries consist of several sub-national higher education systems with separate legislation on higher education, those sub-systems are represented as distinct “countries” in DEQAR to provide accurate system-level information. Sub-national systems have no alpha-3 code assigned but can be identified by the following non-standard extended alpha-2 codes:

Language codes are accepted in ISO 639-1 or ISO 639-2/B format.

Finally, DEQAR provides DEQAR IDs for standard values used for Report Status and Report Decision. These can be provided instead of the equivalent string values in CSV or JSON objects.

(See Submission Object Data Elements: Report Details.)

Building Provider Records¶

DEQAR has two basic workflows for creating and updating provider records:

1. records on higher education institutions from most European countries are created and updated from the ETER/OrgReg databases (available through Research infrastructure for research and innovation policy studies - RISIS or European Tertiary Education Register - ETER;
2. records on higher education institutions located in countries not covered by ETER/OrgReg and records on other providers are created by EQAR from scratch based on data submitted by an agency.

Providers Listed in ETER/OrgReg¶

The European Tertiary Education Register (ETER) is a European-level database providing data on higher education institutions' (HEI) activities and outputs. ETER collects data from national statistics authorities and ministries in charge of higher education matters in Europe. Linked to ETER, the Register of Public Sector Organisations (OrgReg) provides a reference list of higher education institutions in all EU Member States, EEA-EFTA countries (Iceland, Liechtenstein, Norway and Switzerland), candidate countries (Albania, Bosnia and Herzegovina, Kosovo, Montenegro, North Macedonia, Serbia and Turkey) as well as the United Kingdom.

DEQAR updates records from ETER/OrgReg every 24 hours. These records serve as base set of records on European higher education institutions in DEQAR. DEQAR stores the following ETER data on institutions:

• ETER ID
• official name
• English name
• acronym
• country
• city (when available)
• latitude/longitude (when available)
• QF-EHEA levels
• institution website

ETER/OrgReg data is managed according to the following principles:

1. DEQAR uses ETER/OrgReg data as a “single source of truth”.
2. If an agency would like to propose a correction or change of ETER/OrgReg-based data, the EQAR secretariat should be contacted. After reviewing, the EQAR Secretariat will make these changes in OrgReg and they will be reflected in DEQAR automatically afterwards.
3. Alternative names and local identifiers may be added to ETER-based records and managed by agencies through the administrative interface (see Institution Identifiers above).
4. Added information and updates in ETER/OrgReg are carried through to records in DEQAR from the next daily update.

Providers Not in ETER/OrgReg¶

For data not existing in ETER/OrgReg, a new record must be created based on data submitted by an agency. In the majority of cases these providers will be higher education institutions which are either based in countries not covered by ETER/OrgReg or other providers.

In order to ensure data quality and avoid record duplication, provider data is always manually screened by EQAR staff and thus needs to be submitted separately, before reports are uploaded for an institution. The minimum data needed to create a record is:

• official name
• country where the provider is based
• provider website (URL)

Provider data is managed as follows in this case:

1. As a general policy, DEQAR keeps provider data, including those submitted directly by an agency, stable and unchanged.
2. If an agency would like to propose a correction or change of data for more than 5 providers, we are inviting agencies to add the information on the changes in the tab “Update institutions” or “Update other providers” in the templates available here respectively and send it to deqar@eqar.eu. For changes of data on less than 5 providers, please contact the EQAR secretariat with a description of the change (i.e. a new name, closure date of the provider, new website etc.) at the above mentioned email address.
3. Local identifiers may be added to any provider record and managed by agencies through the administrative interface (see Provider Identifiers above).
4. The EQAR Secretariat reserves the right to adapt records based on the information that we receive through agencies and other sources.

(See Provider Data Elements.)

Hierarchical and Historical Provider Relationships¶

In those cases when quality assurance reports are produced for different organisational levels of a provider, DEQAR collects and stores data on both entities and establishes a hierarchical link between them. This may be the case of a higher education institution and its "child" faculties, or of a provider and its "parent" group. Another example could be that a university found another provider through which it organises labour market focused short courses.

In the public search interface, quality assurance reports produced for different levels in the same provider will cascade -- i.e. records on child providers will include the reports produced on the parents; records on parent providers will show the reports produced on its children.

For higher education institutions, DEQAR bases its hierarchical links on information taken from ETER/OrgReg. If any agency would like to propose an additional structural link between two or more providers or institutional levels, then the proposed link can be provided individually or in a longer list to the EQAR secretariat.

Please bear in mind that the main higher education institution unit is the university and that EQAR encourages agencies to upload reports under the university’s record rather than the smaller units. Further information on the definition of higher education institutions can be found under defining institutions.

DEQAR also stores information on historical changes in the structure of providers, e.g. mergers, splits, spin offs and absorptions. This allows users to view historical records in the correct context. It will also facilitate the search and discovery of current providers.

Note: historical changes in the structure of agencies will also be stored and presented online.

Presenting Historical Data¶

DEQAR not only presents information on the recent ESG-compliant quality assurance activities, but also records an historical "trail" of the these activities since 2008, a date which marked the launch of EQAR. Thus DEQAR stores both current and past valid reports on each provider and both are presented to end users through the search interface. Historical data are especially important for DEQAR users from recognition offices or information centres.

Agencies should thus upload information on all external QA procedures that were completed during their registration period, including those reports that are already "expired" and all external QA reports that are still valid.

DEQAR also captures historical changes in the status, profile of agencies and providers, e.g. name changes, changed activity, physical relocation and changes in the organisational structure (see above). Changes in the quality assurance regulations within EQAR countries are also captured. Historical data can be queried by end users, e.g. users can also find a provider under a previous name.

Any request for an update to a provider record may be submitted to the EQAR secretariat for review. (It is part of the daily work of the EQAR secretariat to keep the registry of agencies and countries complete and up to date. Changes to the agency's activities, other than purely editorial or technical changes, must be made through Substantive Change Reports. Nevertheless, in case there is a concern about the recorded status, location or activities of a specific agency or of the quality assurance regime in a particular country, questions can also be directed to the EQAR secretariat.)