Feature | Optimatch | HAP-E | ATLAS | |
---|---|---|---|---|
AB search | Yes (separate search)Included in standard search (only n/n and n-1/n) | No. Technically possible, but turned off for performance reasons. | No | |
ABDR search | Yes | Yes | Yes | |
AB Antigen, DRB1 allele match (for cord matching) | YesTo Do | Not yet. Could be implemented if desired. | No | |
Sorting performed by Matching Engine | Yes | No. WMDA Search and Match performs sorting. | 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 to be implemented in Search & Match. | Delta search to be implemented in Search & Match. 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. Also performed by Search & Match during patient creation/update. | Performed by Search & Match during patient creation/update. ? | |
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 consider combination of serological and dna typing for match probability | Yes | No | No | |
support for > 2 mismatches | No | Not yet. Will also be 2 or more mismatches on ABDRB1. >=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. Not yet implemented in Search & Match. | ? | |
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 will 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 Will return donors which match haplotype with known null allele. Will be marked in search results. | ? | |
TCE handling for DPB1 | probability based? TCE3 | allele Allele frequency based TCE3 | TCE3? based on probabilities? Did not provide allele frequencies | TCE3 |
patient level imputation | All patients are imputed based on global set? Everything is INT patient. | Initiallyinitially: 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 When only 1 ARD in ambiguity list occurs in the known haplotypes → allele match ("A") | always Always "PPotential" 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 explainednull probability | No match probabilities displayed. | No match probabilities displayed. | No match probabilities displayed. | |
directionality of DPB1 nonpermissive mismatch indicated? | yesYes | yes | Yes | Yes No, but filed an "issue" |