⚠Due to planned maintenance you will experience short (<30 min) downtime between 08:00 - 08:30 CET.
Feature | Optimatch | HAP-E | ATLAS |
---|---|---|---|
AB search | Yes (separate search) | Included in standard search (only n/n and n-1/n) | No |
ABDR search | Yes | Yes | Yes |
AB Antigen, DRB1 allele match (for cord matching) | Yes | To Do | No |
Sorting performed by Matching Engine | Yes | No | Yes, but WMDA will override with own sort parameters |
Information about probability of match at other allele at already mismatched locus | No | Yes | Yes |
Flexible scaling to accommodate periods of high and low use of the engine | No | Yes | Yes |
Easy updating of HF Sets | No | Yes | Yes |
g group level matching | Yes | Yes | No → Yes (actually "P" group matching) |
G group level matching (leading to less populations and lesser performance for some of populations, but better matching for other populations). | No | No | Yes, but turned off at the moment in favour of g group matching. |
automatic refresh of patient searches | Yes | delta search handled by Search | delta search handled by Search |
differential results from matching algorithm. → algorithm tells what has changed. | No | No | No |
HLA validation of DRB3, DRB4, DRB5, DQA1 and other loci not considered for matching | No | Yes | ? |
Performing a mismatch search will return also (potentially) matched results | Yes | Yes | No (currently) for donors, Yes for cords |
Amount of searches that can reasonably run in parallel | 3 | 12 | 1 per vCore in the DB |
consider combination of serological and dna typing for match probability | Yes | No | No |
support for > 2 mismatches | No | can also be 2 or more mismatches on ABDRB1. will be done. >=4/8 all loci to be considered need to be typed at high resolution for patient. | yes, >= 4/8 |
HLA imputation based on patient organisation and/or pool | No | Yes | ? |
mismatches per locus can be sent directly to matching engine? | Yes, during actual search and during retrieval. | No. Server side filtering needed for API and GUI | Yes, but not fast. For performance reasons WMDA may decide to perform server side filtering for GUI use. |
null allele handling | Does not return donors with XX or also with some MAC codes? Not matching homozygous typing. | will return donors which match haplotype with known null allele. Will be marked in search results. | ? |
TCE handling for DPB1 | probability based? TCE3 | allele frequency based TCE3 | TCE3? based on probabilities? Did not provide allele frequencies |
patient level imputation | global set? Everything is INT patient | initially: all imputed based on global HF set Later: pool + ethn determine which HF set | ? |
match grade handling when multiple potential ARDs in donor typing | when only 1 ARD in ambiguity list occurs in the known haplotypes → allele match ("A") | always "P" even if there is only 1 ARD in known haplotypes (100% potential match) | |
broad serology level matching | yes | No. Split serology will only match same split serology or when donor/patient is broad serology. Not matched when patient/donor has split serology that is different but both share same broad serology. e.g.
| |
Lowest probability in search results | 1 (0 is very rare circumstances) | 0 | |
matching probability when donor haplotype cannot be explained | null probability | ||
directionality of DPB1 nonpermissive mismatch indicated? | yes | yes | No, but filed an "issue" |