You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 36 Next »

#

1. Introduction

2. XSD schema files

XML file format

1. Introduction

The overall scope of BMDW development phase two is to receive more data from our listing organisations and to make these data available through our Search & Match Service. However, the old format (DOT20) is not an appropriate format when you have many different fields/columns. Therefore, we had to move to another file format. The new file format is an 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

We provided 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.

 We will now describe the global structure of the XML file and the elements.

2.1 InventoryType elements

Field Identifier

Required

Description

Type

Length

Comment

CREATION_TIMEYesCreation time stamp of the inventories (in UTC)dateTimeminimal 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_ORGANIZATIONYesOrganisation that lists the donor/cbu provided as IONionType: number between 1000 and 99994Issuing Organisation Number (ION) allocated by ICBBA. This can be different from the POOL when another organisation is sending the data to BMDW.
POOLYesPhysical location of the donors/CBUs of the inventory provided as IONionType: number between 1000 and 99994Physical location of the donors/CBUs of the inventory provided as ION.
CONTENT_TYPEYesType of the inventory items, i.e. donor ("D") or CBU ("C")contentTypeType1The 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_MODEYesUpdate mode of the inventory, i.e. FULL or DIFFupdateModeType4Only UPDATE_MODE "FULL" is currently supported. Always the complete inventory should be send.
SNAPSHOT_TIMENoTimestamp of the 'data snapshot' (in UTC)dateTimeminimal 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_VERSIONYesVersion 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

IDYesUnique identifier of the donor/CBUString17Unique identifier of the donor/CBU: The value comprises the EMDIS hub code + donor identification allocated by the associated donor registry, where the sending organisation is an EMDIS member, otherwise the 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
GRIDNoGlobal registration identifier of the donor/CBUString19 
ATTRNoDescribing attribute of the donor/CBU according to house rules of the sending organization.String3 
BIRTH_DATEYesDate of birth of the donor/CBUbareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
SEXNoBiological gender of the donor/CBUsexType1

sexType: "F","M"

NOTE: Mandatory for donors, optional for CBUs

ABONoBlood group (ABO) of the donor/CBUaboType2aboType: "A","B","O","AB"
RHESUSNoRhesus (Rh) factor of the donor/CBUrhesusType1

rhesusType: "P","N"

NOTE: "+" and "-" are not supported

ETHNNoEthnic group of the donor/CBUethnType4

ethnType: "AFNA","AFSS", "ASSW", "ASSO", "ASCE", "ASSE", "ASNE", "ASOC", "CAEU",
"CAER", "CANA", "CAAU", "HICA", "HISA", "AF", "AS", "CA", "HI", "MX", "OT","UK"

CCR5NoCCR5 status of the donor/CBUccr5Type2ccr5Type: "DD","WW","DW"
HLAYesHLA of the donor/cbuhlaType Explained separately at hlaType 2.3
KIRNoKIR genotype of the donor/CBUkirType Explained separately at kirType 2.4
IDMNoInfectious disease markers (IDM) and other relevant tests of the donor/CBUidmType Explained separately at idmType 2.5
RSV_PATNoUnique identifier of the patient the donor/CBU is reserved for (STATUS=RS).String17

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.

STATUSYesStatus of the donor/CBUstatusType2statusType: "AV","TU","RS" ("DE" is not supported yet, "RE" not valid for CBUs)
STAT_END_DATENoDate until which the current status will be applicablebareDateType10

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>”;

Example: <SER><FIELD1>1</FIELD1><FIELD2>5</FIELD2></SER>

Serological typing results can be given for loci that are defined as hlaLocusType. These loci include HLA-A, -B, -C, -DRB1, -DQB1.

 

hlaDnaFieldsType: HLA values obtained by DNA based typing methods

hlaDnaFieldsType = “<FIELD1>” string of max length 20 “</FIELD1>”, “<FIELD2>” string of max length 20 “</FIELD2>”;

Exanple: <DNA><FIELD1>01:01</FIELD1><FIELD2>05:01</FIELD2></DNA>

DNA typing results can be given for loci that are defined as hlaLocusType and hlaLocusDnaOnlyType. These loci include HLA-A, -B, -C, -DRB1, -DQB1, -DRB3, -DRB4, -DRB5, -DQA1, -DPA1, -DPB1.

Finally, '01:XX' is equivalent to '01'. Both codes '01:XX' and '01' are allowed.

 

Minimal required elements

Minimal typing values for Donor: A (either SER or DNA), B (either SER or DNA)

Minimal typing values for CBU: A (either SER or DNA), B (either SER or DNA), DRB1 (either SER or DNA)

 

Please note:

  • It is no longer possible to submit string HLA values; only single values are allowed.
  • When a donor or CBU has homozygous alleles/values, please use the following notation:

