Clarification on the nomination workflow and the status field

[jiripetrzelka]

I have a couple of questions regarding the flow chart from MBR on nominations, which I paste below with two arrows added at the top of the chart):

1. How is the sending institution supposed to distinguish the "Pending: sent but not yet delivered" phase from the "Pending: delivered" phase? Am I right that the first phase corresponds to an empty imobilities response for the given omobility-id, while the latter state corresponds to a non-empty response with the "status" element set to "pending"?

2. I assume the "Verified: accepted" phase corresponds to the "verified" status and the "Verified: rejected" phase corresponds to the "rejected" status. I suggest to rename the "verified" status to "accepted".

3. Look at the orange arrow I added to the chart. Am I right that once the receving institution rejected the nomination, it should start detecting any change in any of the omobilities fields and assume a transition directly to the "Pending: delivered" phase once any change is detected (usually by means of omobilities CNR)?

4. Look at the green arrow I added to the chart. A nomination has been accepted but a change in omobilities response is detected. Examples of changes:

   • last name (due to marriage).
   • iia-id change (due to mistake).
   • status changed to cancelled.
   • sending-academic-term-ewp-id changed due to extension.

In this case, do we transition to the "Pending: delivered" phase and does the coordinator at the receving institution have to verify the nomination again, or is the sending institution required to make some fields in the omobilities response immutable once the nomination has been accepted? If so, what is the set of immutable fields whose change should be considered an error and reported to the Stats Portal?

[janinamincer-daszkiewicz]

How is the sending institution supposed to distinguish the "Pending: sent but not yet delivered" phase from the "Pending: delivered" phase?

The easiest approach is to look at the response to CNR: 200 means that nomination is Pending but delivered.

Am I right that the first phase corresponds to an empty imobilities response for the given omobility-id, while the latter state corresponds to a non-empty response with the "status" element set to "pending"?

This approach is better, but requires more effort from the sending HEI. I would leave it to the local system whether they implement it in an easier way or more elaborated.

I assume the "Verified: accepted" phase corresponds to the "verified" status and the "Verified: rejected" phase corresponds to the "rejected" status.

Yes

I suggest to rename the "verified" status to "accepted".

What is the opinion of the others?

Look at the orange arrow ...

Yes

Look at the green arrow ...

Yes, with the exception of 'status changed to cancelled' - this one does not need confirmation (verification) by the receiving HEI (see https://github.com/erasmus-without-paper/ewp-specs-api-omobilities).

[jiripetrzelka]

Thank you for the answers, Janina.

Concerning the status field, my intention was to have the naming in line with the MBR. However, we should also think about the division of the nomination and the application phase here. Currently, the verified status is bound only to the nomination being "formally correct with the cooperation conditions": https://github.com/erasmus-without-paper/ewp-specs-api-imobilities/blob/a2ec90f80b08028ff8778282ce3ec8fae04b633f/endpoints/get-response.xsd#L158-L167

But even if the student's nomination is "formally" correct, the mobility can later be refused during the application process, for example because the receiving institution finds out some insufficiency in student's academic performance. Should the receiving institution set the status to "refused" in this case? I suppose it should but if the result of the application process is be communicated through this API, it would be more consistent if the successful application process would also be communicated. Status "verified" would then correspond to the formal verification of the nomination and a new status "accepted" would mean that not only is the nomination formally valid but the student has been successful in the application phase as well.

[janinamincer-daszkiewicz]

Should the receiving institution set the status to "refused" in this case?

The receiving institution should set state to Rejected, see MBR, page 8, Step 5: "In rare cases, the application is rejected if the student does not meet the enrolment qualifications".

if the result of the application process is be communicated through this API, it would be more consistent if the successful application process would also be communicated.

Such step is not foreseen in MBR. If the status verified is not later replaced by Rejected, it stays verified (accepted).

I will ask RMs for confirmation.

[jiripetrzelka]

The receiving institution should set state to Rejected, see MBR, page 8, Step 5: "In rare cases, the application is rejected if the student does not meet the enrolment qualifications".

Then I suggest to be more clear about it in the specification and change the annotation of this element to "The nomination or the application has been rejected by the receiving HEI." https://github.com/erasmus-without-paper/ewp-specs-api-imobilities/blob/38914aac38ec9d98fbbc441bfbad5943ec4bed76/endpoints/get-response.xsd#L168-L174

Such step is not foreseen in MBR. If the status verified is not later replaced by Rejected, it stays verified (accepted).

Ok, but using this logic we should remove statuses "live" and "recognized" in omobilities because these are processes that are connected to the application phase, not the nomination phase. Or am I mistaken and the MBR describes the "live" and "recognized" phases somewhere?

[janinamincer-daszkiewicz]

Or am I mistaken and the MBR describes the "live" and "recognized" phases somewhere?

You are not mistaken, however these statuses already exist in the specification. The idea was to make the smallest set of necessary changes to the specification.