Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

Current structure is:

donor*

{

description:

Supply one node from the following

gridstring
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

}

4.

...

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 PUT the mentioned reports.
  • Participating registries will have to implement the above mentioned reports for both GET and PUT
  • The only missing part: DON_POOL - Physical location of the donor - must be added to both reports as not nullable field, because it is required by EMDIS Semantics.

4.1 - Typing Request

Needed

 Needed

With this message type all kind of HLA typing requests are transmitted to a remote donor registry. The details of the HLA typing to be performed are defined in the field RESOLUT. The testing has to be performed at the lab of the donor registry (in contrast to the SMP_REQ message where a (blood) sample will be shipped and then the testing will be done in the lab of the transplant centre). The results will be sent back via the message TYP_RES.

/post_api_v1_TypingRequestRequest

...

/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.

4.3 - Sample Request

Needed

...

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_InfectiousDiseaseMarkerResultRequest

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

4.9 - Reservation Request

...

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_ReservationResultRequest

After the RSV_RES message a DONOR_CB with the updated donor status is mandatory to reflect the change. See 4.0 above.

4.11 - Workup Request

Future Phase

...

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_NoResultRequest

If the results cannot be delivered, a NO_RES message followed by a DONOR_CB message is returned which includes the new donor status. See 4.0 above.

4.15 - Result Reminder (RES_REM)

...