Page History

Patient information can be accessed from the 'Patient List' by selecting the "Patient ID'. The patient information can also be accessed from the Patient's Match Result List by opening the 'Patient Details' box and selecting the 'Edit Patient' button. 

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

The patients in the patient list are default sorted on the date of last viewed. The records Records that have not been viewed at all are placed at the top, followed by the most recently viewed record.created are also considered to be "viewed" and there will therefore appear at the top after creation. 

By default, Search & Match performs a 10/10 search for donors if all 5 loci (A,B,C,DRB1,DQB1) are available for the patient. If only 3 or 4 loci are available, the system will scale down to a 6/6 or 8/8 search, respectively. 10/10, 8/8 and 6/6 are all considered as zero mismatch searches and will not include mismatch donors in the results. For CBUs, Search & Match performs a ≥8/10 search in all cases, irrespective of available patient typing.This is also the case for cord searches. 

Setting the filters in the 'Search Settings' on the Search results page prompts a new search request with those parameters. These filters will also not influence the number of results you will retrieve and will be saved in your search results.

The heading/ on-screen filters on the match results table will filter and reduce the results list that is already available. Donors and cords will retain their row number from the original list without any on-screen filters applied. The on-screen filters will not be saved to your search results and when you leave the search results page the on-screen filters will no longer be there when you come back.There is no functional difference. The filters you see on top of the headings in the search results are the frequently used filters. All filters are applied to all search results. 

DPB1 TCE3 evaluation is performed only for A-B-DR(B1) typed donors under the following conditions: typed donors under the following conditions: 

• Patient
• Patient DPB1 values must be present. Typing ambiguities in the form of multiple alleles codes, G-codes, etc. are allowed.
• Donor DPB1 values must be present. Typing ambiguities in the form of multiple alleles codes, G-codes, etc. are allowed.
• Donor DPB1 values must be present. Typing ambiguities in the form of multiple alleles codes, G-codes, etc. are allowedThe donor must be in the group of potential "9/10" and "10/10" identical donors. Therefore, it is implicitly assumed that a 5-locus search report is retrieved and can be accessed. In case of a 4- or 3-locus search reports or deactivation of the grouping by allele differences, there will be no TCE3 grading.

As part of the DPB1 TC3 grading filter, you can filter the results by the following options: Matched, Permissive, Non-permissive in HvG direction, Non-permissive in GvH direction, Ambiguous, Unknown.

Although the DPB1 TC3 filter is available for cords, the results haven't been validated so it shouldn't be used.

Hap-E Search and ATLAS Match 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 apply the filter to see male donors only.

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 Hap-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 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 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 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.