15.0 - DONOR_CB message
25.1 - Typing Request
35.2 - Typing Results
45.3 - Sample Request
55.4 - Sample Information
65.5 - Sample Arrival
75.6 - Sample Results
85.7 - Infectious Disease Marker Request
95.8 - Infectious Disease Marker Results
105.9 - Reservation Request
115.10 - Reservation Result
125.11 - Workup Request
135.12 - Workup Status
145.13 - Request Cancellation
155.14 - Request Rejected (NO_RES)
165.15 - Result Reminder (RES_REM)

A register_patient message will be sent together with all requests. This message contains both wmdaId and patientId of the patient.

Provision of the donor ID in every request must be changed.

Current structure is:

donor*

{

description:

Supply one node from the following

grid

string
nullable: true
maxLength: 19
minLength: 19
example: 9991012070433202000

adcu

{

id*	string maxLength: 13 N/A in EMDIS

}

cbu

{

id*	string maxLength: 17 CBU Identification2 CB_ID Opt 17

}

ADCU and CBU have similar structure, but adult donor has the ID (GRID) right away.

Suggested structure for the adult donors:

scd or adult

{

grid*

string
nullable: true
maxLength: 19
minLength: 19
example: 9991012070433202000

}

5.0 - DONOR_CB message

It was agreed that we must implement DONOR_CB message API to preserve the original EMDIS logic.

S&M APIs have the DONOR_CB message split into

https://apispecs.wmda.info/?urls.primaryName=Search%20%26%20Match#/searches/retrieveFullReportDonors

and

https://apispecs.wmda.info/?urls.primaryName=Search%20%26%20Match#/searches/retrieveFullReportCBUs

In the future another message for ADCUs may come to play.

Proposal: change the Semantics by requesting an "updated donor" message instead of DONOR_CB.

WMDA will implement the endpoints to POST the mentioned reports for each donor type.
Participating registries will have to implement the above mentioned reports for both GET and POST (instead of DONOR_CB)
Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx

5.1 - Typing Request

Needed

/post_api_v1_TypingRequestRequest

5.2 - Typing Results

Needed

/post_api_v1_TypingResponseRequest

After the TYP_RES message, a DONOR_CB with the updated donor data is mandatory to ensure up-to-date master data. See 4.0 above.

5.3 - Sample Request

The SampleRequestRequest (and SampleRequestRetrieve) is used to request a VT for a specific donor/product for a patient. The message, as all requests, has an embedded 'register_patient' part. Next to the actual request informations the institutions needed are sent explicitly as an embedded 'addressBlock' (6.1).

The message ID (correlationGUID) of this message will be used as 'referenceCode' for the rest of the request related message flow.

Send	Retrieve
SampleRequestRequest (comments reffer to changes to the current API definition)	SampleRequestRetrieve
patient (in form of an embedded register_patient block) donor (format change see above) ~~referenceCode~~ (not needed anymore see text above) requestDate prod1 prod2 prod3 prod4 receptionDate1 receptionDate2 acceptableReceptionDaysOfWeek institutionToSendSampleTo (as embedded addressBlock) institutionPaying (as embedded addressBlock) urgent ~~acknowledgementId~~ (not needed anymore → MSG_RSP) remark	MetaInformation Payload patient (in form of an embedded register_patient block) donor (format change see above) ~~referenceCode~~ (not needed anymore see text above) requestDate prod1 prod2 prod3 prod4 receptionDate1 receptionDate2 acceptableReceptionDaysOfWeek institutionToSendSampleTo (as embedded addressBlock) institutionPaying (as embedded addressBlock) urgent ~~acknowledgementId~~ (not needed anymore → MSG_RSP) remark