General considerations:
A patient registration embedded block will be sent together with each request. This block contains both wmdaId and patientId of the patient.
Provision of the donor ID in every request must be changed.
Current structure is:
| donor* | {
} |
ADCU and CBU have similar structure, but adult donor has the ID (GRID) right away.
Suggested structure for the adult donors:
| scd or adult | {
} |
ReferenceCode:
In order to couple messages to the same request, e.g. VT request (SMP_REQ) and its results (SMP_RES) all messages following a request must have a referenceCode as part of the message.
The message ID (correlationGUID) of the request message (TYP_REQ, IDM_REQ, SMP_REQ, RSV_REQ, etc...) will be used as 'referenceCode' for the rest of the request related message flow.
5.1 - Extended Typing Request
This message is used to request an extended typing of a donor (adult, adcu, cbu?). It will primarily contain information about what to type and for which donor.
Added to that a patient block (ref?) containing up-to-date information about the patient, and an address block (ref?) containing up-to-date contact-information about the needed institution(s).
Expected return message is 'typing result' (5.2) or 'request rejected' (5.14).
Check paragraph '5.16 Generic' and '5.16 Extended Typing' for the related message flows.
| Send | Retrieve |
| TypingRequest | TypingRequestRetrieve |
|
|
Rules
The coding schema theoretically allows more combinations than the previous bitstring (e.g. non-high DRB1 typing). The actually valid combinations have to be published in the national rules of each registry. The local user interfaces will have to take care that no invalid or previously undefined requests are issued.
Combinations are possible, i.e. several loci may be requested in one message.
The appropriate action if the typing request cannot be accepted or has to be changed by the recipient, e.g. due to national rules, is to inform the requesting side what was done. If only the resolution was changed (the sender will receive something different than ordered - either more or less) or only a part of the requested loci were accepted (the sender will only receive parts of what was ordered): send a MSG_RSP containing the warning.
5.2 - Extended Typing Results
This message is used to send the results of the initial ET request back to the requesting registry.
Check paragraph '5.16 Generic' and '5.16 Extended Typing' for the related message flows.
| Send | Retrieve |
| TypingResponse | TypingResponseRetrieve |
|
|
Rules
After the TypingResults (TYP_RES) message which includes an embedded donor (DONOR_CB) block, a separate update must be made to the Search & Match system with the updated donor data to ensure up-to-date master data.
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 information the institutions needed are sent explicitly as an embedded 'addressBlock' (6.1).
The messageId of this message will be used as 'referenceCode' for the rest of the request related message flow.
EMDIS Semantic:
The fields ”earliest and latest date of sample reception” represent the lower and upper limit of a period of time in which the blood sample has to be received. If the second date is missing the sample may be received any time after the first date.
The field ACC_DAYS is a binary field with position 1 corresponding to Monday and position 7 corresponding to Sunday. A set bit means acceptable day, an unset bit means not acceptable day. For example, 1110000 means acceptable days for reception are Monday, Tuesday and Wednesday, not acceptable days are Thursday, Friday, Saturday and Sunday. The default value is 1111100 (accept all working days).
The quantity for the first product is optional when requesting DNA from a cord blood unit. In all other requests, the quantity fields for any of the corresponding product fields are required if a product is requested.
Number of tubes requested in a sample request or marrow request:
The maximum amount of material, requested in one sample request or pre-collection sample request, is 100 ml, if not stated otherwise in the national rules. If the number of tubes is unassigned, not given in the request, the default value number of tubes is one.
| Send | Retrieve |
| SampleRequestRequest (comments reffer to changes to the current API definition) | SampleRequestRetrieve |
|
|
5.4 - Sample Information
The SampleInfoRequest (and SampleInfoRetrieve) is used to sent relevant secondary information which may arise in the context of sample request.
The referenceCode is the 'messageId' from the request message.
EMDIS Semantic:
The SMP_INFO message can only be exchanged in one direction: from donor side to patient side.
Sample information is always referencing a sample request.
Sample information is only valid as long as the referenced sample request is considered as ”open” or the donor is reserved for this patient after the sample request.
A request is considered as ”open” as long as the patient registry has neither reported the sample result nor a ”service cannot be performed (NO_RES)” information nor a request cancellation.
There might be several sample information messages within the context of one sample request. Subsequent sample information is regarded as new or additional information and not as updates.
| Send | Retrieve |
| SampleInfoRequest (comments reffer to changes to the current API definition) | SampleInfoRetrieve |
|
|
5.5 - Sample Arrival
The SampleArrivalRequest (and SampleArrivalRetrieve) is used to transmit proposed date of sample arrival.
The messageId of this message will be used as 'referenceCode' for the rest of the request related message flow.
EMDIS Semantic:
This message is sent in response to a SMP_REQ and indicates the arrival date of the sample.
| Send | Retrieve |
| SampleArrivalRequest (comments refer to changes to the current API definition) | SampleArrivalRetrieve |
|
|
5.6 - Sample Results
The SampleResponseRequest (and SampleResponseRetrieve) is used to transmit the results of the sample request.
The messageId of this message will be used as 'referenceCode' for the rest of the request related message flow.
DON_ACCPT = ”N” means: donor can be released immediately.
DON_ACCPT = ”Y” means: please reserve the donor according to your national rules. If possible, the donor should be reserved at the remote hub and reported back to the requesting hub by adding a DONOR_DIFF block to the message STATUS = ”RS”. For all the other patients the donor should be updated by sending a DIFF update to S&M. A delta search will then update the search results for those patients.
EMDIS Semantic:
The fields for the infectious disease markers are included in this message in order to give the transplant centres the possibility to report the results of IDMs they might have tested.
If no SMP_RES can be sent then a NO_RES should be sent with the reason field populated to explain why.
| Send | Retrieve |
| SampleResponseRequest (comments refer to changes to the current API definition) | SampleResponseRetrieve |
|
|
5.7 - Infectious Disease Marker Request
This message is used to request infectious disease marker test results of the selected donor. Expected return message is 'idm result' (5.8) or 'request rejected' (5.14).
| Send | Retrieve |
| InfectiousDiseaseMarkerRequest | InfectiousDiseaseMarkerRequestRetrieve |
|
|
5.8 - Infectious Disease Marker Results
This message is used to send the results of the initial IDM request back to the requesting registry.
Check paragraph '5.16 Generic' and '5.16 Infectious Disease Marker' for the related message flows.
| Send | Retrieve |
| InfectiousDiseaseMarkerResponse | InfectiousDiseaseMarkerResponseRetrieve |
|
|
Rules
After the IDM_RES message which includes an embedded donor (DONOR_CB) block, a separate update must be made to the Search & Match system with the updated donor data to ensure up-to-date master data.
5.9 - Reservation Request
Needed
5.10 - Reservation Result
Needed
After the RSV_RES message which includes an embedded donor (DONOR_CB) block, a separate update must be made to the Search & Match system with the updated donor data to ensure up-to-date master data.
5.10.1 - Donor Release Request (Reservation Release)
**New message
OR
Overload Reservation Request w/ an expiration date in the past
5.11 - Workup Request
Future Phase
5.12 - Workup Status
Future Phase
5.13 - Request Cancellation
Needed
5.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 which includes an embedded donor (DONOR_CB) block, a separate update must be made to the Search & Match system with the updated donor data to ensure up-to-date master data.
5.15 - Result Reminder (RES_REM)
Needed
5.12 - Generic Request
Used to register a patient (by the embedded patientBlock).
Is used for example for direct WU requests until 5.11 is available or to reactivate a closed patient case on recieving registry side.
5.16 Request + Response Flows
Generic
Extended Typing
Infectious Disease Marker
Sample Request
