Questions are divided into the following subjects:
The donor/CBU search service is only available for registry staff members and staff members of organisations assisting in searches for unrelated transplants. Find below the procedure to get access for the different types of users. You can register on the WMDA website
WMDA provides search advise for difficult cases. You can request a search advise at the bottom of the Update patient screen and the HLA experts will then help you to determine the best search strategy for your patient.
The timestamps are indeed in UTC time.
If you see this error, there can be several reasons that cause this error:
1. Your browser cache for search results may cause the issue. Please clear your browser cache and try again.
2. Can you open the login page (https://search.wmda.info/login)? If you can, and after you fill in your credential you see this error, then that is because you provided a wrong email address or password. Please double check your credentials.
3. If you cannot remember your credentials and try to reset the password, but click the password reset link more than 30 minutes after it was generated, you can see this error page. Please use the password reset link in 30 mins.
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.
If you cannot find your patient within the default Active list remember to search the Inactive list as well.
Users will have access to patients registered by other users at their organisation as well, which is also split into 'Active Patients' and 'Inactive patients'
There are different tools in the patient list to search or sort your list which will make it easier to find your patient:
- Use the Search by patient ID box when you know the patient ID or part of it.
- You can sort the list on every column (except from the results column), so you can for example sort on birth date and then find your patient.
- When you are looking for a patient not entered by yourself, you can sort on username at the view with all patients from your organisation.
No. De-activating a patient will just remove it from the OptiMatch server and the 'Active patients' list and place it in the 'Inactive patients' list.
If you need to re-activate a patient, from the Patient List section open the 'Inactive patients' list, search for the relevant patient and open the patient record. At the bottom of the page select or de-select the appropriate search type you wish to run and click on the red 'Reactivate patient' button. This will automatically trigger a re-run of the searches that were performed before and move the patient to the active list.
When you open a patient record from your inactive patients, the details cannot be edited. If you need to change details like weight, you first have to reactivate the patient. When the record is placed in the Active patient list again, you can update the details of your patient.
The patients in the patient list are default sorted on the date of last viewed. The records that have not been viewed at all are placed at the top, followed by the most recently viewed record.
The easiest way is to change the view first in your Active patient list and then go to the Inactive patient list.
No, the system does not auto correct HLA information, but may give you error warnings as applicable.
Urgent and Non-Urgent indicators on patients are a tool for you to use to prioritise your patient searches. At this time, the Search and Match Service does not use this information and will not affect the speed of your match run.
Asynchronous matching is a process of running searches in parallel. It allows you to enter a patient and start the search run, and proceed with other activities within the application like entering another patient or reviewing another match list while the search runs in the background. The user does not have to wait for the current search to finish before proceeding with other activities.
Many factors can impact how long it takes to retrieve search results. The most likely reasons that your search is taking some time is that it is a difficult search or the HLA of your patient is very common and will retrieve many records. We initially only run a 10/10, 8/8 or 6/6 search to make sure we retrieve you results as quickly as possible. Mismatch searches can take longer since there are many more options to assess before providing the results.
The system by default runs for donors a 10/10 match run using the haplotype frequency algorithm 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 respectively a 6/6 or 8/8 match run. 10/10, 8/8 and 6/6 are all considered as zero mismatch runs and will not include mismatch donors in the results.
The system by default runs for cords a ≥8/10 match run at allele level using the haplotype frequency algorithm.
By default, the Search & Match Service only provides 10/10, 8/8 or 6/6 matches initially. Selecting the 'Run Mismatch' search button allows you to request a mismatch search to review e.g. 9/10 or 7/8 match results. Once those results return, you will be able to review them by specific loci mismatches or any loci.
No, at this moment you can only run a zero mismatch donor and/or ≥8/10 cords run as a first match run. You have to requested the mismatch donor run after you retrieved the zero mismatch run results.
Allele frequencies give the proportions of individual alleles. Haplotype frequencies give the proportions of specific haplotypes i.e. several alleles in phase and therefore preserve linkage information.
If you are experiencing difficulties in your selection of a donor/cord for your patient, you can request a search advice from the WMDA HLA experts. To request an advise, go to your patient list, click on the patient ID and at the bottom of the Update patient form you will find a button with 'Request Search Advisory'. An email message will then open with the patient information and some additional fields with requirements. Please fill out as much as possible and send the email. You will receive the advice also by email.
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.
Only changes applied from the search setting box will be saved to your search results. Any other on-screen filters or flags won't be saved and are reset by the system when you leave the search results page.
The default sorting criteria from OptiMatch for donors are:
2. probability in 10% intervals
3. donor age in 5 year intervals for adults
The default sorting criteria from OptiMatch 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
DPB1 TCE3 evaluation is performed only for A-B-DR(B1) typed donors under the following conditions:
- 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.
- The 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: 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.
The default sorting criteria from OptiMatch are:
2. probability in 10% intervals
3. donor age in 5 year intervals
Yes, all cords are sorted based on out of 6 HLA matching and TNC. So on top of your results you will find potential 6/6 matched cords with the largest unit (based on TNC) one on top of the page, followed by the 5/6 cords and 4/6 cords (depending on the match type you selected).
It is not possible to sort the search results in the match results table. You do have the ability to use many filters and to use different match types.
These donors don't have haplotype probabilities. This is usually the case when the phenotype could not be explained with the haplotypes given in the frequency set (inexplicable donor). Without haplotypical context, the programme gives only allele frequencies for the tested loci.
Part 1: Since B*15:BPXE = B*15:03/61/74/103 a donor with this codes is a potential allele match for the patient. According to the official WMDA serology/DNA correspondence table, B*15:61 and B*15:74 have a serology of B15/B70 while B*15:03 is B72 and B*15:103 is B70. As a consequence a serology of B15 rules out B*15:03 and this donor is no longer potentially identical (on the allele level). Another explanation could be the limited length of donor lists.
Part 2: In the old BMDW serology was ignored when DNA typing was available so B*15:03 was not excluded. The new system does not modify or ignore donor data and respects and relies on the responsibility of the providing registry for its data.
Background: Unfortunately, for many donors serology was derived from DNA (by using the first field for the serological assignment) and vice versa (by appending “:XX” to the serological assignment) and often eventually both values are reported. In the case discussed, B*15:BPXE probably was translated back into B15 which is most likely wrong. This is a typical and (with certain registries) frequent case but there are many more unexpected DNA-serology correspondences that can give rise to exactly the same situation.
OptiMatch 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 OptiMatch.
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 OptiMatch. Below are some possible (not mutually exclusive) reasons:
- The allele designations encode for the identical ARD (antigen recognition domain) and OptiMatch 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 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.
- 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).
- 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.
In rare cases the match program cannot decide which of two B locus results are a mismatch, in those cases both are given in bold. For example, the patient is B*27:05, 44:03; the donor is B*44:ABYM, 44*AFFK. In this case both multiple allele codes include 44:03 therefore the match program cannot choose between them. See example image below where donor 12 on the search report is being marked as having two HLA-B mismatches, when actually it is only a single mismatch.
The patient's 5 locus phenotype (10/10) cannot be explained by the haplotypes used for probability matching. The algorithm tries to fall back to 4 locus phenotypes (8/8) and 3 locus phenotypes (6/6).
- The patient's 5 locus phenotype (10/10) cannot be explained by the haplotypes used for probability matching. The algorithm tries to fall back to 4 locus phenotypes (8/8) and 3 locus phenotypes (6/6).
- If the HLA of the patient does not contain information for all 5 loci, the system will automatically scale the match run down to 8/8 or 6/6 depending on the available HLA information of the patient.
Most likely, the donor's phenotype cannot be explained by the haplotypes used for probabilistic matching.
Currently, 10/10, 8/8 and 6/6 lists are reserved for donors that have no known mismatches. Donors that have known mismatches for your patients will only be returned when you select "Run a Mismatch Search" and then select to view a 9/10 or 7/8 match type results list.
A*02:01 (2) vs. 02:03 (203) is an allele mismatch because A203 is an associated antigen to A2.
B*15:01 (62) vs. B15:03 (72) is an antigen mismatch.
The probabilities shown in your match results table are based on allele level matching and do not correspond with this particular match type.
Currently this feature is not implemented. However, this could be a feature for upcoming versions of the matching program.