...
| Field | Details |
|---|---|
| wmdaId* | integer nullable: false example: 1234 ID provided by the WMDA |
| patientId* | string maxLength: 17 nullable: false example: 99991234P MUST Start with ION of patient registry. Organisation unique identifier for patient. Cannot be set unless "legalTerms" is set to "true". Do not use real names here. |
| hla* | {...} |
| idm | {...} |
| dateOfBirth | string($date) nullable: true maxLength: 10 example: 1961-05-27 |
| diagnosis | {...} |
| diseasePhase | string Enum: |
| ethnicity | string Enum: |
| poolCountryCode | string maxLength: 2 pattern: ^[A-Z]{2} nullable: true example: NL ISO 3166-1 alpha-2 Country Code (capitalized) |
| abo | string Enum: |
| rhesus | string Enum: |
| weight | integer nullable: true minimum: 1 maximum: 999 example: 76 |
| sex | string Enum: |
| firstName | string maxLength: 30 nullable: true example: John First (given name) of the patient |
| lastName | string maxLength: 30 nullable: true example: Doe Last (family name) of the patient |
6.1.4 Embedded Donor Block (donor in request)
In EMDIS, the following messages are linked to the donor updates:
- IDM_RES
- TYP_RES
- NO_RES
- RSV_RES
These four will be replaced with the Match-Connect API endpoints that have the donor details embedded in the message. Respective endpoints of IDM_RES and TYP_RES will deliver new IDM and new typing details, and all the mentioned endpoints will also inform the patient registry of the new donor status.
These donor updates are for the receiving registry (patient registry) only and will not be updated in the central HUB. So the sending (donor) registry is responsible for sending a DIFF upload to the S&M system in parallel to keep information in sync.
case the embedded donor block is part of a message type that may not result in updates of donor-related data, the "embedded donor block (donor in request" block is used.
Only sending a grid, cordId or adcuId for message types with static donor information enhances privacy and security through data minimization.
| Donor type | Details | |||||||
|---|---|---|---|---|---|---|---|---|
| adult |
| |||||||
| cbu |
| |||||||
| adcu |
|
6.1.5 Embedded Donor Block (donor in response)
In EMDIS, the following messages are linked to the donor updates:
- TYP_RES
- IDM_RES
- RSV_RES
- NO_RES
These four will be replaced with the Match-Connect API endpoints that have the donor details embedded in the message. Respective endpoints of IDM_RES and TYP_RES will deliver new IDM and new typing details, and all the mentioned endpoints will also inform the patient registry of the new donor status.
The corresponding endpoints in Match-Connect are:
- extendedTypingResponse
- infectiousDiseaseMarkerResponse
- reservationResponse
- requestRejected
These donor updates are for the receiving registry (patient registry) only and will not be updated in the central HUB. So the sending (donor) registry is responsible for sending a DIFF upload to the S&M system in parallel to keep information in sync.
| Field | Details | |||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| grid* | string | |||||||||||||||||||||||||||||||
| dateOfBirth | string Donor date of birth | |||||||||||||||||||||||||||||||
| sex | string | |||||||||||||||||||||||||||||||
| antiCmvStatus | string nullable:true Enum: [P, G, M, B, H, O, N] | |||||||||||||||||||||||||||||||
| antiCmvDate | string date of CMV NAT test | |||||||||||||||||||||||||||||||
| hla |
| |||||||||||||||||||||||||||||||
| abo | string nullable:true Enum: [A, B, O, AB] | |||||||||||||||||||||||||||||||
| rhesus | string nullable:true Enum: [P, N] |
| Expand | ||
|---|---|---|
| ||
|
| Expand | ||
|---|---|---|
| ||
|
| title | ... |
|---|
adcuIdid*
string
minLength: 13
maxLength: 13
example: A99991412345612N
Here is the comparison of the DONOR_CB and the API endpoints: EMDIS EMDIS vs API.xlsx
6.1.
...
6 Embedded WMDA Response block
The WMDA will provide a standard response to request messages sent to Match-Connect. Its structure is as follows:
| Field | Details |
|---|---|
| deliveredAtUtc* | string($date-time) Server-supplied timestamp showing time of Message delivery to receiving registry's inbox queue |
| referenceMessageId* | string($uuid) |
| responseType* | stringEnum: messages can be failed, if the message has a structure or information that prevent delivery to the receiving registry. This could be incorrect JSON structure and non-existent ION or because the receiving registry does not allow messages from your registry. |
| receivingRegistryMessageSequenceNumber | integer Incrementing integer set by WMDA MatchConnect systems that indicates the order in which the messages were received by the WMDA and therefore the order in which messages should be processed. Each receiving registry has its own unique sequence. |
| wmdaRemarks | [...] |
6.1.
...
7 Embedded 'generalInformation' Response block
The WMDA will provide a standard response to retrieve messages sent to Match-Connect. Its structure is as follows:
...
Users should be aware that the functionality to restore messages is limited to 72 hours. After this window, the soft-deleted messages are permanently removed from the system. Also see: section 2.4.7 Message storage retention policies in the Technical Guidelines chapter.
| POST | ||||||||||||||||||||
| recoverMessages | ||||||||||||||||||||
|