<HLA><A><SER><FIELD1>1</FIELD1><FIELD2 /></SER></A> ...
or
<DQB1><DNA><FIELD1>05:02:01G</FIELD1><FIELD2 /></DNA></DQB1>

 

Field Identifier

Required

Description

Type

Length

Comment

SERdepends on content type and DNA fields providedHLA values obtained by serological typing methodshlaSerFieldsType5Each SER element contains two other elements: FIELD1 and FIELD2
DNAdepends on content type and SER fields providedHLA values obtained by DNA based typing methodshlaDnaFieldsType20Each DNA element contains two other elements: FIELD1 and FIELD2
FIELD1 HLA value of allele 1 5 or 20Element within the element SER and DNA
FIELD2 HLA value of allele 2 5 or 20Element within the element SER and DNA
AYesHLA-A valueshlaLocusType Both SER and DNA possible; either SER or DNA values required
BYesHLA-B valueshlaLocusType Both SER and DNA possible; either SER or DNA values required
CNoHLA-C valueshlaLocusType Both SER and DNA possible
DRB1Yes (CBU) No (Donor)HLA-DRB1 valueshlaLocusType Both SER and DNA possible; either SER or DNA values required for CBU
DRB3NoHLA-DRB3 valueshlaLocusDnaOnlyType Only DNA possible
DRB4NoHLA-DRB4 valueshlaLocusDnaOnlyType Only DNA possible
DRB5NoHLA-DRB5 valueshlaLocusDnaOnlyType Only DNA possible
DQA1NoHLA-DQA1 valueshlaLocusDnaOnlyType Only DNA possible
DQB1NoHLA-DQB1 valueshlaLocusType Both SER and DNA possible
DPA1NoHLA-DPA1 valueshlaLocusDnaOnlyType Only DNA possible
DPB1NoHLA-DPB1 valueshlaLocusDnaOnlyType Only DNA possible

 

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:

<KIR2DL1>,<KIR2DL2>,<KIR2DL3>,<KIR2DL4>,<KIR2DL5A>,<KIR2DL5B>,<KIR2DS1>,<KIR2DS2>,<KIR2DS3>,<KIR2DS4>,<KIR2DS5>,<KIR2DP1>,<KIR3DL1>,<KIR3DL2>,<KIR3DL3>,<KIR3DS1>,<KIR3DP1>.

There is another field called <KIR_GL> (URI that refers to a GL-string registered with a GL-service or direct GL-string for absence / presence) this field is not used at the moment and must be empty.

 

Field Identifier

Required

Description

Type

Length

Comment

KIR gene e.g. KIR2DL1NoKIR genotype e.g. KIR gene 2DL1kirLocusType3valid values: "POS" = presence of KIR gene; "NEG" = absence of KIR gene

 

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”

Field Identifier

Required

Description

Type

Length

Comment

CMVNoCMV statusidmValueExtType1

idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”

EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the BMDW data submission file.

CMV_NATNoCMV NAT statusidmValueType1idmValueType: "P","N"
CMV_DATENoDate of CMV testbareDateTyp10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
HBS_AGNoHepatitis B status (hepatitis B surface antigen)idmValueType1idmValueType: "P","N"
ANTI_HBCNoHepatitis B status (antibody to hepatitis B core antigen)idmValueType1idmValueType: "P","N"
ANTI_HBSNoHepatitis B status (antibody to hepatitis B surface antigen)idmValueType1idmValueType: "P","N"
ANTI_HCVNoHepatitis C status (antibody to hepatitis C virus)idmValueType1idmValueType: "P","N"
ANTI_HIV_12NoAnti-HIV 1/2 statusidmValueType1idmValueType: "P","N"
HIV_1_NATNoHIV-1 NAT statusidmValueType1idmValueType: "P","N"
HIV_P24NoHIV p24 statusidmValueType1idmValueType: "P","N"
HCV_NATNoHCV NAT statusidmValueType1idmValueType: "P","N"
ANTI_HTLVNoAntibody to HTLV I/IIidmValueType1idmValueType: "P","N"
SYPHILISNoSyphilis statusidmValueType1idmValueType: "P","N"
WNVNoWNV statusidmValueType1idmValueType: "P","N"
CHAGASNoChagas statusidmValueType1idmValueType: "P","N"
EBVNoEBV statusidmValueExtType1

idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”

EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the BMDW data submission file. Please leave blank for Q.

TOXONoToxoplasmosis statusidmValueExtType1

idmValueExtType: “P”,“G”,“M”,“B”,“H”,“O”,“N”

EMDIS data dictionary also has a ‘Q’ (questionable / unclear) but that will not be applicable within the BMDW data submission file. Please leave blank for Q.

