• The Match-Connect technical specifications consist of the API documentation and the documents listed below. When developing a Match-Connect implementation all content of the following documents is relevant and needs to be considered:
  • The Semantics of Match-Connect Messages
  • Match-Connect Data Dictionary
• A Donor_DIFF block is embedded in every result message, i.e. TYP_RES, IDM_RES, SMP_RES, RSV_RES or NO_RES message as the donor record is changing in its source.
  • More generally: every time data on a match list that was provided by donor upload changes, a DIFF upload becomes necessary to update the master data.
• The term ”donor” in this document usually means ”adult donor” or ”cord blood unit” or "adult donor cryopreserved unit". 
• The institution paying (INST_PAY) has to be of the institution type (INST_TYPE) FIN.
• It is required to transmit every known field value every time. If a field is not sent, its contents are to be deleted at the receiver. 
• The WMDA nomenclature files (http://hla.alleles.org/wmda/index.html) must be used for all HLA fields. The recipient may reject messages with invalid values. The details are described in the WMDA Guidelines for use of HLA Nomenclature (https://www.nature.com/articles/bmt201393; follow the link ”Supplementary information”).
• The Match-Connect semantics for the WMDA approved additional codes are defined as follows: 

Message	UUUU	NEW	XXXX	NNNN
PAT_UPD	N	N	DRB3/4/5	DRB3/4/5
Donor_DIFF	N	N	DRB3/4/5	DRB3/4/5
TYP_RES	N	Y	DRB3/4/5	DRB3/4/5
SMP_RES	Y	Y	DRB3/4/5	DRB3/4/5

• Match-Connect patient IDs should be defined in a way that a change of patient data such as name, birth date or transplant centre does not result in a changed Match-Connect ID. Once a patient ID has been assigned for a given patient, the patient ID cannot be changed.
• Detailed information about the Global Registration Identifier (GRID) can be found on: https://share.wmda.info/display/OptimisingSearchMatchConnect/Project%3A+GRID.
• HLA changes of a recipient must not cancel requests for the recipient. The requests remain under full responsibility of the transplant centre.
• 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.
• If there are results that cannot be delivered via Match-Connect for whatever reason, the usage of any Match-Connect message (e.g. to give the result in the remark field) is discouraged - fax or email should be used instead.
• It’s not only useless but forbidden to give a postbox (POB) in a LAB address since this address is used for delivery of samples. For the same reason ZIP code, City and Country are required in the NEW_ADD message.
• Generally faxes and emails should be avoided in an electronic communication system. If they become necessary, it’s recommended not to mix channels in message groups, for example, if the TYP_REQ was in Match-Connect, the result should be in Match-Connect as well and not by fax/email (and vice versa).
• Don’t send information multiple times - WARNINGs are to be used if it happens in order to find errors.
• Multiple *_RES or *_ARR messages are regarded as updates and therefore should be different from the previously sent one.
• Do not initialize integer and float values with zero but use ”null”.
• The correct action if a request cannot be accepted is to send a NO_RES followed by a DONOR_CB. The NO_RES.REASON shall be given as ”OT”. 
• Do not change IDs of patients, donors or addresses: use the primary keys of your database tables prefixed by your hub code as Match-Connect IDs.
• Only use the specified (see Data Dictionary) character set – a character set translation routine might be necessary.
• Check the MSG_DEN and WARNING messages you receive from your partners.
• 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.
• Resolution of patient HLA typing: provide the highest resolution of HLA-A,B and DR possible. DNA low (XX) resolution on HLA-A,B and DR seriously hampers DNA based matching and mismatching.
• Announce changes in your national system, for example, sending/accepting more Match-Connect messages.
• Try to improve your national Match-Connect interface: automated LAB/TC address updates (danger of lost samples for verification typing (CT) and work-up), recognition of duplicates (patients, requests), and usage of the correct reference code (i.e. of the recipient’s side) in result messages (to allow correct assignment of results).
• Institution addresses registered in the Match-Connect network must be kept up to date. Any updates (and updates only) of Match-Connect institutions must be transmitted at least once a year.
• 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.
• If a new hub does not want to implement the whole set of available message types, reasonable groups of message types should be implemented together.
  • Support of typing requests by a donor registry:
    • IN: TYP_REQ, REQ_CAN
    • OUT: TYP_RES, MSG_ACK, NO_RES
      plus associated administrative messages like MSG_DEN, WARNING, NEW_ADD