WMDA is using XML (Extensible Markup Language) file, which is considered an industry standard that is extendable, robust and easy to use. Several people from the community formed a working group to create the required XML Schema Definition (XSD) files. These files define the elements that are allowed in the XML file, the order of the elements and the values that will be accepted. The names of the elements are based upon EMDIS specifications and aligns with the EMDIS Data Dictionary when appropriate. Several elements are basic elements that should be included in all files, but there are also elements that are specific for only donors or only cord blood units (CBUs).
We will now explain the composition of the XML file and how you should use the XSD reference files.
2. XSD schema files
WMDA is offering two XSD schema files that define the structure of your XML file: basicTypes.xsd and Inventories.xsd.
The Inventories file describes the structure of the XML file and the order of the elements. Here you can also find if a certain field is mandatory or not (minOccurs="0"-> not mandatory). This file includes many "complexTypes": an XML element that contains other elements and/or attributes. In the file you can see that the values of the elements can be defined here, like the elements GRID and ID, or that after the name of the field a "type" is defined. For example for the element with name BIRTH_DATE you see type="bareDateType". The definition of "bareDateType" is described in the basicTypes.xsd file.
Related to XSD versions, our data upload system always supports latest 3 versions of XSD. And in this page, we keep the latest version to be displayed. If there is another version, it will be in the collapse object before the tables.
Supported versions now: 2.2, 2.3. The XSD schema can be download here:
We will now describe the global structure of the XML file and the elements.
Please note: For a lot of elements, we use abbreviations as allowed values. The explanation of all those abbreviations can be found in the XSD files. Most abbreviations are also the same as used for EMDIS and clarified in the EMDIS dictionary.
2.1 InventoryType elements
Field Identifier
Required
Description
Type
Length
Comment
CREATION_TIME
Yes
Creation time stamp of the inventories (in UTC)
dateTime
minimal 20
Without fractional seconds the length is 20, for example: 2016-08-23T13:16:48Z.
Additional notes: CREATION_TIME is defined as "Creation time stamp of the <INVENTORIES>" that means the time in UTC when the complete and valid file was finally created at the registry. This can be the same as SNAPSHOT_TIME.
LISTING_ORGANIZATION
Yes
Organisation that lists the donor/cbu provided as ION
ionType: number between 1000 and 9999
4
Issuing Organisation Number (ION) allocated by ICBBA. This can be different from the POOL when another organisation is sending the data to WMDA.
POOL
Yes
Physical location of the donors/CBUs of the inventory provided as ION
ionType: number between 1000 and 9999
4
Physical location of the donors/CBUs of the inventory provided as ION.
CONTENT_TYPE
Yes
Type of the inventory items, i.e. donor ("D") or CBU ("C")
contentTypeType
1
The content-type is also shown in the fileName. When CONTENT_TYPE is "D", the INVENTORY must contain <DONOR>-blocks. When CONTENT_TYPE is "C", the INVENTORY must contain <CBU>-blocks.
UPDATE_MODE
Yes
Update mode of the inventory, i.e. FULL or DIFF
updateModeType
4
Both UPDATE_MODE of "FULL" and "DIFF" are supported. For "FULL", the complete inventory should be sent without deleted inventory, for "DIFF", only the new, edited, deleted inventory need be sent.
SNAPSHOT_TIME
No
Timestamp of the 'data snapshot' (in UTC)
dateTime
minimal 20
Without fractional seconds the length is 20, for example: 2016-08-23T13:16:48Z
Additional notes: SNAPSHOT_TIME in the element <INVENTORY> is defined as "timestamp of the data snapshot in UTC" that means the timestamp of the creation of this part of the complete file. This can be the timestamp of the XML export and I guess that in most of the cases it will be identical to the CREATION_TIME.
SCHEMA_VERSION
Yes
Version of the applied XML Schema Definition (XSD)
schemaVersionType
The schema version is very important as this determines the validation rules that should be applied during the processing of your file.
2.2 ItemBaseType elements (for Donors and CBUs)
Field Identifier
Required
Description
Type
Length
Comment
ID
No for Donor
Yes for CBU
Unique identifier of the donor/CBU
String
17
Unique identifier of the donor/CBU:
If you are an EMDIS member, you can use the same ID as you use for that system (EMDIS hub code + donor identification allocated by the associated donor registry).
For non-EMDIS members we recommend to use two digit ISO country code of the associated donor registry + donor identification allocated by the associated donor registry. For example: AU600196166, DEGOE-35487, US087013165, SB45.
However, you are also allowed to use just the donor ID allocated by your registry.
Field Identifier
Required
Description
Type
Length
Comment
ID
No for Donor
Yes for CBU
Unique identifier of the donor/CBU
String
25
Unique identifier of the donor/CBU:
If you are an EMDIS member, you can use the same ID as you use for that system (EMDIS hub code + donor identification allocated by the associated donor registry).
For non-EMDIS members we recommend to use two digit ISO country code of the associated donor registry + donor identification allocated by the associated donor registry. For example: AU600196166, DEGOE-35487, US087013165, SB45.
However, you are also allowed to use just the donor ID allocated by your registry.
Update from XSD 2.2
GRID
Yes for Donor
No for CBU
Global registration identifier of the donor
String
19
ONLY applicable for donors. GRID format allowed is: XXXXXXXXXXXXXXXXXXX. Only upper case letter and numbers are allowed. The first 4 characters include the ION were the donor is registered. The following 13 characters contain the donor specific ID and the last two characters are check characters that are calculated from the 17 previous characters.
Note: For the generation of the value of GRID, check the "checksum" calculation rule in GRID user guide and a WMDA "checksum" calculator example here.
Field Identifier
Required
Description
Type
Length
Comment
ATTR
No
Describing attribute of the donor/CBU according to house rules of the sending organization.
String
3
BIRTH_DATE
Yes
Date of birth of the donor/CBU
bareDateType
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
AFNA = African: North Africa AFSS = African: Sub-Sahara Africa ASSW = Asian: Southwest Asia (Middle East, Turkey) ASSO = Asian: Southern Asia (India, Pakistan, Bangladesh, Sri Lanka, Bhutan, Nepal) ASCE = Asian: Central Asia (Eastern Russia, Kazakhstan, Uzbekistan, Kyrgyzstan, Tajikistan) ASSE = Asian: Southeast Asia (China, Mongolia, Burma, Laos, Cambodia, Thailand, Vietnam, Taiwan) ASNE = Asian: North and Northeast Asia (Japan, North Korea, South Korea) ASOC = Asian: Oceania (Pacific Islands, excluding Japan, Australia, Taiwan, Sakhalin, Aleutian Islands) CAEU = Caucasian: Mainland Europe, Greenland, Iceland, Western Russia CAER = Caucasian: Eastern Russia CANA = Caucasian: North America (USA, Canada, Mexico) CAAU = Caucasian: Australia (Australia, New Zealand) HICA = Hispanic: Central America, Caribbean HISA = Hispanic: South America MX = Mixed / multiple OT = Other (e.g. Australian Aborigine) UK = Unknown
Infectious disease markers (IDM) and other relevant tests of the donor/CBU
idmType
Explained separately at idmType 2.5
RSV_PAT
No
Unique identifier of the patient the donor/CBU is reserved for (STATUS=RS).
String
17
The value comprises the EMDIS patient identification, where the patient search centre is an EMDIS member, otherwise the value is empty. For example: AU9654021, DE275342, US2277450.
NOTE: This field is not required for status "RS" and can be transmitted as empty if privacy concerns exist.
STATUS
Yes
Status of the donor/CBU
statusType
2
statusType: "AV" ,"TU" ,"RS" , "DE" ( "DE" is not supported in "FULL" mode, and supported in "DIFF" mode)
AV = Available for transplantation purposes TU = Temporarily unavailable RS = Reserved DE = Deleted, permanently unavailable
STAT_END_DATE
No
Date until which the current status will be applicable
bareDateType
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
2.3 hlaType elements
HlaType fields can be divided in hlaSerFieldsType and hlaDnaFieldsType
hlaSerFieldsType: HLA values obtained by serological typing methods
hlaSerFieldsType = “<FIELD1>” string of max length 5 “</FIELD1>”, “<FIELD2>” string of max length 5 “</FIELD2>”;
DNA typing results can be given for loci that are defined as hlaLocusSerDnaType and hlaLocusDnaOnlyType. These loci include HLA-A, -B, -C, -DRB1, -DQB1, -DRB3, -DRB4, -DRB5, -DQA1, -DPA1, -DPB1.
Finally, previously the dot20 file format allowed to submit values like 01 in DNA fields. We can no longer accept this and you have to submit the equivalent of 01, so '01:XX' .
hlaGlsFieldType: HLA GL String typing value or GL String like typing value.
hlaGlsFieldType = "<GLS>"string of max length 255"</GLS>"
DNA GL String like typing is now used for MICA and MICB.
Full HLA example: Please notice the "..." should be filled with the HLA data like in <A>, if no value, the HLA type should be excluded, or include without "...".
Each SER element contains two other elements: FIELD1 and FIELD2
DNA
depends on content type and SER fields provided
HLA values obtained by DNA based typing methods
hlaDnaFieldsType
20
Each DNA element contains two other elements: FIELD1 and FIELD2
FIELD1
HLA value of allele 1
5 or 20
Element within the element SER and DNA
FIELD2
HLA value of allele 2
5 or 20
Element within the element SER and DNA
GLS
HLA typing result provided as GL String
hlaGlsFieldType
255
GLS element contains the HLA typingresult in GL String
A
Yes
HLA-A values
hlaLocusSerDnaType
Both SER and DNA possible; either SER or DNA values required
B
Yes
HLA-B values
hlaLocusSerDnaType
Both SER and DNA possible; either SER or DNA values required
C
No
HLA-C values
hlaLocusSerDnaType
Both SER and DNA possible
E
No
HLA-E values
hlaLocusDnaOnlyType
20
Only DNA possible
DRB1
Yes (CBU) No (Donor)
HLA-DRB1 values
hlaLocusSerDnaType
5 or 20
Both SER and DNA possible; either SER or DNA values required for CBU
DRB3
No
HLA-DRB3 values
hlaLocusDnaOnlyType
20
Only DNA possible
DRB4
No
HLA-DRB4 values
hlaLocusDnaOnlyType
20
Only DNA possible
DRB5
No
HLA-DRB5 values
hlaLocusDnaOnlyType
20
Only DNA possible
DQA1
No
HLA-DQA1 values
hlaLocusDnaOnlyType
20
Only DNA possible
DQB1
No
HLA-DQB1 values
hlaLocusSerDnaType
5 or 20
Both SER and DNA possible
DPA1
No
HLA-DPA1 values
hlaLocusDnaOnlyType
20
Only DNA possible
DPB1
No
HLA-DPB1 values
hlaLocusDnaOnlyType
20
Only DNA possible
MICA
No
MHC class I polypeptide-related sequence A
hlaLocusGlsOnlyType
255
GL String like value, example: 008:01:01/008:01:02/008:03/008:04+018:01/018:02
MICB
No
MHC class I polypeptide-related sequence B
hlaLocusGlsOnlyType
255
GL String like value
2.4 kirType elements
The kirType Field Definitions consists of the type: kirLocusType. This is defined as a String with 3 characters: "POS" or "NEG". "POS" means "Presence of KIR gene", "NEG" means "Absence of KIR gene".
The following elements are possible and in this specific order:
URI that refers to a GL String registered with a GL service or direct GL String for absence / presence
string
255
This field is not used at the moment and must be empty.
Field Identifier
Required
Description
Type
Length
Comment
KIR gene e.g. KIR2DL1
No
KIR genotype e.g. KIR gene 2DL1
kirLocusType
3
valid values: "POS" = presence of KIR gene; "NEG" = absence of KIR gene
KIR_GL_URI
No
URI that refers to a GL String registered with a GL service or direct GL String for absence / presence
string
255
This field is updated and supported from XSD 2.3
2.5 idmType elements
There are many infectious disease markers (IDM) possible in the element IDM. Many IDM elements can have either the values idmValueType or idmValueExtType
idmValueType includes the following values: "P","N"
idemValueExtType include the following values: “P”,“G”,“M”,“B”,“H”,“O”,“N”
Only when there is old version fields name, then will be in a separated collapse box:
Field Identifier
Required
Description
Type
Length
Comment
CMV
No
Cytomegalovirus status
idmValueExtType
1
idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”
P = IgG or IgM positive, test did not differentiate G = IgG positive, IgM negative M = IgG negative, IgM positive B = Both IgG and IgM positive H = IgG positive, IgM not tested O = IgG negative, IgM not tested N = Both IgG and IgM negative
EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the data submission file.
CMV_DATE
No
Date of CMV test
bareDateTyp
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
Field Identifier
Required
Description
Type
Length
Comment
ANTI_CMV
No
Antibody to Cytomegalovirusstatus
idmValueExtType
1
idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”
P = IgG or IgM positive, test did not differentiate G = IgG positive, IgM negative M = IgG negative, IgM positive B = Both IgG and IgM positive H = IgG positive, IgM not tested O = IgG negative, IgM not tested N = Both IgG and IgM negative
EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the data submission file.
CMV_NAT
No
Cytomegalovirusnucleic acid testing (NAT) status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ANTI_CMV_DATE
No
Date of CMV test
bareDateTyp
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
CMV_NAT_DATE
No
Date of CMV NAT test
bareDateTyp
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
HBS_AG
No
Hepatitis B status (hepatitis B surface antigen)
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ANTI_HBC
No
Hepatitis B status (antibody to hepatitis B core antigen)
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ANTI_HBS
No
Hepatitis B status (antibody to hepatitis B surface antigen)
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ANTI_HCV
No
Hepatitis C status (antibody to hepatitis C virus)
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ANTI_HIV_12
No
Antibody to Human immunodeficiency virus (HIV) 1/2 status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
HIV_1_NAT
No
Human immunodeficiency virus (HIV)-1 nucleic acid testing (NAT) status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
HIV_P24
No
Human immunodeficiency virus (HIV) p24 status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
HCV_NAT
No
Hepatitis C nucleic acid testing (NAT) status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ANTI_HTLV
No
Antibody to human T-cell lymphotropic virus (HTLV) I/II status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
SYPHILIS
No
Syphilis status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
WNV
No
West Nile Virus status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
CHAGAS
No
Chagas status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
EBV
No
Epstein Barr Virus status
idmValueExtType
1
idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”
P = IgG or IgM positive, test did not differentiate G = IgG positive, IgM negative M = IgG negative, IgM positive B = Both IgG and IgM positive H = IgG positive, IgM not tested O = IgG negative, IgM not tested N = Both IgG and IgM negative
EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the data submission file. Please leave blank for Q.
TOXO
No
Toxoplasmosis status
idmValueExtType
1
idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”
P = IgG or IgM positive, test did not differentiate G = IgG positive, IgM negative M = IgG negative, IgM positive B = Both IgG and IgM positive H = IgG positive, IgM not tested O = IgG negative, IgM not tested N = Both IgG and IgM negative
EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the data submission file. Please leave blank for Q.
HBV_NAT
No
Hepatitis B virus (HBV) nucleic acid testing (NAT) status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
PB19_NAT
No
ParvoB19 nucleic acid testing (NAT) status
idmValueType
1
idmValueType: "P","N"
P = Positive N = Negative
ALT
No
Alanine aminotransferase status in units per litre
Short
Number, no decimals, minimal value is 1
2.6 donItemType elements
DonItemType elements contain elements that are specific for donors and not applicable for CBUs.
Field Identifier
Required
Description
Type
Length
Comment
ID
No
Unique identifier of the donor
String
25
Same field name used for unique identifier of the donor/CBU:
If you are an EMDIS member, you can use the same ID as you use for that system (EMDIS hub code + donor identification allocated by the associated donor registry).
For non-EMDIS members we recommend to use two digit ISO country code of the associated donor registry + donor identification allocated by the associated donor registry. For example: AU600196166, DEGOE-35487, US087013165, SB45.
However, you are also allowed to use just the donor ID allocated by your registry.
GRID
Yes
Global registration identifier of the donor
String
19
ONLY applicable for donors. GRID format allowed is: XXXXXXXXXXXXXXXXXXX. Only upper case letter and numbers are allowed. The first 4 characters include the ION were the donor is registered. The following 13 characters contain the donor specific ID and the last two characters are check characters that are calculated from the 17 previous characters.
Note: For the generation of the value of GRID, check the "checksum" calculation rule in GRID user guide and a WMDA "checksum" calculator example here. More detail you can check the GRID project page here.
STAT_REASON
No
Additional information relevant to the donor status. Can only be used for "TU" status.
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
CONTACT_DATE
No
Date of last confirmed contact - defined as the date of an active form of communication (e.g. a query about status, an address update, confirmation of their interest in donating) via any channel (e.g. email, mail, phone, website), post registration, from a donor to the registry. Any communication from the registry to the donor that does not lead to an activity of the donor suggesting his further interest in donation is explicitly excluded (e.g. annual mailing without reaction).
bareDateType
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
CHECKUP_DATE
No
Date of the last medical checkup - defined as the date of a donor health assessment that indicates whether a donor is minimally suitable to be considered for donation, regardless if eligible for only one donation type, and includes questions about current medication and health issues (e.g. completion of a health screening questionnaire at Extended Typing or Verification Typing). The donor health assessment can be completed by any means (e.g. paper-based, online, phone). This does not require any physical examination of a donor.
bareDateType
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
WEIGHT
No
Weight in kg Please note that current validation only allows [40-199] kg
Short
Number between 1 and 999, no decimals
HEIGHT
No
Height in cm Please note that current validation only allows [100-250] cm
Short
Number between 1 and 999, no decimals
NMBR_TRANS
No
Number of blood transfusions
Short
Number: zero or greater, no decimals
NMBR_PREG
No
Number of pregnancies
Short
Number: zero or greater, no decimals
NMBR_MARR
No
Number of marrow donations
Short
Number: zero or greater, no decimals
NMBR_PBSC
No
Number of PBSC donations
Short
Number: zero or greater, no decimals
COLL_TYPE
No
Collection type, i.e. the willingness of the donor to donate in a specific manner
String
1
collTypeType: "M", "P","B"
M = Marrow P = PBSC B = Both PBSC & Marrow
2.7 cbuItemType elements
CbuItemType elements contain elements that are specific for CBUs and not applicable for donors.
Field Identifier
Required
Description
Type
Length
Comment
ID
Yes
Unique identifier of the CBU
String
25
Same field name used for unique identifier of the donor/CBU::
If you are an EMDIS member, you can use the same ID as you use for that system (EMDIS hub code + donor identification allocated by the associated donor registry).
For non-EMDIS members we recommend to use two digit ISO country code of the associated donor registry + donor identification allocated by the associated donor registry. For example: AU600196166, DEGOE-35487, US087013165, SB45.
However, you are also allowed to use just the donor ID allocated by your registry.
STAT_REASON
No
Additional information relevant to the CBU status. Can only be used for "TU" status.
Proposed reasons for Status TU: QR = Quarantined; AD = Administrative
Proposed reasons for Status DE: CD = Cord Destroyed or Damaged; DS = Distributed for infusion; XP = ExpiredCD = Cord Destroyed or Damaged; MR = Medical reasons OT = Unavailable for other reasons; UK = Unknown
LOCAL_ID
No
Identification of CBU locally at the associated CBB
String
17
BAG_ID
No
Identification as it appears on the bag. If more than one bag is available then this data attribute is not populated
String
17
BANK_MANUF_ID
No
Unique identifier of the CBB that manufactured the CBU. ID shown in table in tab Cord blood bank IDs
String
10
PLEASE NOTE: For the upload the fields BANK_MANUF_ID and BANK_DISTRIB_ID should be fulfilled with a new ID in WMDA attribute for the corresponding cord blood banks (See column "WO number at share.wmda.info/display/WMDAREG/Database ) and EMDIS IDs can be filled in the EMDIS attribute.
These IDs in WMDA attribute are important to allow WMDA to identify if the CBU is from an accredited bank which will be displayed within a search report. The supported accreditation are FACT, AABB, WMDA C/D accreditation.
Unique identifier of the CBB distributing the CBU. ID shown in table in tab Cord blood bank IDs
String
10
PLEASE NOTE: For the upload the fields BANK_MANUF_ID and BANK_DISTRIB_ID should be fulfilled with a new ID in WMDA attribute for the corresponding cord blood banks (See column "WO number at share.wmda.info/display/WMDAREG/Database ) and EMDIS IDs can be filled in the EMDIS attribute.
These IDs in WMDA attribute are important to allow WMDA to identify if the CBU is from an accredited bank which will be displayed within a search report. The supported accreditation are FACT, AABB, WMDA C/D accreditation.
BCE = Buffy Coat Enriched DNE = Density Enriched PLR = Plasma Reduced (Volume reduction only) PRR = Plasma and RBC Reduced RBR = RBC Reduced (depletion) NOT = Not reduced OTH = Other
BAG_TYPE
No
Type of bag used (bag fractions / split unit)
bbagTypeType
5
bagTypeType: "80/20","50/50","40/60","NS" (no split)
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
VOL
No
Collected volume before processing (without additives) in ml
Short
Number between 10 and 400, no decimals
VOL_FRZN
No
Total volume frozen (post processing, prior to cryopreservation) in ml
Short
Number between 10 and 400, no decimals
TNC
No
Total number of nucleated cells (before processing)
Float
Number with decimals, minimum is 0.0E0, maximum is 999.9E7
TNC_FRZN
No
Total number of nucleated cells (post processing, prior to cryopreservation)
Float
Number with decimals, minimum is 0.0E0, maximum is 999.9E7
RED_BC_FRZN
No
Total number of nucleated red blood cells (post processing, prior to cryopreservation)
Float
Number with decimals: minimum is 0.0E0, maximum is 999.9E7
MNC_FRZN
No
Total Number of mononucleated cells (post processing, prior to cryopreservation)
Float
Number with decimals
CD34PC
No
Total number of CD34+ cells (before processing)
Float
Number with decimals
CD34PC_FRZN
No
Total number of CD34+ cells (post processing, prior to cryopreservation)
Float
Number with decimals
CFU_FRZN
No
Total count of colony forming units (post processing, prior to cryopreservation)
Float
Number with decimals, nunimum is 0.1E5, maxnum is 999.9E5
VIABILITY
No
Viability as percentage value
Short
Number between 0 and 100, no decimals
VIABILITY_DATE
No
Date that viability was tested
bareDateType
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
VIABILITY_CELLS
No
Type of cells tested for viability
viabilityCellsType
6
viabilityCellsType: "TNC","CD34PC","CD45PC"
NOTE:
VIABILITY_CELLS = "CD34PC" corresponds to CB_VIABILITY_CELLS = "CD34" in EMDIScord.
VIABILITY_CELLS = "CD45PC" corresponds to CB_VIABILITY_CELLS = "CD45" in EMDIScord.
VIABILITY_METHOD
No
Method used to calculate the viability
viabilityMethodType
2
viabilityMethodType: "7A","PI","TB","OT"
7A = 7AAD PI = Propidium Iodide TB = Trypan Blue OT = Other
ATT_SEG
No
Number of attached segments available
Short
Number between 0 and 99, no decimals
DNA_SMPL
No
DNA samples available?
Boolean
true,false
OTH_SMPL
No
Samples other than DNA available?
Boolean
true,false
CT_COMPLETE_DATE
No
Date of completion of confirmatory typing (CT)
bareDateType
10
Date without timezone information, example 1968-06-28, Date Delimiter = "-"
CT_SMPL_TYPE
No
Confirmatory typing (CT) sample type
ctSmplTypeType
2
ctSmplTypeType: "AS","WB","RC","FP","ED"
AS = CBU Contiguous Attached Segment WB = Whole Blood Sample RC = Red Cell Fraction (pellet) FP = Blood Spotted Filter Paper ED = Extracted DNA
AL_RED_BC
No
Number of red cell fraction aliquots
Short
Number between 0 and 99, no decimals
AL_SER
No
Number of serum aliquots available
Short
Number between 0 and 99, no decimals
SER_QUANT
No
Total quantity of serum available in ml
Float
Number between 0.0 and 99.9, one decimal
AL_PLA
No
Number of plasma aliquots available
Short
Number between 0 and 99, no decimals
PLA_QUANT
No
Total quantity of plasma available in ml
Float
Number between 0.0 and 99.9, one decimal
MAT
No
Data of the mother of the infant associated with the CBU
matType
see further on this webpage matType
2.8 matType elements
The matType elements are a sub-element from the element CBU.
Field Identifier
Required
Description
Type
Length
Comment
ID
No
Identification used to identify the maternal donor as assigned by the registry
String
15
ID_BANK
No
Identification used by associated CBU manufacturer to identify maternal detail
String
15
HLA
No
HLA of the mother of the infant associated with the CBU
hlaType
see above in section 2.3 hlaType
IDM
No
Infectious disease markers (IDM) and other relevant tests of the mother of the CBU
idmType
see above in section 2.5 idmType
AL_SER
No
Number of serum aliquots available
short
Number between 0 and 99, no decimals
SER_QUANT
No
Total quantity of serum available in ml
Float
Number between 0.0 and 99.9, one decimal
AL_PLA
No
Number of plasma aliquots available
Short
Number between 0 and 99, no decimals
PLA_QUANT
No
Total quantity of plasma available in ml
Float
Number between 0.0 and 99.9, one decimal
#
Minimal required data
Organisations providing donor or CBU data, should at least include the following elements with valid values. Without this data, the records will be rejected during the validation procedure.
Note: For the generation of the value of GRID, check the "checksum" calculation rule in GRID user guide and a WMDA "checksum" calculator example here. More detail you can check the GRID project page here.
A DONOR record should include:
GRID
BIRTH_DATE
SEX
HLA (including at least HLA-A (SER or DNA) and HLA-B (SER or DNA))
STATUS
A CBU record should include:
ID
BIRTH_DATE
HLA (including at least HLA-A (SER or DNA), HLA-B (SER or DNA) and HLA-DRB1 (SER or DNA))
STATUS
#
XML example files
We already provided you the XSD files, but these files do not show directly how an XML file with those definitions will look like. Therefore we created some example files: one for donors and one for CBUs.
Both files contain only 2 records, but in those two records almost all possible elements contain a value. It can help you to check the order of the elements in your own XML file. Please be aware that values like GRID are fictive and do not follow the rules for the check character.
We suggestion you to always implement the latest version.
Important to know for XML structure:
Currently, the error handling can not handle the data structure as below if there is no records included for both FULL/DIFF upload mode.
After generating your XML files, you are advised to validate the generated XML file. You may use any XML tool that includes validation for that, for example the open source Qxmledit or XMLLINT.
You can use xmllint by invoking the program giving the XML file and the Schema file, and it will generate a report.
Download the required binary files. You need the binary files from 4 .zip files, and download the latest version. They are iconv, libxml2, libxslt and zlib. The names are as belows, some binary files may have suffix version number, that is fine, and you can keep it.
Create a new folder in C:\tools\libxml. (This is a suggestion from the owner). Or you can create folder "libxml" in C:\Windows\ or C:\Program Files as you prefer.
Move all binary files in the folder C:\tools\libxml
Add "C:\tools\libxml" to the System environment variable PATH/Path.
Restart your system
The xmllint cmds can be executed in the windows cmd or PowerShell (windows 10).
Please refer to your IT staff for installation if you can not handle this.
Viewing large files
XML files tend to be large. For quick visual inspection and search you may use Glogg (windows)
Generate XML file from excel data source
WMDA suggest two methods to generate the XML file manually for small dataset.
If you have Microsoft excel with developer tab. You can manually generate the XML with less than 65,536 records. You can use the specific xsd schema file Inventories-cbu-xml-gen.xsd or Inventories-donor-xml-gen.xsd to generate the XML file. You can download the file mentioned above in the XSD schema page.
WMDA prepare a php script to generate XML file from excel/csv data source for small dataset like less than 2000 records. If you need further help, please contact support@wmda.info.
#
File names
Registries with data on stem cell donors and cord blood units should separate these two data sets and provide two files: one for stem cell donors, and one for cord blood units. Data of stem cell donors and cord blood units should not be combined in one file. In the filename the distinction between donor data and cord blood unit data is made clear.
The first part of the filename is "ION-" (without the quotes) followed by the ion number and either a "D-" for donors (without the quotes) or a "C-" (without the quotes) for cold blood units. This <ION> should be similar to the one provided in the field <POOL>. The extension of the file is ".XML". Using this naming convention the name of the Austrian cord blood registry is: ION-2614-C.XML and the name of the German donor registry is: ION-6939-D.XML
After encryption, the file should follow almost the same name convention as for the xml file name, but then xml is replaced to pgp. So the first part of the GPG-filename is identical to the XML-filename. The GPG software will either add a second extension ".PGP", or replace the ".XML" extension of the data file with the ".PGP" extension. As an example, the file name of an encrypted Austrian cord blood file would then be: "ION-2614-C.PGP" (without the quotes).
If you are listing organisation and are also sending data from other listing organisations (with ION), you can provide the inventory of different POOL IDs together in one file. However, you should not combine donor and CBU data together. For the file naming, please always use the ION from the organisation that is sending the data.
#
How to compress your XML file with ZIP
ZIP file is not a request anymore, even for big file. Because the encryption process will compress and encrypt the file.
When your file is larger then 200Mb, you have to compress your file by using ZIP. If your file is smaller, you are also encouraged to compress your file, because the time to upload your file will be reduced.
Please find below some methods to compress your file with ZIP when you are using any of the operating systems Windows, OS, or Linux/unix.
Please note: When you are using another method to compress your file, like tar, we cannot decompress your file during processing and we have to reject the file.
Creating a compressed zip file in Windows
Click to highlight the file that you need to zip. Please note: WMDA can only accept your file when the zip file contains 1 file.
Right-click the file and select Send to > Compressed (zipped) Folder.
Windows will create the zip file and will position the cursor where you can choose a unique name for the file.
It is also possible to first create your ZIP folder and then drag the file to your zip folder.
Creating a compressed zip file in OS X
Open a new Finder window and navigate to the file.
Click to highlight the file that you need to zip.
Select File > Compress from the pull-down menu. Sometimes you can also click with your right mouse button on the file and use the quick menu.
Finder will compress the selected file and will create the zip file with the same same as your file but with the extension .zip.
Creating a compressed zip file in Linux
Open a terminal session and navigate to the location of your file
To view a listing of directory contents, enter the following command: ls
Note the files to be zipped.
Create the zip file by entering the command: zip {.zip-filename} {filename-to-compress} (e.g. zip ION-1234-D.zip ION-1234-D.xml)
#
How to encrypt your XML file
WMDA will only accept pgp encrypted XML files for data upload. We will now describe how you can encrypt your xml file. If you have a very large file, you should first compress your file with ZIP before you encrypt your file. Please see the picture below for a schematic representation of the encryption en decryption process.
Encryption is performed by the organisation who is sending data to WMDA; decryption is performed by WMDA to be able to process and validate the data in your file.
For this encryption, you should use the WMDA public key.
This is the new public key: public key (download the file in this link)
Please note: This key is different from the key that you used to encrypt your DOT20 file.
STEP 1: Encryption program
The DOT20 file also needed to be encrypted. The procedure is actually the same, but you now have to use the new public key.
Currently, there are several different software packages that you can use to encrypt and decrypt your files. It depends of course also of your operating system which programs you can use.
GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880 (also known as PGP). GnuPG allows to encrypt and sign your data and communication, features a versatile key management system as well as access modules for all kinds of public key directories. GnuPG, also known as GPG, is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries are available. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License . For installation on your Linux/Unix machine, please visit the following page for HowTos: https://www.gnupg.org/documentation/howtos.html
STEP 2: Import the public key
After installing your preferred program, you have to import the public key.
First download the public key to your computer. It is important that you save the file with extension asc (key.asc)
Open your encryption program and look for something like import (PGP) key or import certificate. Click on this and then you have to upload the file with the WMDA public key and save the key.
If you might get an error with importing the key, you can try to remove the text “Version: GnuPG v2” from the file and try to import the file again.
For Linux/Unix, importing of the key in your gpg keyring can be done by using the following command:
$ gpg --import {public_key_file}
Alternatively, instead of saving this file and importing the key, you may look it up at a keyserver.
For example, if you use Kleopatra, use CTRL-SHIFT-I and search for 0xC44E0E7A736E374E
If you use gpg from the commandline, use gpg --recv-keys --keyserver pool.sks-keyservers.net --recv 0xC44E0E7A736E374E
STEP 3: Encrypt XML or ZIP file with the public key
Next step is to use the public key that you just imported into your encryption program to encrypt your XML or zipped XML file.
In your encryption program, go to the function called encrypt or encrypt files.
A windows with all your files will open. Look up the file you would like to encrypt.
Following the steps in your program and make sure you choose the public key to encrypt your file
Some programs work together with your file exploring program like Finder for Mac or Explorer for windows. If this is the case, go to your file look-up program and look for your file.
Select your file and click on the right mouse button. A quick menu will become visible. Look for something with encryption or GPG or with a MAC it is probably under Services. This depends on the program you installed on your computer. Click on that and follow the instructions on your screen.
Make sure you choose the public key to encrypt your file.
For Linux/Unix, encryption of your file can be done by using the following command:
$ gpg --encrypt --recipient ID {filename_to_be_encrypted}
where ID is replaced with that key's ID
The short version of the above command is:
$ gpg -e -r ID {filename_to_be_encrypted}
In either case, a file is created with the same name, plus an additional .gpg file extension added to the end. Thus, if your file is ION-1234-D.xml, you will create an encrypted copy of the file named ION-1234-D.xml.gpg.
Please note: Do not sign your file. This will result in rejection of your file during processing.
User guide for Kleopatra(Windows):
Download here. It is included in the gpg4win package.
Import the the public key. And you will see imported public key as below:
Encrypt the file. Click "Sign/Encrypt", in the pop-up window, un-check "Sign as", "Encrypt for me" and "Encrypt with password". And in "Encrypt for others", type in the public key e-mails to get the public key. Tip: if the WMDA public key is imported correctly, then after you type-in "data", the whole key name will pop-up, and can be selected. NOTE: There will be pop-up window to notify you to certify the public key, you can ignore this. But if you do want to certify the public key, you can following the guide here. If the public key is correctly imported, but without certify, there will be a blue "i" icon () in front of the key. If you add certify, then it will be green "v" icon. If the public key is not correctly imported, there will be a red "x" icon(). If that is the case, please repeat above process till you see the . After that, the grep "next" button will turn "Encrypt", then click "Encrypt" to encrypt the file. You may get warning that you can not decrypt the file because you do not have private key, that is fine.
#
Explanation of Errors and Warnings in your processing report
INFORMATION
We are currently working on the new errors and warning you might find in your processing report. The errors and warnings shown below are mainly based on the old processing reports and are amended to our best knowledge at this moment. More information will follow soon.
After submitting a file you will receive a processing report in your data upload service account. This document describes explanations of warnings or errors as you may find them in the processing report. In the explanations below you find references to various fields from the file format for data delivery. For details on these field names and the file format look in the tabs 'XML file' and 'File name' of this page.
The ID of the donor or CBU will be displayed as well. This helps you find the problem line in the file you have sent, and hopefully helps you correct the problem.
Business validation rules applied
WMDA has additional business validation rules in place to ensure that even though the data supplied on a field level might be correct they need to have passed the validation rules applied sometimes on multiple fields to ensure correct data is being added to the GCD database. As part of providing us the XML your organisation should also perform these checks to ensure the validity of the data you are providing.
You don't have access to ConfiForms Form on the page: Business rules Input form XML files-(member Public)
File Errors
FileError: Empty file or file without data.
Explanation: When the size of the received file is zero bytes, or no data could be read from the received file, this error is returned.
Record Errors
RecordError: No ID specified: Explanation: The ID or GRID field should be given, and should not be blank.
RecordError: Duplicate donor/CBU ID found: Explanation: Every donor or cord blood unit should be listed only once. During processing of your file, a donor or cord blood ID is listed more than once, only the first occurrence has been accepted. The second occurrence XXXXX has been rejected.
RecordError: Invalid GRID ID specified: Explanation: The global registration identified provided is invalid. PLEASE NOTE: GRID format allowed is: XXXX XXXX XXXX XXXX XXX. Also only upper case letter and numbers are allowed.
RecordError: Duplicate GRID ID found: Explanation: Every donor or cord blood unit should be listed only once. During processing of your file, a GRID ID is listed more than once, only the first occurrence has been accepted. The second occurrence XXXXX has been rejected.
RecordError: Invalid ION & GRID specified: Explanation: The GRID ID and Listing organisation (ION) ID are contradictory.
RecordError: "Collected Volume before processing" (VOL) has an incorrect value: Explanation: The "Volume Collected" (VOL) should be no less than 10, or more than 400 milliliters (ml).
RecordError: "Total Nucleated Cells" (TNC) has an incorrect value: Explanation: The "Total Nucleated Cells" should be no less than 10, or more than 999 (10^7).
RecordError: "Collected number of CD34+ cells" (CD34PC) has an incorrect value: Explanation: The value provided for the CD34+ cell count is not a numeric value with decimal point in units of 10^6.
RecordError: "Collected number of mononuclear cells" (MNC_FRZN) has an incorrect value: Explanation: The value provided for the mononucleated cell count is rounded number of mononuclear cells in the units of 10^7.
RecordError: Duplicate donor/CBU ID found: Explanation: Every donor or cord blood unit should be listed only once. If during processing of a file, a donor or cord blood ID is listed more than once, only the first occurrence is accepted, the second occurrence generates this error.
RecordError: Invalid date format for field 'field name' given: Explanation:This error may be returned for date fields. The format for dates field should be in the format YYYY-MM-DD.
RecordError: Donor is either too young or too old: Explanation:The age limits of donors are set by the WMDA. Donor age outside range of 18-60 years are rejected.
RecordError: Invalid Gender value found (not "M" or "F"): Explanation: Gender of donors other than "M" (for Male) or "F" (for Female) are reported as an error.
RecordError: Invalid CMV Status value found: Explanation: The CMV status provided is not one of the possible values for this field.
RecordError: BANK_MANUF_ID not provided: Explanation: The BANK_MANUF_ID allows the Search report to indicate that the Cord blood bank unit is accredited. If you do not provide this ID the search report will not be able to indicate the cord blood bank unit as being accredited or not.
HLA/DNA Related Errors
HLA/DNA-ERROR: Invalid allele value X found for DNA-"Allele".
Explanation: The value for DRB4 contains a slash (/) which is invalid. If such a problem is found the allele values are blanked and processing of the record continues. So, this is a warning, and not an error that requires the record to be rejected!Another examples might be an C*04:AVK (AVK is assigned bij the NMDP as 01/02/03/04/05/06) which is not valid since the C*04:02 is not assigned.
HLA/DNA-ERROR: Invalid DNA string found: "some string"
Example: For HLA A, the following value is given: 01:01/01:02/01:03/01:04.
Explanation: The DNA string given A*01:01/01:02/01:03/01:04 is not valid since the A*01:04 does not exist. Another reported problem may be that a ambiguity in the format of A*01:01/02/03 is invalid.
HLA/DNA-ERROR: Invalid HLA antigen "some value" found for field "field name".
Example: Serological HLA A30/3 is given in the file.
Explanation: The antigen or search determinant value "30/3" for HLA-A in this example is invalid.
HLA/DNA-ERROR: Incomplete typing found: HLA-A and HLA-B are required.
Explanation: At least one HLA-A and -B antigen or serological value should be available to be able to match the record. If no HLA-A or -B values (either on DNA level or on serological level) are available the record is rejected.
HLA/DNA-ERROR: "DNA allele values" does not match "serology". Equivalents for DNA alleles are ...
Example: HLA-B*15:02,15:26N does not match serological HLA-B76,62. Equivalents for the DNA-B alleles are: 75(15)
Explanation: The serology and DNA values provided, are validated separately, but also matched. If there is no match between the provided serology and the provided DNA, the record is reported.
HLA/DNA-ERROR: Number of alleles for DRB3/4/5 is more than 2; DRB3/4/5 blanked.
Example: Values are given for DRB4 for FIELD 1 and FIELD 2 and also for DRB5 for FIELD 1
Explanation: Only two allele values are allowed for DRB3, DRB4 and DRB5 combined.
HLA/DNA-ERROR: DRB3 (or DRB4 or DRB5) does not match HLA-DR "values". DRB3 (or DRB4 or DRB5) blanked.
Example: Serology DR is 4 and 11; DRB5 is 01:XX
Explanation: DRB5 is associated with DR2, DR15(2), DR16(2) or DR1(rare). Likewise, DRB3 is associated with DR3, DR5, DR6, DR11(5), DR12(5), DR13(6), DR14(6), DR1403, DR1404, DR17(3), DR18(3); and DRB4 with DR4, DR7, DR9.
Cord blood bank IDs
In the XML file format we also defined two fields that are referring to cord blood banks: BANK_MANUF_ID and BANK_DISTRIB_ID.
The BANK_MANUF_ID is the ID corresponding to the cord blood bank that manufactured the cord blood unit (CBU)
The BANK_DISTRIB_ID is the ID corresponding to the cord blood bank that will distribute the CBU
Please find in the table below the ID you have to use for your cord blood banks. The number always consist of 4 digits and is not the same as your ION number. We expect that the BANK_MANUF_ID and the BANK_DISTRIB_ID will be the same for many CBUs.
Find the name of your cord blood bank on this page
If you can find the name of your cord blood bank, click on the name of your cord blood bank en you will see on the left side in the corner a number (for example: WO-1346); you can use the four digits of this number in the file you are uploading
If you can not find the name of your cord blood bank, contact the WMDA office at: support@wmda.info
OR
Contatc the WMDA Office at: support@wmda.info
PLEASE NOTE: EMDIS is using very similar fields, but here you need to use a different ID.
Why deprecated code?
WMDA has developed HLA nomenclature guidelines, which have been published in 2007 and 2012. The HLA typing of your donors and cord blood units is validated based on these guidelines. If you list donors/cord blood units, it may happen that you receive the message that the HLA of your donor or cord blood unit is invalid.
There are two forms of ‘deleted’ alleles:
Alleles that have been renamed (e.g. A*01:34N; sequence known to be expressed at low levels and renamed to A*01:01:38L)
Alleles that have been removed without a replacement (e.g. A*2401; sequence shown to contain errors)
What you see in the report?
For data exchange between your organisation and WMDA, it is acceptable to use the older designation for renamed alleles for a period of one year after the renaming. During this grace period, you will receive the following message in your processing report (see below example messages):
#Warning at locus B*: renamed HLA code B*47:01:01:01 is still in grace period, New: 47:01:01:03
And if the deprecated code already passed one year grace period time, you will receive the following message in your processing report:
#Warning at locus B*: deprecated HLA code A*23:ABEBP is now invalid and passed its grace period hence blanked, New: 23:AFVGH 23:AZVXU
What to do with the deprecated code warning?
If you receive such warning messages, you have to update the HLA allele or MAC code within one year. WMDA will not mention the final date of the grace period in the processing report. You can find this information on: http://hla.alleles.org/alleles/deleted.html.
WMDA will provide you advice on how to replace the code. It may be that there are several options possible to update the allele or MAC code. WMDA recommends to perform the replacement using rules as following:
Always pick the same replacement code for a given deprecated code
A possible sophisticated picking strategy is to use the code with the shortest definition string. For example: if you can choose between 15:01 and 15:01N, you pick the latter. The fewer items without trailing expression character in the definition string the better. Prefer generic codes over specific codes.
Generally, definition strings containing items with trailing Q should be avoided (if possible) as alleles with expression character Q are in danger of being renamed. For example: in case of B*13:08Q you pick: B*13:08.
If you do not know, go for simple alphanumeric sorting
For 2018 the following alleles were deleted: • April 2018: B*47:01:01:01 replaced by B*47:01:01:03 • July 2018: B*56:55:01:01 replaced by B*56:55:01:02 • August 2018: A*02:17:01 replaced by A*02:17:02
2019 Update
With the recent HLA Nomenclature Release 3.35.0, the allele HLA-C*03:99 has been renamed to HLA-C*01:169. While renaming of alleles usually does not affect the first two fields of an allele name, this does and as a consequence affects the HLA haplotype frequencies (HF). In fact, we use this allele for the HF sets of DE (1 haplotype) and East Asia (eas, 15 haplotypes). The affected haplotypes have a cumulated frequency of around 1 copy for each of the two HF sets.
We have one abroad patient with that HLA-C*03:99 in the Search&Match database for whom a HLA-C mismatched donor was requested in 2017.
Summary: 1. The allele is generally very rare. 2. Therefore the effect on patients can be assessed as negligible. 3. ZKRD will replace the allele in the HF sets before it expires.
In case you need any support, we recommend to contact the WMDA at: support@wmda.info.
