HLA (MAC) Validation

[mmelchers]

We were wondering to what extent ATLAS is able to validate the HLA that is coming in with a search and with the donors. We were able to find some code for generating and updating the storage tables and for importing MAC codes and valid alleles, but we haven't been able to find how you are doing MAC code verification itself. This because a MAC code (just the letters) could exist, but when one of its decoded alleles (so including locus and first field) does not exist, it automatically makes this particular HLA typing invalid. How do you check that? Which part of the ATLAS code base takes care of that?

[zabeen]

Existing MACs that expand to an "invalid" list of alleles would be discovered during lookup of the HLA typing within the HLA metadata dictionary component, causing an invalid HLA exception.

This integration test covers the scenario you describe:

Atlas/Atlas.HlaMetadataDictionary.Test/IntegrationTests/Tests/SearchRelatedMetadataServiceTests.cs

Line 59 in dc7b0ec

public void GetHlaMetadata_WhenMacContainsAlleleNotInHlaMetadataDictionary_ThrowsException()

[benbelow]

FWIW I believe this is the relevant ADR for this decision https://github.com/Anthony-Nolan/Atlas/blob/master/ArchitecturalDecisionRecord/Phase1/003-MultipleAlleleCodeLookup_Storage.md

this ADR covers the differences between Atlas and the old Anthony Nolan algorithm more than it makes this specific decision explicit. I think this line Generic MACs only contain information about the alleles' second fields, and are applicable to any first field. At time of lookup, the given first field will need to be added to all expanded second fields before individual alleles can be processed. implies what Zabeen said above - although it could be clearer. If I get a free second I can add the implication that This means that it is possible to expand a MAC to invalid alleles - these will not be validated by the MAC component, but each individually expanded allele should be validated by the appropriate nomenclature HLA Metadata Dictionary

I wonder if it's also worth emphasizing that this approach allows the MAC lookup component to be nomenclature agnostic - as otherwise the expansion of a single MAC/first field/locus could be valid in one nomenclature version, and not the next

[mmelchers]

Thanks Ben. Unfortunately it is not always true that the MAC code only has information on the alleles' second fields. It also forces the first field in some cases. An example of this is "ZHXJ". So if you want to do proper validation, you also check whether the first field in the MAC code file matches the first field for these special MAC Codes.

[benbelow]

@mmelchers you're right - I remember this coming up early in the Atlas project.

I believe the choice was made to not validate such cases - IIRC, we never found an internationally agreed standard for which first field should be used in the case of expanding to multiple first fields - I recall discussing whether it should be the first option, any represented one, or the most frequent one, but don't remember getting a definitive answer.

I also think we came to the conclusion that as the MAC ZHXJ includes the first fields in the expanded result - so it's impossible to expand to incorrect HLA.

Given the short timescale of the project, the minimal (arguably zero) impact on search, and the lack of this requirement in our agreed spec, this specific form of validation was not implemented by the initial project team.

If you think that this edge case should be covered, can I recommend:

• Raising an issue in the Atlas repository detailing the changes that need to be made
• Provide a reference for the international standard for correctly identifying the "valid" first field (or fields) for such codes
• Discuss prioritisation of said issue with AN in our teams instance

Cheers, and apologies for the delay, I think I was away when you posted this and didn't notice it until now!