Page History

2.0 Guaranteeing Message Order

The sender is responsible for ensuring the desired order of calls to the Connect APIs.  It is suggested that the sender maintain a queue of outgoing calls / messages so that message sequence is persistent in the event of system failure.

The receiver is responsible for monitoring the incoming messages queue and process retrieval calls to the Connect APIs in the order specified.

2.1 Rules

• 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 changes in its source.
  • More generally: every time data on a match list 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", "cord blood unit", or "adult donor cryopreserved unit." 
• The institution paying (INST_PAY) has to be of the institution type (INST_TYPE) FIN.
• Empty/blank/missing fields in the payload mean deletion. 
  • Consequently, empty/blank integer or float values must be provided as null values.
• The WMDA nomenclature files (http://hla.alleles.org/wmda/index.html) must be used for all HLA fields. The central hub and/or the receiving registry 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: 

...