EMDIS message: NO_RES

Description Service can not be performed

The NO_RES message indicates the requesting hub that a service can not be performed. The reason may differ depending on the type of request and the direction of the NO_RES.

EMDIS Fields

Field description (WMDA dictionary field) EMDIS field code Required Field Type
Sending EMDIS registry (REG_SND) REG_SND Optional N4
Receiving EMDIS registry (REG_RCV) REG_RCV Optional N4
Patient identification (Patient Identification) P_ID Required A17
Donor identification (Donor Identification ( to be replaced by GRID)) D_ID Required A17
Global registration identifier for donors (old format, deprecated).For information regarding GRID in the new format please see field D_GRID. (GRID) GRID Optional A19
Reference code (REF_CODE) REF_CODE Required A15
Type of request (REQ_TYPE) REQ_TYPE Required A3
Reason why a service cannot be performed (Request denial reason) REASON Required A3
Remark (REMARK) REMARK Optional A120
The unit identification assigned by the hub. It may be the same as the local ID (CB_LOCAL_ID) (Cord Blood Unit Identification) CB_ID Optional A17
Global registration identifier for donors (GRID) D_GRID Optional A19

The reason codes belong to the data dictionary and may contain for:

TC → Hub → DC

For a SMP_REQ – i.e. no SMP_RES can be sent:

'BCC’: bad clinical condition of patient
’FND’: donor found
’LAB’: laboratory problem / typing failed / not enough sample 
’NSP’: no sample received
’OLD’: sample too old
’PDC’: patient deceased
’STP’: search stopped
’TRX’: patient already transplanted
’OTH’: other reason
DC → Hub → TC

The same reasons as D_STAT_REASON plus

’EX’:  (expired)
’MM’:  (HLA mismatch)

Several NO_RES / *_RES for a single request are allowed since they can be considered as an update to the result.

The NO_RES message is neither a replacement for nor redundant to MSG_DEN or WARNING. The latter must be issued immediately after processing a message. The NO_RES may only be issued after a certain period of time.

Furthermore, a NO_RES is not a replacement for a REQ_CAN or RES_REM message. Generally, REQ_CAN has to be used by the hub that sent the request, NO_RES has to be used by the hub that received the request. The exception is the SMP_REQ message. Depending on the status of the request, a NO_RES can be sent by sender or recipient of the request. Here, a NO_RES can only be used if a result is expected by the recipient (i.e. NO_RES can be sent by DC only before sending SMP_ARR and/or IDM_RES and NO_RES can be sent by TC only after receiving SMP_ARR and/or IDM_RES. Incorrectly received NO_RES and REQ_CAN messages can be rejected. Please see also TYP_REQ and SMP_REQ message flow.