⚠Due to planned maintenance you will experience short (<30 min) downtime between 08:00 - 08:30 CET.
Table of Contents | ||
---|---|---|
|
General considerations:
A patient registration
embedded block will beEmbedded Patient 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 institutions are needed, they are sent explicitly as an Embedded Address Block.
The requested donor requested has to be reserved at the remote hub and reported back to the requesting hub / donor registry by an Embedded Donor Block (donor in response) within a Reservation Response reflecting the changed donor status (c.f. DONOR_CB with D_STATUS = ”RS”).
Provision of the donor ID in every request must be changed.
Current structure is:
...
{
description: | Supply one node from the following | ||
grid | string nullable: true maxLength: 19 minLength: 19 example: 9991012070433202000 | ||
adcu | {
} | ||
cbu | {
} |
}
- All changes in the donors (change of status, updated typing, or IDMs) resulting from the requests are reported back in an Embedded Donor Block (donor in response) within the respective message, e.g. updated HLA information resulting from an Extended Typing Request in an Extended Typing Result. 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.
- requestId: In order to couple messages to the same request, e.g. Sample Request and its results, all the request-related messages responding to the original request must have a referenceMessageId as part of the message.
The message ID (referenceMessageId) of the request message is used as a reference code for the rest of the request-related message flow.
- Next to the technical referenceMessageId requests, a human-readable reference code (requestId) is used for end-user recognition (communication outside the automated system)
- The requestId is optional
- The requestId is part of the original message block
- The requestId will be generated by the sending registry
- The requestId will only be used for human-to-human communication (e.g. could be used on printed invoices)
- Once requestId is sent, it must be used in all subsequent request message exchanges
- The requestId is optional
- 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.
The expected return messages are Reservation Response, Extended Typing Result and/or Request Rejected.
Send (Post) | Retrieve (Post) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
extendedTypingRequestRequest | extendedTypingRequestRetrieve | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Rules
resolutionRequired: string-enum with the following options
- low = DNA low resolution
- medium = DNA medium (intermediate) resolution
- high = DNA high resolution
- Intermediate resolution (medium) translates to non-high resolution.
- Combinations are possible, i.e.
ADCU and CBU have similar structure, but adult donor has the ID (GRID) right away.
Suggested structure for the adult donors:
...
{
grid* | string nullable: true maxLength: 19 minLength: 19 example: 9991012070433202000 |
}
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.
...
- Typing info
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestDate
- resolutionRequired
- urgent
- remark
- donor
- Patient Block (ref?)
- Address Block (ref?)
...
- Meta Block (ref?)
- Payload TypingRequest
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.
...
- several loci may be requested in one message.
The address block must provide the necessary details for the donor registry to send an invoice for the service. In EMDIS, this used to be the address of the financial institution.
The appropriate action if the typing request cannot be accepted or has to be changed by the recipientby the receiving registry, e.g. due to national rules, is to inform the requesting side what was done. If only the only the resolution was changed (the sender sending registry will receive something different than ordered - either more either more or less) or only a part of the requested loci were accepted (the sender sending registry will only receive parts receive parts of what was ordered): send a MSG_RSP containing a message response (see 6 - Administration v1.0) containing the warning.
5.2 - Extended Typing Results (TYP_RES)
This message is used to send the results of the initial ET request Extended Typing Request back to the requesting registry. Check paragraph '5.16 Generic' and '5.16 Extended Typing' for the related message flows.
...
- Extended Typing Result
- patient (wmdaId)
- referenceCode
- hlaNomenclatureVersion
- etSampleType
- remark
- Donor Block (ref)
...
- Meta Block (ref?)
- Payload TypingResponse
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
extendedTypingResponseRequest | extendedTypingResponseRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
5.3 - Sample Request (SMP_REQ)
This message is used to request a sample to be used for verification typing in the lab of the sending registry.
Send (Post) | Retrieve (Post) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
sampleRequestRequest | sampleRequestRetrieve | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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 of the donor registry.
- If the number of tubes is unassigned, and not given in the request, the default value number of tubes is one.
- A typical response to the Sample Request message is the Sample Arrival Date message. In addition to that, it is mandatory (by the accreditation standards) that the donor registry also sends an IDM Result message to inform the patient registry of the known diseases of the donor.
5.4 - Sample Information (SMP_INFO)
This message is used to send relevant secondary information that may arise in the context of the sample request.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sampleInfoRequest (comments refer to changes to the current API definition) | sampleInfoRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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 ”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.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sampleArrivalRequest (comments refer to changes to the current API definition) | sampleArrivalRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
5.6 - Sample Response (SMP_RES)
This message is used to transmit the results of the sample testing.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
sampleResponseRequest (comments refer to changes to the current API definition) | sampleResponseRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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.
Send (Post) | Retrieve (Post) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
infectiousDiseaseMarkerRequest | infectiousDiseaseMarkerRequestRetrieve | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
infectiousDiseaseMarkerResultRequest | infectiousDiseaseMarkerResultRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Rules
- The common use of the IDM Results message is in response to the Sample Request message, in addition to the 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 requestId 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 a specific patient for a upcoming transplantation at the receiving registry. The patient registry can ask for a specific reservation period by making use of the optional field expirationDate.
Send (Post) | Retrieve (Post) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
reservationRequestRequest | reservationRequestRetrieve | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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 OR if the donor reservation was performed after another request. The donor registry reports back the expirationDate. This might differ from the expirationDate of the Reservation Request message due to local rules or regulations at the donor registry side. The expirationDate in the Reservation Response reflects the "true" reservation period.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
reservationResponseRequest | reservationResponseRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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 acknowledgment.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
reservationReleaseRequest | reservationReleaseRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
requestCancellationRequest | requestCancellationRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
5.15 - Request Rejection (NO_RES)
This message is used to notify the requesting registry when a request cannot be fulfilled (service cannot be provided).
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||
requestRejectedRequest | requestRejectedRetrieve | |||||||||||||||||||||||||||
|
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.
new:
SendRetrieveSampleRequestRequest (comments reffer to changes to the current API definition)SampleRequestRetrieve
maximum: 9999
minimum:
recipientcorrelationGuid*string($uuid)
{...}donor*{
}
referenceCode*string($uuid)requestDate*string($date-time)
nullable: true
readOnly: true
nullable: true
readOnly: true
nullable: true
nullable: true
readOnly: true
nullable: true
maxLength: 14
maxLength: 10
maxLength: 17
nullable: true
example: 1234567890abcdefg
nullable: true
Request
recipient | integer maximum: 9999 minimum: 0 maxLength: 4 minLength: 4 example: 1234 4 digit ION of recipient |
correlationGuid* | string($uuid) Sender generated GUID used to correlate response acknowledgement |
Payload | |
---|---|
patient* | {...} |
donor* | {...} |
referenceCode* | string($uuid) |
requestDate* | string($date-time) Request date REQ_DATE Req 8 |
prod1* | {...} |
prod2 | {...} |
prod3 | {...} |
prod4 | {...} |
receptionDate1* | string($date-time) Earliest date of sample reception REC_DATE1 Req 8 yyyy-MM-dd [or yyyyMMdd] |
receptionDate2 | string($date-time) nullable: true Latest date of sample reception REC_DATE2 Opt 8 yyyy-MM-dd [or yyyyMMdd] |
acceptableReceptionDaysOfWeek | string nullable: true Weekdays acceptable for reception ACC_DAYS Opt 7 |
institutionToSendSampleTo* | string maxLength: 14 Institution the sample has to be sent to INST_SMP_SENT Req 10 |
institutionPaying* | string maxLength: 10 Institution paying INST_PAY Req 10 |
urgent | boolean Urgent request URGENT Opt 1 |
acknowledgementId | string maxLength: 17 nullable: true example: 1234567890abcdefg Acknowledgement ID ACK_ID Opt 17 |
remark | string nullable: true Remark REMARK Opt 120 |
Response
deliveredAtUtc | string($date-time) Server-supplied timestamp showing time of Message delivery to recipient's inbox queue |
referenceMessageId | string($uuid) |
responseType | stringEnum: Array [ 3 ] |
remark | [...] |
Request
No parameters specified
Response
recipientintegermaximum: 9999
minimum:
|
Sender generated GUID used to correlate response acknowledgement
Payload
|
|
Request date REQ_DATE Req 8
requestDateEmdisstringnullable: true
readOnly: true
EMDIS format of Request date REQ_DATE Req 8 yyyy-MM-dd [or yyyyMMdd]
prod1*{...}prod2{...}prod3{...}prod4{...}receptionDate1*string($date-time)Earliest date of sample reception REC_DATE1 Req 8 yyyy-MM-dd [or yyyyMMdd]
receptionDate1Emdisstringnullable: true
readOnly: true
EMDIS format of Earliest date of sample reception REC_DATE1 Req 8
receptionDate2string($date-time)nullable: true
Latest date of sample reception REC_DATE2 Opt 8 yyyy-MM-dd [or yyyyMMdd]
receptionDate2Emdisstringnullable: true
readOnly: true
EMDIS format of Latest date of sample reception REC_DATE2 Opt 8
acceptableReceptionDaysOfWeekstringnullable: true
Weekdays acceptable for reception ACC_DAYS Opt 7
institutionToSendSampleTo*stringmaxLength: 14
Institution the sample has to be sent to INST_SMP_SENT Req 10
institutionPaying*stringmaxLength: 10
Institution paying INST_PAY Req 10
urgentbooleanUrgent request URGENT Opt 1
acknowledgementIdstringmaxLength: 17
nullable: true
example: 1234567890abcdefg
Acknowledgement ID ACK_ID Opt 17
remarkstringnullable: true
Remark REMARK Opt 120
old:
...
- 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
- Response
- deliveredAtUtc
- messageId
- responseType
- remark
- Payload
- n/a
- Response
- MetaInformation
- Send payload
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.
...
- Payload
- patient (just the wmdaID)
- donor (format change see above)
- referenceCode (see text above)
- informationType
- remark
- Response
- deliveredAtUtc
- messageId
- responseType
- remark
- Payload
- n/a
- Response
- MetaInformation
- Send payload
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.
...
- Payload
- patient (just the wmdaID)
- donor (format change see above)
- referenceCode (see text above)
- arrivalDate
- collectionDate
acknowledgementId(not needed anymore → MSG_RSP)- labelId (is there a usecase for this ID, where it is not the donor ID?)
- aampleType (missing: was this field dropped by purpose?)
- remark
- Response
- deliveredAtUtc
- messageId
- responseType
- remark
- Payload
- n/a
- Response
- MetaInformation
- Send payload
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.
...
- Payload
- patient (just the wmdaID)
- donor (format change see above)
- referenceCode (see text above)
- hlaNomenclatureVersion
- hla (full block of all HLA typing results)
- mlcGch
- mlcHvg
- gvhReactivityPercent
- hvgReactivityPercent
- abo
- rh (missing)
- ccr5 (missing)
- cmv (→ antiCmv)
- cmvDate (→ antiCmvDate)
- cmvNat (missing)
- cmvNatDate (missing)
- hbsAg
- antiHbc
- antiHbs
- hbvNat (missing)
- antiHcv
- hcvNat (missing)
- antiHev (missing)
- hiv (→ antiHiv12)
- hiv1Nat (missing)
- hivP24
- antiHtlv
- syphilis (missing)
- antiChagas (missing)
- chagasNat (missing)
- ebv
- toxo
- pb19Nat (missing)
- alt
- donAccpt
- remark (missing: was this field dropped by purpose?)
- Response
- deliveredAtUtc
- messageId
- responseType
- remark
- Payload
- n/a
- Response
- MetaInformation
- Send payload
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).
...
- IDM info
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestDate
- marker
- remark
- donor
- Patient Block (ref?)
- Address Block (6.1)
...
- Meta Block (ref?)
- Payload InfectiousDiseaseMarkerRequest
|
|
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.
Send (Post) | Retrieve (Post) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
resultReminderRequest | resultReminderRetrieve | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
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 the receiving registry side.
Send (Post) | Retrieve (Post) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
genericRequestRequest | genericRequestRetrieve | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
5.18 Request + Response Flows
PlantUML Render Macro | ||||||
---|---|---|---|---|---|---|
| ||||||
participant "Patient Registry" as PR control "Match-Connect" as MC control "Search & Match Service" as SM participant "Donor Registry" as DR skinparam SequenceMessageAlign center skinparam dpi 92 == Register Patient == PR -> SM : Create Patient activate SM #FFBBBB SM -> PR : Return wmdaId deactivate SM == Start Search == PR -> SM : Start Search activate SM #FFBBBB SM -> PR : Return searchId deactivate SM PR -> SM : Check search status activate SM #FFBBBB SM -> PR : Return search status (Completed, Running, Errored) deactivate SM PR -> SM : Retrieve search results activate SM #FFBBBB SM -> PR : Return search results deactivate SM == Making Request == PR -[#dodgerblue]> DR : Extended Typing Request (incl. Embedded Patient Block) DR -[#dodgerblue]> PR : Reservation Response PR -[#dodgerblue]> DR : Request Cancellation == Getting Response == DR -[#dodgerblue]> PR : Request Rejection DR -[#dodgerblue]> PR : Extended Typing Result (incl. Embedded Donor Block) |
PlantUML Render Macro | ||||||
---|---|---|---|---|---|---|
| ||||||
participant "Patient Registry" as PR control "Match-Connect" as MC control "Search & Match Service" as SM participant "Donor Registry" as DR skinparam SequenceMessageAlign center skinparam dpi 92 == Register Patient == PR -> SM : Create Patient activate SM #FFBBBB SM -> PR : Return wmdaId deactivate SM == Start Search == PR -> SM : Start Search activate SM #FFBBBB SM -> PR : Return searchId deactivate SM
activate SM #FFBBBB SM -> PR : Return search status (Completed, Running, Errored) deactivate SM
activate SM #FFBBBB SM -> PR : Return search results deactivate SM == Making Request == PR -[#dodgerblue]> DR : Sample Request (incl. Embedded Patient Block) DR -[#dodgerblue]> PR : Reservation Response PR -[#dodgerblue]> DR : Request Cancellation DR -[#dodgerblue]> PR : Request Rejection DR -[#dodgerblue]> PR : Sample Arrival DR -[#dodgerblue]> PR : IDM result (incl. Embedded Donor Block) DR -[#dodgerblue]> PR : Sample Information == Getting Response == PR -[#dodgerblue]> DR : Request Rejection PR -[#dodgerblue]> DR : Sample Result |
PlantUML Render Macro | ||||||
---|---|---|---|---|---|---|
| ||||||
participant "Patient Registry" as PR control "Match-Connect" as MC control "Search & Match Service" as SM participant "Donor Registry" as DR skinparam SequenceMessageAlign center skinparam dpi 92 == Register Patient == PR -> SM : Create Patient activate SM #FFBBBB SM -> PR : Return wmdaId deactivate SM == Start Search == PR -> SM : Start Search activate SM #FFBBBB SM -> PR : Return searchId deactivate SM
activate SM #FFBBBB SM -> PR : Return search status (Completed, Running, Errored) deactivate SM
activate SM #FFBBBB SM -> PR : Return search results deactivate SM == Making Request == PR -[#dodgerblue]> DR : IDM Request (incl. Embedded Patient Block) DR -[#dodgerblue]> PR : Reservation Response PR -[#dodgerblue]> DR : Request Cancellation == Getting Response == DR -[#dodgerblue]> PR : Request Rejection DR -[#dodgerblue]> PR : IDM Result (incl. Embedded Donor Block) |
PlantUML Render Macro | ||||||
---|---|---|---|---|---|---|
| ||||||
participant "Patient Registry" as PR control "Match-Connect" as MC control "Search & Match Service" as SM participant "Donor Registry" as DR skinparam SequenceMessageAlign center skinparam dpi 92 == Register Patient == PR -> SM : Create Patient activate SM #FFBBBB SM -> PR : Return wmdaId deactivate SM == Start Search == PR -> SM : Start Search activate SM #FFBBBB SM -> PR : Return searchId deactivate SM PR -> SM : Check search status activate SM #FFBBBB SM -> PR : Return search status (Completed, Running, Errored) deactivate SM PR -> SM : Retrieve search results activate SM #FFBBBB SM -> PR : Return search results deactivate SM == Making Request == PR -[#dodgerblue]> DR : Reservation Request (incl. Embedded Patient Block) PR -[#dodgerblue]> DR : Request Cancellation == Getting Response == DR -[#dodgerblue]> PR : Reservation Response (incl. Embedded Donor Block) PR -[#dodgerblue]> DR : Reservation Release Request |
PlantUML Render Macro | ||||||
---|---|---|---|---|---|---|
| ||||||
@startuml participant "Patient Registry" as PR control "Match-Connect" as MC control "Search & Match Service" as SM participant "Donor Registry" as DR skinparam SequenceMessageAlign center skinparam dpi 92 == Register Patient == PR -> SM : Create Patient activate SM #FFBBBB SM -> PR : Return wmdaId deactivate SM == Start Search == PR -> SM : Start Search activate SM #FFBBBB SM -> PR : Return searchId deactivate SM PR -> SM : Check search status activate SM #FFBBBB SM -> PR : Return search status (Completed, Running, Errored) deactivate SM PR -> SM : Retrieve search results activate SM #FFBBBB SM -> PR : Return search results deactivate SM == Making Request == PR -[#dodgerblue]> DR : Generic Request (incl. Embedded Patient Block) DR -[#dodgerblue]> PR : Reservation Response PR -[#dodgerblue]> DR : Request Cancellation == Getting Response == DR -[#dodgerblue]> PR : Request Rejection @enduml |
v1.0.1
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.
...
- IDM Result
- patient (wmdaId)
- referenceCode
- hlaNomenclatureVersion
- etSampleType
- remark
- Donor Block (ref)
...
- Meta Block (ref?)
- Payload InfectiousDiseaseMarkerResult
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
This message is used to request the reservation of a donor for transplant at the receiving registry.
...
- Reservation Request Payload
- patient (wmdaId)
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestDate
- expirationDate
- remark
...
- Meta Block (ref?)
- Payload ReservationRequest
5.10 - Reservation Result
This message is used to notify the of the requesting patient registry if Reservation Request has been confirmed by the donor registry.
...
- Reservation Result
- patient (wmdaId)
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- referenceCode
- expirationDate
- confirmed
- remark
- Donor Block (ref)
...
- Meta Block (ref?)
- Payload Reservation Result
Rules
After the ReservationResult (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)
This message is used so the patient registry can notify the donor registry to release a donor reservation when it is no longer needed (e.g. patient deceased or was transplanted with another donor). This should be used if the Reservation Request has been fulfilled, if the Reservation Request has not been fulfilled 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.
...
- Reservation Release
- patient (wmdaId)
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestDate
- reason
- remark
...
- Meta Block (ref?)
- Payload Reservation Release
Rules
After the Reservation Release 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
Consulation items from the TWG - Stopping a Search
5.11 - Workup Request
Future Phase
5.12 - Workup Status
Future Phase
5.13 - Request Cancellation
This message is used to cancel a previous request that has been sent to the donor registry. The Request It must have a preceding request that is being cancelled.
...
- Request Cancellation
- patient (wmdaId)
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestType
- reason
- remark
...
- Meta Block (ref?)
- Payload Request Cancellation
5.14 - Request Rejected (NO_RES)
This message is used to notify the requesting registry when a request cannot be fulfilled.
...
- Request Rejected
- patient (wmdaId)
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestType
- reason
- remark
...
- Meta Block (ref?)
- Payload Request Rejected
Rules
After the Request Rejected (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)
This message is sent by the requesting registry to the receiving registry to remind the receiving registry of an outstanding results from a previous request.
...
- Result Reminder
- patient (wmdaId)
- donor
- type (adult, adcu, cbu)
- id (grid, id)
- requestDate
- resultType
- expirationDate
- remark
...
- Meta Block (ref?)
- Payload Result Reminder
5.16 - 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.17 Request + Response Flows
Generic
Extended Typing
Infectious Disease Marker
Sample Request