⚠Due to planned maintenance you will experience short (<30 min) downtime between 08:00 - 08:30 CET.
6.1 Embedded blocks
6.1.1 Embedded Meta block
The additional meta-information "blocks" are added to ensure the receiving registry is aware of:
- A message identifier
- A timestamp
- What registry sent the information (sending registry)
- What type of response is provided by the WMDA Match Connect system
- Any failed validations detected by the Match Connect system
Field | Details |
---|---|
referenceMessageId | string($uuid) |
deliveredAtUtc | string($date-time) Server-supplied timestamp showing UTC time of Message delivery to receiving registry's inbox queue. |
sendingRegistry | string maximum: 9999 minimum: 0 maxLength: 4 minLength: 4 example: 5678 4-digit ION of the sending registry |
messageType | string the type of message just sent by calling this endpoint |
responseType | string Enum: |
wmdaRemark | One or more remarks, each in its own object |
6.1.2 Embedded Address block (NEW_ADD)
With this message block, the contact information of the hub's institutions, namely Financial institutions, Transplant Centers and Laboratories are shared with the partner hubs. Thus a partner hub has all the required contact information for the Institution contained in Donor Requests.
- Hubs are required to keep this contact information up to date.
- It’s not only useless but forbidden to give a postbox (POB) in a LAB address since this address is used for the delivery of samples. For the same reason ZIP code, City, and Country are required in the address block.
In the Match-Connect system, the addresses will be embedded in the donor requests. See Chapter Requests for details.
Consider to use address block structure according to HL7-FHIR standard with extensions (https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Address.html), e.g.
Suggested format | Suggested field | Description | Mapping to NEW_ADD |
StringType | City | The name of the city, town, suburb, village or other community or delivery center. | City Req 40 |
StringType | country | Country - a nation as commonly understood or generally accepted. | Country Req 2 |
StringType | District | The name of the administrative area (county). | Address Line 2 ADDR_2 Opt 40 |
List <StringType> | line | This component contains the house number, apartment number, street name, street direction, and P.O. | Address Line 3 ADDR_3 Opt 40 |
Period | period | The time period when the address was/is in use. | new - Opt |
StringType | postalCode | A postal code designating a region defined by the postal service. | ZIP code ZIP Req 10 |
StringType | state | Sub-unit of a country with limited sovereignty in a federally organized country. | new - Opt |
StringType | text | Specifies the entire address as it should be displayed e.g. on a postal label. This may be provided instead of or as well as the specific parts. | Address Line 1 to Address Line 3, City, Country, Zip code - Opt |
Enumeration <Address.AddressType> | type | Distinguishes between physical addresses (those you can visit) and mailing addresses (e.g. PO Boxes and care-of addresses. Most addresses are both.). This is the underlying object with id, value, and extensions. The accessor "getType" gives direct access to the value. | new - Req |
Enumeration <Address.AddressUse> | use | The purpose of this address. | Institution Type INST_TYPE Req 3 |
StringType | contact person | The name of the contact person. | Contact person PERSON Opt 40 |
StringType |
| The value is a telephone number used for voice calls. | Phone Number PHONE Req 20 |
StringType |
| The value is a fax machine. | Fax Number FAX Opt 20 |
StringType |
| The value is an email address. | Email address EMAIL Opt 60 |
StringType | ID | Not needed anymore, as the full address will be sent embedded in every request. | INST_ID Req 10 |
Obsolete. S&M provides accreditation on the match list. | Accreditation Opt 5 |
6.1.3 Embedded Patient Block
There is no "register patient" endpoint. Instead, an embedded patient block will accompany all requests. The embedded patient block looks as follows:
Field | Details |
---|---|
wmdaId* | integer nullable: false example: 1234 ID provided by the WMDA |
patientId* | string maxLength: 17 nullable: false example: XY1234P Organisation unique identifier for the 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
In EMDIS, the following messages are linked to the donor updates:
- IDM_RES
- TYP_RES
- NO_RES
- RSV_RES
These four and newly two more (SMP_ARR and SMP_INFO) 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 to send a DIFF upload to the S&M system in parallel to keep information in sync.
Donor type | Payload |
---|---|
Adult donor | |
CBU | |
ADCU | In the future |
Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx
6.1.5 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. |
wmdaRemark | [...] |
6.2 Message Response
The message response is intended as an automated response to every user generated message. It serves three purposes:
- message acknowledgment
- warning
- message denial
This is a purely machine-to-machine type of message, as compared to EMDIS where such responses can be user generated.
Note: The concept of the REF_CODE field used in EMDIS is replaced by the GUID assigned by the central system to each message. The Message Response is supposed to be using the GUID of the original message as the Reference ID in its structure.
Message structure:
Send | Retrieve |
---|---|
MessageResponse | |
6.3 Text message [TXT_MSG]
The TXT_MSG is useful to convey notes or comments pertaining to a particular patient, donor, or patient/donor pair.
Note: Since Warnings are going to be automated, we must keep Text Messages as the only means for user communication left.
Message structure:
Send | Retrieve |
---|---|
textMessageRequest | |
6.4 Alert message
The Alert message is used to broadcast an important information about the system, like planned service outage. Messages are generated centrally by WMDA. Members are expected to display them to the users.
Message structure:
Send | Retrieve |
---|---|
AlertRetrieve | |
Alerts can only be sent by the WMDA's central system |
6.5 Alert Update message
The Alert Update message is used to broadcast an update about some previous alert. Messages are generated centrally by WMDA. Members are expected to display them to the users.
Message structure:
Send | Retrieve |
---|---|
AlertUpdateRetrieve | |
Alert updates can only be sent by the WMDA's central system |
6.6 Available Messages
The available messages endpoint is used for retrieving an array of messages that are ready to be downloaded. This information can then be used to retrieve the messages from their respective *retrieve endpoints.
Message structure:
Send | Retrieve |
---|---|
availableMessages | |
N/A |