HBV_NATNoHBV NAT statusidmValueType1idmValueType: "P","N"
PB19_NATNoParvoB19 NAT statusidmValueType1idmValueType: "P","N"
ALTNoAlanine aminotransferase status in units per litreShort 

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

STAT_REASONNoAdditional information relevant to the donor statusstatReasonDonType2statReasonDonType: "DO", "DD","MR", "PR","TX", "MO", "UC", "TQ", "OT", "UK"
CONTACT_DATENoDate 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).bareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
CHECKUP_DATENoDate 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.bareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
WEIGHTNoWeight in kgShort Number between 1 and 999, no decimals
HEIGHTNoHeight in cmShort Number between 1 and 999, no decimals
NMBR_TRANSNoNumber of blood transfusionsShort Number: zero or greater, no decimals
NMBR_PREGNoNumber of pregnanciesShort Number: zero or greater, no decimals
NMBR_MARRNoNumber of marrow donationsShort Number: zero or greater, no decimals
NMBR_PBSCNoNumber of PBSC donationsShort Number: zero or greater, no decimals
COLL_TYPENoCollection type, i.e. the willingness of the donor to donate in a specific mannerString1collTypeType: "M", "P","B"

 

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

STAT_REASONNoAdditional information relevant to the CBU statusstatReasonCbuType 2statReasonCbuType: "QR","AD","CD","DS","XP","MR","MO","OT","UK"
LOCAL_IDNoIdentification of CBU locally at the associated CBBString17 
BAG_IDNoIdentification as it appears on the bag. If more than one bag is available then this data attribute is not populatedString17 
BANK_MANUF_IDNoUnique identifier of the CBB that manufactured the CBU: The value comprises the EMDIS hub code + id allocated by the associated EMDIS hub, where the cord registry is an EMDIS member, otherwise the two digit ISO country code of the associated cord registry + id identification allocated by the associated cord registry. For example: AUCBB1, SB890String10

PLEASE NOTE: For the upload to BMDW the fields BANK_MANUF_ID and BANK_DISTRIB_ID should be fulfilled with a new ID for the corresponding cord blood banks. These new IDs will be generated by BMDW and sent out to the registries so that they are able to fulfill the two ID fields or at least the BANK_MANUF_ID field.

 

These IDs are important to allow BMDW to identify if the CBU is from an accredited bank which will be displayed within a search report.

BANK_DISTRIB_IDNoUnique identifier of the CBB distributing the CBU: The value comprises the EMDIS hub code + id allocated by the associated EMDIS hub, where the cord registry is an EMDIS member, otherwise the two digit ISO country code of the associated cord registry + id identification allocated by the associated cord registry. For example: AUCBB1, SB890String10 Please see note above
COLL_DATENoDate that the CBU was collectedbareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
PROC_DATENoDate that the processing startedbareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
PROC_METHNoProcessing method usedprocMethType3

procMethType: "HES","DGS","CEN","FIL","FIC","PER","OTH"

NOTE: Values "NOT" and "UNK" are not supported

"NOT" can now be found in CB_PROD_MOD = "NOT",  "UNK" has to be transmitted as empty (CB_PROD_MOD = "")

PROC_METH_TYPENoProcessing method type usedprocMethTypeType3procMethTypeType: "MAN","SPX","OTP","AXP","OTH"
FREEZE_DATENoDate that the CBU was frozenbareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
FREEZE_METHNoFreezing method usedfreezeMethType1freezeMethType: "C","M"
PROD_MODNoProduct modifications madeprodModType3prodModType: "BCE","DNE","PLR","PRR","RBR","NOT","OTH"
BAG_TYPENoType of bag used (bag fractions / split unit)bbagTypeType5bagTypeType: "80/20","50/50","40/60","NS"
BAGSNoNumber of bags for CBU sub unitsShort Number between 1 and 99, no decimals
BACT_CULTNoBacterial culturecultValueType1cultValueType: "P","N","D"
FUNG_CULTNoFungal culturecultValueType1cultValueType: "P","N","D"
HEMO_STATUSNoHemoglobinopathy screening statushemoStatusType2hemoStatusType: "DN","DU","NS","CD","NC","DT","DD"
VOLNoCollected volume before processing (without additives) in mlShort Number between 1 and 9999
VOL_FRZNNoTotal volume frozen (post processing, prior to cryopreservation) in mlShort Number between 1 and 9999
TNCNoTotal number of nucleated cells (before processing)Float Number with decimals
TNC_FRZNNoTotal number of nucleated cells (post processing, prior to cryopreservation)Float Number with decimals
RED_BC_FRZNNoTotal number of nucleated red blood cells (post processing, prior to cryopreservation)Float Number with decimals: minimum is 0.0E0, maximum is 999.9E7
MNC_FRZNNoTotal Number of mononucleated cells (post processing, prior to cryopreservation)Float Number with decimals
CD34PCNoTotal number of CD34+ cells (before processing)Float Number with decimals
CD34PC_FRZNNoTotal number of CD34+ cells (post processing, prior to cryopreservation)Float Number with decimals
CFU_FRZNNoTotal count of colony forming units (post processing, prior to cryopreservation)Float Number with decimals
VIABILITYNoViability as percentage valueShort Number between 0 and 100, no decimals
VIABILITY_DATENoDate that viability was testedbareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
VIABILITY_CELLSNoType of cells tested for viabilityviabilityCellsType6

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_METHODNoMethod used to calculate the viabilityviabilityMethodType2viabilityMethodType: "7A","PI","TB","OT"
ATT_SEGNoNumber of attached segments availableShort Number between 0 and 99, no decimals
DNA_SMPLNoDNA samples available?Boolean true,false
OTH_SMPLNoSamples other than DNA available?Boolean true,false
CT_COMPLETE_DATENoDate of completion of confirmatory typing (CT)bareDateType10Date without timezone information, example 1968-06-28, Date Delimiter = "-"
CT_SMPL_TYPENoConfirmatory typing (CT) sample typectSmplTypeType2ctSmplTypeType: "AS","WB","RC","FP","ED"
AL_RED_BCNoNumber of red cell fraction aliquotsShort 

