EMDIS message: SMP_REQ

Name SMP_REQ
Description Sample request

With this message type, the Registry is requesting Samples to allow them to perform further testing.

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
Request date (Request date) REQ_DATE Required D8
Reference code (REF_CODE) REF_CODE Required A15
First product required (Blood sample requirements (tube type)) PROD1 Required A10
First product quantity per tube (see also NBTx) (Blood sample requirements (amount)) QU1 Optional N4
Number of tubes for the first product (Blood sample requirements (amount)) NBT1 Optional N2
Second product required (Blood sample requirements (tube type)) PROD2 Optional A10
Second product quantity per tube (see also NBTx) (Blood sample requirements (amount)) QU2 Optional N4
Number of tubes for the second product (Blood sample requirements (amount)) NBT2 Optional N2
Third product required (Blood sample requirements (tube type)) PROD3 Optional A10
Third product quantity per tube (see also NBTx) (Blood sample requirements (amount)) QU3 Optional N4
Number of tubes for the third product (Blood sample requirements (amount)) NBT3 Optional N2
Fourth product required (Blood sample requirements (tube type)) PROD4 Optional A10
Fourth product quantity per tube (see also NBTx) (Blood sample requirements (amount)) QU4 Optional N4
Number of tubes for the fourth product (Blood sample requirements (amount)) NBT4 Optional N2
Earliest date of sample reception (REC_DATE1) REC_DATE1 Required D8
Latest date of sample reception (REC_DATE2) REC_DATE2 Optional D8
Weekdays acceptable for sample reception (Acceptable sample reception days) ACC_DAYS Optional B7
Institution receiving sample (�ship-to� address) (Receiving institution) INST_SMP_SENT Required A10
Institution paying (Invoice institution) INST_PAY Required A10
Urgent request (Urgency) URGENT Optional A1
Acknowledgement ID (Acknowledgment ID) ACK_ID Optional A17
Remark (REMARK) REMARK Optional A120
Global registration identifier for donors (GRID) D_GRID Optional A19

Only one SMP_REQ can be open for a patient / donor pair (please see also the General section about duplicate requests).

The fields ”earliest and latest date of sample reception” represent the lower and upper limit of a period of time in which the blood sample has to be received. If the second date is missing the sample may be received any time after the first date.

The field ACC_DAYS is a binary field with position 1 corresponding to Monday and position 7 corresponding to Sunday. A set bit means acceptable day, an unset bit means not acceptable day e.g. 1110000 means acceptable days for reception are Monday, Tuesday and Wednesday, not acceptable days are Thursday, Friday, Saturday and Sunday. The default value is 1111100 (accept all working days).

The address INST_SMP_SENT must not be a P.O. box, since couriers often need a signature upon delivery.

The SMP_REQ is the only request message where the result also comes from the transplant centre. The quantity for the first product is optional when requesting DNA from a cord blood unit. In all other requests, the quantity fields for any of the corresponding product fields are required if a product is requested.

Number of tubes requested in a sample request or marrow request: The maximum amount of material, requested in one sample request or pre-collection sample request, is 100 ml, if not stated otherwise in the national rules. If the number of tubes is unassigned, not given in the request, the default value number of tubes is one.

Duplicate requests on the same day: This issue becomes particularly difficult if SMP_REQs are concerned - sometimes users want to ”correct” their previous request (i.e. forgot to request quantity and product). The correct way of doing this is to cancel the erroneous request first and send the second one later. However, this procedure might also confuse if not carried out on the same working day. In doubt a phone call helps sorting things out.