...
- most detailed information as the number is part of the whole communication proess
Con:
- a lot alot of overhead in the commnicationcommunication
- extra work at each registry
- each registry has to maintain a sequence number for each new registry (peer to peer behaviour)
- exra extra work for each registry when a new registry is added to the system
- error prone as independed implemenations are needed and no control by the centralized system
Option C):
central sequence number provided by SMC:
...
The sender is responsible for ensuring the desired order of calls to the Connect APIs. If api calls are to be scheduled / batched, 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. Make sure no message is send after former message run into an errorthe next message is sent only when the status of the previous one has been marked OK by SMC.
Central system:
Central system provides the sequence number as part of the meta block as anwser in each connect message (messages to another Registry).
...
The sequence number would be part of the meta block. The reciever receiver has to check that the sequence number is correct (no number numbers missing) and only process the messages if that is ok. Otherwise go back to the central system and claim the missing message.
...
- avoid peer-to peer problem
- least effort needed on registry side
- reciever receiver can re-request "missing" message
- can be automated, no help needed by WMDA staff
- allows for different levels of details (C1 vs. C2)
...
- additional effort on WMDA side
- new endpoint for re-request specific message
- handling of the sequences
- storing registry to registry messages centralized for a time to make re-request possible.
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:
...