You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »



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

/post_api_v1_PatientRegistration

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

/post_api_v1_TypingRequestRequest

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

4.3 - Sample Request

Needed

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

4.4 - Sample Information

Needed

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

4.5 - Sample Arrival

Needed

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

4.6 - Sample Results

Needed

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

4.7 - Infectious Disease Marker Request

Needed

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

4.8 - Infectious Disease Marker Results

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

Needed

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

4.10 - Reservation Result

Needed

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

4.12 - Workup Status

Future Phase

4.13 - Request Cancellation

Needed

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

4.14 - Request Rejected (NO_RES)

Needed

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)

Needed

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

  • No labels