Number between 0 and 99, no decimals

AL_SERNoNumber of serum aliquots availableShort Number between 0 and 99, no decimals
SER_QUANTNoTotal quantity of serum available in mlFloat Number between 0.0 and 99.9, one decimal
AL_PLANoNumber of plasma aliquots availableShort Number between 0 and 99, no decimals
PLA_QUANTNoTotal quantity of plasma available in mlFloat Number between 0.0 and 99.9, one decimal
MATNoData of the mother of the infant associated with the CBUmatType 

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

IDNoIdentification used to identify the maternal donor as assigned by the registryString15 
ID_BANKNoIdentification used by associated CBU manufacturer to identify maternal detailString15 
HLANoHLA of the mother of the infant associated with the CBUhlaType see above in section 2.3 hlaType
IDMNoInfectious disease markers (IDM) and other relevant tests of the mother of the CBUidmType see above in section 2.5 idmType
AL_SERNoNumber of serum aliquots availableshort Number between 0 and 99, no decimals
SER_QUANTNoTotal quantity of serum available in mlFloat Number between 0.0 and 99.9, one decimal
AL_PLANoNumber of plasma aliquots availableShort Number between 0 and 99, no decimals
PLA_QUANTNoTotal quantity of plasma available in mlFloat 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.


A DONOR record should include:

  • ID
  • 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. These two examples are based on the XSD files version 2.1.

 

Example donor file: ION-1234-D.xml

Example CBU file: ION-1234-C.xml

 

#

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

 

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

  1. Click to highlight the file that you need to zip. Please note: BMDW can only accept your file when the zip file contains 1 file.
  2. Right-click the file and select Send to > Compressed (zipped) Folder.  
  3. 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

  1. Open a new Finder window and navigate to the file.
  2. Click to highlight the file that you need to zip.
  3. 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.
  4. 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

  1. Open a terminal session and navigate to the location of your file
  2. To view a listing of directory contents, enter the following command: ls
  3. Note the files to be zipped.  
  4. 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

 

BMDW 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 encrypted 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 BMDW; decryption is performed by BMDW to be able to process and validate the data in your file.

For this encryption, you should use the BMDW public key.

This is the new BMDW public key: BMDW public key

Please note: This key is different from the key that you used to encrypt your DOT20 file.

STEP 1: Encryption program

The DOT20 file you sent before to BMDW also needed to be encrypted. The procedure is actually the same, but you now have to use the new BMDW 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.

Here are some examples:

Windows: Kleopatra, PGP Tool

OS (MAC): GPG Suite

Linux/unix: GnuPG

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 BMDW public key

After installing your preferred program, you have to import the BMDW public key.

  • First download the key to your computer.
  • 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 BMDW public key and save the key.

For Linux/Unix, importing of the key in your gpg keyring can be done by using the following command:

$ gpg --import {public_key_file}

STEP 3: Encrypt XML or ZIP file with BMDW public key

Next step is to use the BMDW 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 BMDW 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 BMDW 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.

 

#

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 to BMDW you will receive a processing report in your BMDW 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.

BMDW – Business validation rules applied

BMDW 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 to BMDW. These rules will be published later.

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 that BMDW adheres to, 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".

Example: <HLA><DRB4><DNA><FIELD1>01:01/</FIELD1><FIELD2>value</FIELD2></DNA></DRB4></HLA> 

 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.

 

  • No labels