Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

For more info on this please see the following slides and video from the educational webinar held on 1 September 2022. 

FeatureOptimatchHAP-EATLAS
AB searchYes (separate search)No. Technically possible, but turned off for performance reasons. No
ABDR searchYesYesYes
AB Antigen, DRB1 allele match (for cord matching)YesNot yet. Could be implemented if desired. No
Sorting performed by Matching EngineYesNo. 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 locusNoYesYes
Flexible scaling to accommodate periods of high and low use of the engineNoYesYes
Easy updating of HF SetsNoYesYes
g group level matchingYesYesYes (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). NoNoYes, but turned off at the moment in favour of g group matching. 
automatic refresh of patient searchesYesDelta search to be implemented in Search & Match.  Delta search to be implemented in Search & Match. 
differential results from matching algorithm. → algorithm tells what has changed. NoNoNo
HLA validation of DRB3, DRB4, DRB5, DQA1 and other loci not considered for matchingNoYes. 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 resultsYesYes Yes
Consider combination of serological and dna typing for match probabilityYesNoNo
support for > 2 mismatchesNoNot 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 poolNoYes. 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 GUIYes, but not fast. For performance reasons WMDA will perform server side filtering for GUI use. 
null allele handlingDoes 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. ?
TCE handling for DPB1probability based? 
TCE3
Allele frequency based TCE3TCE3 
patient level imputationAll patients are imputed based on global set. Initially: all imputed based on global HF set
Later: pool + ethn determine which HF set
match grade handling when multiple potential ARDs in donor typingWhen only 1 ARD in ambiguity list occurs in the known haplotypes → allele match ("A")Always "Potential" even if there is only 1 ARD in known haplotypes (100% potential match)
broad serology level matchingyes

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. 

  • 26 -> split serology 26, broad serology 10
  • 66:XX -> split serology 66, broad serology 10
  • Hap-E does not consider the shared broad serology as a match
  • Optimatch seems to consider them a match

Lowest probability in search results1 (0 is very rare circumstances)0
matching probability when donor haplotype cannot be explainedNo match probabilities displayed. No match probabilities displayed. No match probabilities displayed. 
directionality of DPB1 nonpermissive mismatch indicated? YesYes

Yes