...
- 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.0.1
How to collect all messages at keep the sequence:
Options:
to allow external registries to access those messages there are several options:
A)
"the current suggested situation":
- 1) call /availableMessages endpoint and then collect the messages from the endpoints with waiting messages
- 2) or collect messages from all endpoints and accept that some are empty
To keep the ordering (aside from timestamp) the above suggested sequence per receiving registry should be introduced.
The registries has to separate collecting from processing in order to keep the sequence of processing right.
B)
"meta-queue":
- 1) introduce the sequence per receiving registry to /availableMessages endpoint and list all messages per specific queue, not only give the sum
- 2) collect those messages based on the sequence number by going round the specific endpoints
This would allow a registry to collect and process messages in the right order without storing them locally and sort them there
C)
"All-in-One Queue":
- provide a new endpoint that makes use of the "oneOf" tag and provides all messages for external registries
- here the sequence is not needed for ordering anymore but still needed to realize missing messages
This would allow a registry to call just one endpoint to collect all messages.
Limitations:
Option C) doesn't work for powerplattform in microsoft 365, it will only work with a static structure in call responses.
As on WMDA side (propably) all messages are stored in one queue anyhow (check with Mark) options A-C) will only effect the exposure of the messages to the registries and not the internal workings on WMDA side.
So implementing the options next to each other might give the registries the choice to pick there prefered solution and might still be fine for WMDA?!?
Recommendation:
implement B and C
As a consequence of implementing B) all individual endpoint will have an optional parameter "sequenceNumber" that will function as a filter so that you only get the message with that sequence from the endpoint, without that parameter the endpoints will function as is.
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:
...