Page History

No. De-activating a patient will just remove it from the OptiMatch Hap-E Search and ATLAS server and the 'Active patients' list and place it in the 'Inactive patients' list.

The default sorting criteria from OptiMatch Hap-E Search and ATLAS for donors are: 

1. HLA

2. probability in 10% intervals

3. donor age in 5 year intervals for adults

The default sorting criteria from OptiMatch Hap-E Search and ATLAS for cords are: 

1. HLA (6/6, 5/6, 4/6 categories)

2. Number of total nucleated cells (TNC) for cords within HLA match category

The default sorting criteria from OptiMatch Hap-E Search and ATLAS are:

1. HLA

2. probability in 10% intervals

3. donor age in 5 year intervals

OptiMatch Hap-E Search and ATLAS does not consider binary attributes like gender or CMV for  sorting at all. If you see a rich donor list and prefer, for example,  male donors you should use the filtering capability of OptiMatchthe algorithms.

Rationale: There is no agreed concept for weighing secondary match  criteria like age, gender or CMV against each other. The approach to sort by probability in blocks and then by age plus ad hoc filtering gives the user maximum control of the appearance of the list.

This can happen only if the difference in resolution is not  considered sufficiently relevant in the given context by OptiMatchHap-E Search and ATLAS. Below are some possible (not mutually exclusive) reasons:

1. The allele designations encode for the identical ARD (antigen  recognition domain) and OptiMatch Hap-E Search and ATLAS only matches for the ARD part of the HLA protein complex. For example B*07:ANVB stands for B*07:02/07:61 which both encode for the same ARD (here: exon 2 and 3). Hence OptiMatch Hap-E Search and ATLAS is regarding the codes B*07:02, B*07:61 and B*07:ANVB all as allele matches for each other but might give different matching probabilities for phenotypes containing each of those three codes since haplotypes  involving B*07:02 and B*07:61 are having individual frequencies.
2. The resolution only looks higher but, in fact, is lower (e.g.  B*15:12 currently is only a single allele while B*15:12:01G covers three), identical (e.g. A*80:01, A*80:01:01 and A*80:01:01G cover exactly the same alleles) or not directly comparable since each code is containing some alleles not covered by the other (e.g. comparing  B*07:TDVB and B*07:02:01G the former also covers a lot more variants of  B*07:02 like  B*07:02:02 to B*07:02:05 while it is excluding other alleles like B*07:44 and B*07:49N).
3. The broader code only contains additional alleles which have never  been observed in the population whose haplotype frequencies are used - at least not in a relevant haplotypical context. Their frequency could  also be so low that it is disregarded due to rounding or the 10%  probability grouping explained elsewhere. This applies, in particular,  to all null variants of expressed alleles with identical first two field  designations.