Guides › IPD-IMGT/HLA releases

hla_nom_g.txt and hla_nom_p.txt: reading the G and P group files

Updated 2026-10-30 · allele examples checked against IPD-IMGT/HLA 3.66.0 on 2026-10-30

hla_nom_g.txt and hla_nom_p.txt are the machine-readable definitions of HLA G and P groups, published in the wmda folder of the IPD-IMGT/HLA repository with every release. Each data line has three semicolon-separated fields: the locus with its asterisk, a slash-separated list of alleles without the locus, and the group name without the locus, which is empty when the alleles on that line are in no named group.

Read correctly, the two files tell you which alleles a G or P code stands for in a given release. Read naively, they produce three common bugs: dropped loci, phantom groups and stale group names.

Where the files come from

The WMDA README says these files are made available at the request of the World Marrow Donor Association's IT Working Group (now its Bioinformatics and Innovation Committee), built with the WHO Nomenclature Committee, and updated every three months with each database release. Every file starts with a six-line # header naming the file, date, version, origin, repository and author. In release 3.66.0 the version line reads IPD-IMGT/HLA 3.66.0.

The group definitions themselves are on hla.alleles.org:

• A G group is the set of alleles with identical nucleotide sequence across the exons encoding the peptide-binding domains, exons 2 and 3 for class I and exon 2 for class II. It is named with the first three fields of the lowest-numbered allele plus G.
• A P group is the set of alleles encoding the same protein sequence over those domains, named with the two-field name of the lowest-numbered allele plus P.

The README explains why the G file exists: most sequence-based typing uses exons 2 and 3 for class I and exon 2 for class II, and "due to the heterozygous nature of the SBT analysis the combinations of many pairs of alleles may give an ambiguous typing result". The G and P groups guide covers the concepts; this guide covers the files.

The line format

Three real lines from release 3.66.0:

A*;01:09:01:01/01:09:01:02;01:09:01G
A*;01:02:01:01/01:02:01:02/01:02:01:03/01:02:02/01:412/01:520;01:02P
A*;03:06;

To get full names, prefix each member and the group name with field 1. 01:09:01G becomes A*01:09:01G, with members A*01:09:01:01 and A*01:09:01:02.

The third line has an empty group field. A*03:06 is an assigned allele, listed here with no group name: in this release it belongs to no named G or P group. In the 3.66.0 G file, 27,037 lines are like this; 793 lines define named G groups. The P file defines 1,580 named P groups.

What the files contain, and what they leave out

Counted in release 3.66.0:

The P file lists no null alleles at all, which follows from its definition: a null allele does not encode an expressed protein. The G file does list them, and 162 G groups contain at least one, so a G code can stand for a set that includes an allele that is not expressed. A*24:09N is in A*24:02:01G and absent from the P file. The null alleles guide covers why that matters.

Q alleles are not excluded from P groups: C*01:02:01:74Q is a member of C*01:02P.

Group names do not always describe their members

The naming rule says a group is named after its lowest-numbered member, but names are stable once assigned. The README is explicit: if the allele a group was named after is removed from it, "the group will retain the original name", and adding a lower-numbered allele does not rename the group either. It warns that a G or P group designation can therefore refer to allele groups not represented in the group.

Two kinds of example in release 3.66.0:

• A three-field G name over two-field members. The line A*;02:10/02:453;02:10:01G defines A*02:10:01G with members A*02:10 and A*02:453. No allele named A*02:10:01 exists. In the 3.66.0 G file, 125 named groups have no member whose name begins with the group's three-field stem.
• A P name from another allele group. DRB3*03:22P contains only DRB3*02:171, DRB3*02:173:01 and DRB3*02:173:02. The allele it was named after was renamed into the DRB3*02 group in release 3.46.0, and the group kept its name.

So never derive membership from the name. A*02:01:01G is not "every allele starting A*02:01:01": in 3.66.0 it also contains A*02:66, A*02:75 and null alleles such as A*02:43N, 554 members in all.

Parsing the files in Python

This parser was run against the 3.66.0 files and reproduces the counts above.

def read_groups(path):
    """Parse hla_nom_g.txt or hla_nom_p.txt into {group: [alleles]} and {allele: group}."""
    groups, group_of = {}, {}
    with open(path, encoding="utf-8") as fh:
        for line in fh:
            if line.startswith("#") or not line.strip():
                continue
            locus, members, name = line.rstrip("\n").split(";")
            alleles = [locus + m for m in members.split("/")]
            group = locus + name if name else None      # empty third field: no named group
            if group:
                groups[group] = alleles
            for allele in alleles:
                group_of[allele] = group
    return groups, group_of

g_groups, g_of = read_groups("hla_nom_g.txt")
print(len(g_groups), len(g_groups["A*02:01:01G"]), g_of["A*24:09N"])  # 793 554 A*24:02:01G in 3.66.0

Three choices in it are deliberate. It skips # lines rather than a fixed number of lines, because the README allows a disclaimer line to be added to files under development. It keeps the locus on every name, because a bare 01:09:01:01 is ambiguous across loci. And it records "no named group" as None, not as a group named after the allele, so a lookup cannot invent a group such as A*03:06G that the file does not define.

Keeping the files in step with releases

Group membership is recalculated from the sequences at every release, and the README records changes to the method too: from release 3.30, DRB G groups use the complete exon 2 sequence, which removed some groups that previously existed. A stored G or P code is only meaningful with the release whose files defined it.

• Store the release with every group code.
• Re-expand stored codes against each new release's files and record any membership change.
• Do not mix a G file from one release with an allele list from another.

POST /v1/normalize accepts G and P group names, flags them g_group_name or p_group_name, and reduces them to the two-field name they are written under, against the pinned release named in the response.

Frequently asked questions

What does an empty third field mean in hla_nom_g.txt?

The alleles on that line are in no named G group in that release. A*;03:06; lists A*03:06 without a group.

Are null alleles in hla_nom_p.txt?

No. In release 3.66.0 no name in the P file ends in N. Null alleles do appear in the G file and in 162 G groups.

Why is there a G group named A*02:10:01G when no A*02:10:01 allele exists?

Group names are stable once assigned and are not renamed when membership changes. In release 3.66.0 that group contains A*02:10 and A*02:453.

How often are the G and P group files updated?

With every quarterly IPD-IMGT/HLA release, according to the WMDA README in the repository.