...
- HLA changes of a patient must not cancel requests for the patient. The requests remain under full responsibility of the patient registry.
- 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.
- MSG_DEN, WARNING and REMARK content from the message response messages as well as the TXT_MSG messages have to be presented to the responsible user (search coordinator) by the local Match-Connect administrator in an appropriate manner.
- Don’t send information multiple times - WARNINGs are to be used if it happens in order to find errors.
- A donor can have only one open request at a time. Multiple *_REQ messages for the same patient-donor-pair are therefore invalid and have to be rejected by the receiving registry. If a request has to be corrected, it has to be cancelled (REQ_CAN) and subsequently re-requested ( *_REQ)
- Multiple *_RES or *_ARR messages for the same request (i.e. the same message ID) are regarded as updates and therefore should be different from the previously sent one.
- Do not change IDs of patients, donors or addresses: use the primary keys of your database tables prefixed by your unique registry code (in EMDIS known as hub code) as Match-Connect IDs.
- Only use the specified (see Data Dictionary) character set – a character set translation routine might be necessary.
- Return the data as you’ve received it, for example, if you had to change incoming data due to national rules, return the original data with the answer.
- Announce changes in your national system, for example, sending/accepting more Match-Connect messages.
- Provide SMP_RES or NO_RES for all samples received even if the donor is reported as unavailable in the meantime. Closing a request formally by sending an appropriate result message is important (for result reminders, invoicing) because often the donor later shows up as AV again.