General Information

OOP Enabling Infrastructure
EMREX is a solution for electronic transfer of student records between higher education institutions in Europe. The biggest benefit of EMREX is an increased availability, quality and reliability of information about student records of achievement information.
Short summary
The EMREX field trial aims at testing new ways to make the administration of student mobility easier, promoting higher attainment level to student mobility in higher education, encouraging more effective recognition of prior learning and avoiding overlapping studies. In the first phase the trial is set-up between four Nordic countries (Norway, Finland, Denmark and Sweden) and Italy.
The electronic transfer of the student achievement is initiated by a student’s approval through the Student Mobility Plug-in (SMP), installed in the student web/ the student portal at the home university. The student records are then fetched from the National Contact Point (NCP) of the host university in question.
EMREX is neither an IT project as such, nor is the project aiming at developing a new system. The solution utilizes existing infrastructure (e.g. user authentication, authorization, data warehouses etc.).

Because EMREX is a decentralized system, there are no major components that new partners can reuse out of the box. The EMREX project does provide some modules, plugins and examples that can be used and built upon, however there are a couple of issues that cannot be solved in a general way:

1. Authenticating a student: Each country has their own way of authenticating a student in their system. In Norway there are Feide and ID-porten, Finland has Haka, Sweden has Swamid and so on. Therefore, the EMREX project cannot make a complete login module and distribute this, as each country solves this in different ways.

2. Fetching results for a student: Each country/higher education institution (HEI) has their own student information systems. Some countries have national data sources that can provide this information. Therefore, there is not one unified way of fetching results from these systems. The EMREX-system is dependent on connecting to an existing solution that can fetch results for a given student at a given HEI. The preferred solution is to build a REST service for each student information system involved, that provides ELMO formatted data.

3. Storing results for a student: Each country/HEI has their own student information systems. So there is no standard way of storing the result data the EMREX fetches into
the existing student system. When the EMREX client returns a set of results for a student, these must be stored in some local system, as EMREX does not store data in itself.

Start date
Cross-border EU
Nature and status of project
Pilot Case


Political commitment
The project’s title is: “Field trial on the impact of enabling easy mobility on recognition of external studies” (EACEA-388499).
The EMREX project has received funding from the ERASMUS+ program, more specifically from Key Action 3: European policy experimentation

The results and conclusions from the policy experimentation will be evaluated by the University of Warsaw as part of the project. The main goal of the policy is to increase student mobility and recognition rates of academic degrees. The success will be evaluated using both statistical analyses and qualitative measures.


Type of data sharing
Actual data
Data handler
Stakeholder name
Stakeholder category
Stakeholder Role
Data provider
Kind of data
Transcript of records
Stakeholder name
Stakeholder category
Stakeholder Role
Data subject
Kind of data
Transcript of records
The following diagram shows in detail the data flow for a student wanting to import results from two different result providers (for instance, higher education institutions) in the same country.
It is up to each implementer to decide whether the SMP will run as a standalone service, or embedded into their client. The EMREX project provides a SMP library which can be used out-of-the-box as a standalone service.
The same remark applies to the result provider(s), the implementation is very much dependent on the underlying system(s).
Image upload