To be designed and described. The idea is to help registry's MC admin to analyze possible issues reported in validationDetails field. AM: I think this is an excessive information, as messageId should be sufficient.
validationDetails
To be designed and described. The idea is to supply the concerns of the central hub validation system that are acceptable but require attention of the receiving registry.
}
6.2 Embedded Address block
Original message: Address to broadcast [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 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.
Address block structure (HP's suggestion, requires discussion regarding the accreditation field and extension of the use field):
In EMDIS, the following messages are linked to the donor updates:
InfectiousDiseaseMarkerResultRequest (IDM_RES)
TypingResponseRequest (TYP_RES)
NoResultRequest (NO_RES)
ReservationResultRequest (RSV_RES)
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
Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx
6.5 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.
Alerts can only be sent by the WMDA's central system
Alert Payload:
Level
Status
Message
Meta block
6.8 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.