General considerations:

• A patient registration embedded block is sent together with each request. This block contains both the wmdaId and the patientId of the patient.

• Next to the actual request information, whenever the institutions are needed, they are sent explicitly as an Embedded Address Block.

• The requested donor has to be reserved at the remote hub and reported back to the requesting registry by an embedded donor block with the donor status reflecting the change (a.k.a. DONOR_CB with D_STATUS = ”RS”).

• All changes in the donors (change of status, updated typing, or IDMs) resulting from the requests are reported back in an embedded donor block. A separate update must be made to the Search & Match system with the updated donor data to ensure up-to-date master data. More information on how to do so may be found here.
• ReferenceCode: In order to couple messages to the same request, e.g. Sample Request and its results, all messages following the initial request must have a referenceCode as part of the message.

  • The message ID (correlationGuid) of the request message is used as the referenceCode for the rest of the request related message flow.

• Each field inherited from EMDIS Semantics contains a comment describing its purpose in EMDIS and its original name to assist in the transition from EMDIS to Match-Connect.
• Paragraph Request + Response Flows depicts the new message flows.

5.1 - Extended Typing Request (TYP_REQ)

This message is used to request an extended typing of a donor (adult, ADCU, CBU). It primarily contains information about what to type and for which donor.
Expected return message is Extended Typing Results or Request Rejected.

Rules

Examples for field resolutionRequired:

HLA-DRB1 low resolution:
---L-------
HLA-DRB1 serological:
---S-------
HLA-DRB1 high resolution:
---H-------
HLA-DRB1 and HLA-DQB1 high resolution:
---H----H--

• Intermediate resolution (M) translates to non-high resolution.
• 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 receiving registry, e.g. due to national rules, is to inform the requesting side what was done. If only the resolution was changed (the sending registry will receive something different than ordered - either more or less) or only a part of the requested loci were accepted (the sending registry will only receive parts of what was ordered): send an MSG_RSP containing the warning.

5.2 - Extended Typing Results (TYP_RES)

This message is used to send the results of the Extended Typing Request back to the requesting registry. 

5.3 - Sample Request (SMP_REQ)

This message is used to request a VT (verification typing) of a specific donor/product for a patient. 

Rules:

• The fields ”earliest and latest date of sample reception” represent the lower and upper limit of the 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 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.
• A 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, and not given in the request, the default value number of tubes is one.

5.4 - Sample Information (SMP_INFO)

This message is used to send relevant secondary information which may arise in the context of sample request.

Rules:

• The message can only be exchanged in one direction: from the donor side to the 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” and the donor is reserved for this patient after the sample request.
• A request is considered”open” as long as the patient registry has neither reported the sample results nor a Request Rejected message 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.

5.5 - Sample Arrival (SMP_ARR)

This message is used to transmit the proposed date of the sample arrival.

5.6 - Sample Response (SMP_RES)

This message is used to transmit the results of the sample testing.

Rules:

• donorStillOfInterest = ”N” means: the donor can be released immediately.
• donorStillOfInterest = ”Y” means: please prolong donor reservation according to your national rules.
• The fields for the infectious disease markers are included in this message in order to give the transplant centers the possibility to report the results of IDMs they might have tested.
• If Sample Results cannot be sent then a Request Rejected message should be sent with the reason field populated to explain why.

5.7 - Infectious Disease Marker Request (IDM_REQ)

This message is used to request infectious disease marker test results of the selected donor.

Rules:

• Several distinct requests for the same patient/donor pair at a time are possible, for example, a verification typing and a CMV status, but each request has to be answered by an individual IDM Results, i.e. results must not be ”concatenated” to a single result message. Multiple IDM
  requests for the same patient/donor pair have to be disjoint (i.e. may not contain identical markers). The occurrence of multiple requests should be an exception. Normally, all markers required should be requested within one message.

5.8 - Infectious Disease Marker Results (IDM_RES)

This message is used to send the results of the IDM request back to the requesting registry. 

Rules

• The common use of the IDM Results message is in response to the Sample Request message, in addition to shipment of the donor blood sample. Please note there may be a charge involved with this service. If a fee is charged, it may come as a separate item or might be included in the price of the sample shipment. Such IDM Results messages can be sent via a regular EMDIS message - the remote hub must be able to handle it appropriately. The IDM Results must have the same referenceCode as the Sample Request message.
• IDM Results message can be generated in response to two different message requests:
  • Sample Request does not specify what set of infectious disease markers to be tested
  • IDM Request does specify what set of infectious disease markers to be tested
• The field marker is a required field.
• For those hubs reporting infectious disease markers during verification typing, the marker field should contain the IDMs actually tested. There is a fixed-length binary field for the IDM Results message. The blood group may also be reported.
• IDM results can also be reported as a part of the Sample Results message by the hub (transplant center) that requested the blood sample. This is to give the transplant centers the possibility to report the results of IDMs they might have tested.

5.9 - Reservation Request (RSV_REQ)

This message is used to request the reservation of a donor for transplant at the receiving registry.

5.10 - Reservation Response (RSV_RES)

This message is used to notify the requesting patient registry if the Reservation Request has been confirmed by the donor registry.

5.11 - Reservation Release Request (new message)

The patient registry sends this message to inform the donor registry that a donor can be released from the reservation when it is no longer needed (e.g. patient is deceased or was transplanted with another donor). This should be used if the donor reservation was confirmed in response to some request. If the reservation has not been confirmed then a Request Cancellation message should be used.

This is a change request with respect to the current procedure and should be handled as such as it has implications on local systems.

There is no response to this message except for the automated acknowledgement.

5.12 - Workup Request

Future Phase

5.13 - Workup Status

Future Phase

5.14 - Request Cancellation (REQ_CAN)

This message is used to cancel a previous request that has been sent to the donor registry. The Request must have a preceding request that is being canceled.

5.15 - Request Rejected (NO_RES)

This message is used to notify the requesting registry when a request cannot be fulfilled (service cannot be provided).

5.16 - Result Reminder (RES_REM)

This message is sent by the requesting registry to the receiving registry to remind the receiving registry of an outstanding result from a previous request.

5.17 - Generic Request (new message)

This message is used for registering a patient (by the embedded patient block).

This may be required for example for direct WU requests until 5.11 is available or to reactivate a closed patient case on receiving registry side.

5.18 Request + Response Flows

Generic 

Extended Typing 

Infectious Disease Marker

Sample Request