the type of message just sent by calling this endpoint
responseType
string
Enum: Array [ Warning, Acknowledge]
wmdaRemark
One or more remarks, each in its own object
Field
Details
remarkType
string
description
string
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.
The contactPerson is required if the INST_TYPE is ”LAB”.
The EMDIS ID (INST_ID) of an institution should remain stable over time and should not be assigned to different institutions.
In the Match-Connect system, the addresses will be embedded in the donor requests. See Chapter Requests for details.
Organisation unique identifier for the institution.
Unique reference to an institution
Allows local address management if needed (e.g. for other use cases) by receiving registry and backward compatibility to existing EMDIS implementations.
Provided by the local registry system.
Should be worldwide unique.
Should follow the construct of hub code + local address id.
The hub code usually are the two-character ISO country code of the registry (e.g. NL for Netherlands)
In the case of multiple registries in one country, a replacement code will be assigned.
Should be provided as a user-friendly (displayable) id for use on screens and on documentation.
line1*
string nullable:false
maxLength: 60
Address line 1
line2
string nullable:true
maxLength: 60
Address line 2
line3
string nullable:true
maxLength: 60
Address line 3
postalCode*
string nullable: false
maxLength: 10
city*
string nullable: false
maxLength: 40
country*
string nullable: false
minLength: 2
maxLength: 2
2 character ISO country code (ISO 3166-1 alpha-2)
type*
string nullable: false
minLength: 3
maxLength: 3
HUB = EMDIS Hub DON = Donor centre TRA = Transplant centre HAR = Harvesting centre LAB = Typing laboratory FIN = Financial institution CBB = Cord Blood Bank
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
phone
The value is a telephone number used for voice calls.
Phone Number PHONE Req 20
StringType
fax
The value is a fax machine.
Fax Number FAX Opt 20
StringType
email
The value is an email address.
Email address EMAIL Opt 60
StringType
ID
Organisation unique identifier for the institution.
Unique reference to an institution
Allows local address management if needed (e.g. for other use cases) by receiving registry and backward compatibility to existing EMDIS implementations.
Provided by the local registry system.
Should be worldwide unique.
Should follow the construct of hub code + local address id.
The hub code usually are the two-character ISO country code of the registry (e.g. NL for Netherlands)
In the case of multiple registries in one country, a replacement code will be assigned.
Should be provided as a user-friendly (displayable) id for use on screens and on documentation.
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:
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.
Collection type, i.e. the willingness of the donor to donate in a specific manner. M = Marrow P = PBSC B = Both PBSC & Marrow
Enum: Array [ 3 ]
transfusionsCount
integer nullable:true example:1
pregnanciesCount
integer nullable:true example:2
reservedPatientId
string nullable:true example:1234222ss
statusEndDate
string($date) maxLength:10 nullable:true
statusReason
string nullable:true
DO = Donor is too old, DD = Donor died, MR = Medical reasons, PR = Personal reasons, TX = After transplantation, MO = Donor has moved, UC = Unable to contact donor, OT = Other reasons, TQ = Typing questionable, UK = Unknown
DN = "Screening done, normal results" DU = "Screening done, unusual findings" NS = "No screening done" CD = "Can be done at time of release" NC = "Cannot be done" DT = "Thalassemia" DD = "Drepanocytosis"
Enum: Array [ 7 ]
viabilityCellType
string nullable:true
type of cell tested for viability
Enum: Array [ 3 ]
viabilityMethod
string nullable:true
7A = 7AAD PI = Propidium Iodide TB = Trypan Blue OT = Other
Total number of nucleated red blood cells (post processing, prior to cryopreservation)
serumAliquotsCount
integer minimum:0 maximum:99 nullable:true
serumQuantity
number minimum:0 maximum:99.9 nullable:true
plasmaQuantity
number minimum:0 maximum:99.9 nullable:true
ctCompletionDate
string($date) maxLength:10
ctSampleType
string nullable:true maxLength:2
AS = CBU Contiguous Attached Segment, WB = Whole Blood Sample, RC = Red Cell Fraction (pellet), FP = Blood Spotted Filter Paper, ED = Extracted DNA
Enum: Array [ 5 ]
dnaSamplesAvailable
boolean nullable:true
otherSamplesAvailable
boolean nullable:true
donorAttribute
string maxLength:3 nullable:true
statusEndDate
string($date) maxLength:10 nullable:true
statusReason
string nullable:true
DO = Donor is too old, DD = Donor died, MR = Medical reasons, PR = Personal reasons, TX = After transplantation, MO = Donor has moved, UC = Unable to contact donor, OT = Other reasons, TQ = Typing questionable, UK = Unknown
Enum: Array [ 10 ]
hla*
{...}
mic
{...}
registry
{...}
cbb
{...}
maternalInfo
{...}
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: Array [ Success, Warning,Failed]
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.
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.
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.
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.