A willing donor is not always a matching donor.
ISOT SWAP is the national paired-exchange registry of the Indian Society of Organ Transplantation. When a donor cannot give to their own recipient, it finds the pair — or the ring of pairs — where everybody can.
Each of them is a mismatch between two particular people — not a defect in the donor. Put enough pairs in one registry and the mismatches cancel out.
An O recipient can receive only from an O donor. A willing B donor for an O patient is a transplant that cannot happen — and, somewhere in the registry, exactly the donor another patient is waiting for.
Eleven loci are typed on each side. The closer the match, the better the graft is tolerated. The registry scores every possible pairing by locus weight rather than counting mismatches equally.
A recipient sensitised by pregnancy, transfusion or a previous graft carries antibody against specific HLA. Every bead of their single antigen panel is checked against the donor's alleles before a pairing is offered.
Recipient and donor: demographics, medical history, serology, HLA typing, and the donor criteria this recipient will accept.
HLA typing and single antigen bead panels upload as CSV — the generic layout, One Lambda LABScreen or HLA Fusion.
A reciprocal two-way match, a chain of up to fifteen pairs, or a direct comparison of two pairs you name. You set the scope and the thresholds on every search.
Send a swap request from the report. The receiving centre accepts or declines. Only on acceptance are identities revealed and documents shared.
Compatibility is not symmetric. A pairing can be a transplant in one direction and a rejection in the other, because the recipient on one side carries an antibody the recipient on the other side does not. Both directions are computed, and both are reported.
Eplet and CREG analysis is used to rank candidates, never to exclude them. There is no evidence base for eplet-guided paired exchange in any population, and the registry says so rather than implying one.
| Locus | Points per matched allele |
|---|---|
| DRB1 | 15.0 |
| DQB1 | 7.5 |
| A | 4.0 |
| B | 4.0 |
| C | 2.0 |
| DPB1 | 2.0 |
| Threshold | Default | Effect |
|---|---|---|
| Unacceptable | 2,500 MFI | blocks the pairing |
| Positive | 1,500 MFI | reported on the bead |
Registry policy, not a standard — and adjustable per search by the consultant running it.
If both directions work, two pairs simply exchange. When only one direction works, the exchange has to continue — to a third pair, a fourth, until the ring closes back on the first. India has run chains of twelve; this registry searches to fifteen.
Each search reports whether it was exhaustive. When the engine has had to prune, it says so, so that "no chain exists" is never claimed on the strength of a search that stopped early.
A chain report is one document: the cycle drawn, a ledger of every hop, then every hop in full — both directions, with the epitope and CREG analysis. A fifteen-way chain is fifteen pair summaries in one file, and the weakest hop is named on page one.
Blank CSV templates for recipient typing, donor typing and single antigen bead results are on the Downloads screen, each with a worked example row. Two vendor layouts are read as they are exported — One Lambda LABScreen and HLA Fusion — so a plate does not have to be reshaped by hand.
Every recipient and every donor can carry an Ayushman Bharat
Health Account — both the 14-digit ABHA number and the
someone@abdm address — so a pair on this registry is
identifiable in the same terms as the rest of the patient's health
record, and stays identifiable when they move between centres in an
exchange.
To be precise about what this is not: the registry records and validates the identifiers. It does not yet exchange records over the ABDM network — verifying an ABHA against the national registry runs through the patient's own consent flow, which is not something a hospital user may complete on their behalf from an admin screen. That integration is separate work, and we would rather say so than imply it is already done.
Another centre sees the NSID, organ, blood group, readiness and clinical data it needs to judge the exchange — not the patient's name, consultant or hospital. Masking is decided per viewer at the moment of serialisation, and lifts only when a swap request is accepted.
Deciding whether an exchange is viable is the entire purpose of the report, and it cannot be done against hidden values. What is protected is identity; what is shared is immunology.
Passwords are stored with Argon2, traffic is TLS-only, access is role-based, and the audit log carries who looked at what and when — including document downloads.
The 14-digit ABHA number and the someone@abdm address are
captured for recipients and donors alike, validated on the check
digit, and kept optional — see above.
The portal runs in the browser and as an Android, iOS, Windows and macOS application from a single codebase, so a coordinator on a ward sees the same registry as a consultant at a desk.
Pairs, swaps, consultants and coordinators export as CSV, Excel or PDF, filtered as they are on screen. Match and chain reports print as PDF for the file.
MFI is semi-quantitative. Eplet load is not comparable across published thresholds. CREG is reported because a serologist reads it quickly. The documentation states all of it plainly.
Transplant consultants register here. Your centre is enrolled as part of approving you, and your transplant coordinators are added under you once you are in.