Calculate cPRA of recipient

[kubantjan]

• Estimate the value of cPRA for recipient from the donors in the current matching
• Get the list of donor_ids the recipient can receive the transplant from

Prepare endpoint that receives id of a recipient and returns these two values

[kubantjan]

Q: What is a calculated panel reactive antibody or cPRA? A: After your antibodies are measured, your health care provider can use them to calculate your PRA. The cPRA estimates the percentage of donors with whom a particular recipient would be incompatible. In other words, it would give you an idea of the percentage of offered kidneys your body would likely reject at the time of transplantation. The cPRA is used in the allocation of kidney and pancreas transplants. Patients with high cPRA levels get priority for transplantation because it is harder to find compatible donor organs in those situations. The good news is that most patients awaiting kidney transplantation have low levels of anti-HLA antibodies, but it is estimated that 9,000 patients on the waitlist have cPRA > 95%.

[discovermow]

Hello, @kubantjan :)

I wanted to ask whether this function should be written in some specific file/place. Also I'd like to ensure that I understand the metric correctly: if cRPA is a percentage of donors with whom a particular recipient would be incompatible, then it might be calculated as number of incompatible donors/number of all donors.

Thank you.

[kubantjan]

1) Cpra definition is correct.

2) put it where you will feel it fits best. I think maybe adding another endopit to patient could be good

[discovermow]

Hello, @kubantjan,

i suppose it will be logical to add parameters cRPA and possible_donors_ids for Recipient (not Patient, because we won't calculate cRPA score for a Donor) and a function that calculates cRPA somewhere near the place, where a matching is calculated (if I understand it correctly, we would like to find a cRPA for some specific, already found matching and Recipient). Just wanted to ask, if it seems OK from your point of view.

[kubantjan]

The exact location is open, but this is not related to matching but more to recipients properties, so i would put it somewhere there. (and I am sorry for delayed reply)

[kubantjan]

Q: what will be cPRA used for?

it is for the doctors as extra info about the patient, it is not used anywhere in the code. Similarily list of potential donors.

that is why in this issue one should create an endpoint that receives patient id and outputs the info.

[discovermow]

Thank you for the explanation. If I understand it correctly, only a function that calculates cRPA is needed and I shouldn't think about other situations and use cases?

Also I wanted to ask if _related_donors_dbids is the list of all possible donors for a specific recipient.

Thank you.

[kubantjan]

Thank you for the explanation. If I understand it correctly, only a function that calculates cRPA is needed and I shouldn't think about other situations and use cases?

a function AND an endpoint.

Also I wanted to ask if _related_donors_dbids is the list of all possible donors for a specific recipient.

no, _related_donors_db_ids are donors that are the original donors of the recipient that for some reason are not able to give the kidney to the patient. We are asking for potential donors, those have to be calculated. (this is computed as part of the process of finding matchings, so you can reuse logic from there)

[discovermow]

Thank you for the explanation. If I understand it correctly, only a function that calculates cRPA is needed and I shouldn't think about other situations and use cases?

a function AND an endpoint.

by "endpoint" you mean that the API for patient should be updated?

Also I wanted to ask if _related_donors_dbids is the list of all possible donors for a specific recipient.

no, _related_donors_db_ids are donors that are the original donors of the recipient that for some reason are not able to give the kidney to the patient. We are asking for potential donors, those have to be calculated. (this is computed as part of the process of finding matchings, so you can reuse logic from there)

ok, so the potential donors should be calculated, but what about the list of all possible donors? Should it be calculated as well or is it given by default? (for example like _alldonors in TxmEvent class)

Thank you.

[kubantjan]

by endpoint i mean creating a new endpoit that will receive a patient ID and return the info.

for each recipient possible donors are different and have to be calculated.

[discovermow]

by endpoint i mean creating a new endpoit that will receive a patient ID and return the info.

could you please provide me with an example? I'm a bit confused, because the term "endpoint" is broad and can have many meanings. In other words, I'm not familiar with it in terms od programming and it sounds pretty similar to a function.

[kubantjan]

https://rapidapi.com/blog/api-glossary/endpoint/

example of an endpoint is implemented here: https://github.com/mild-blue/txmatching/blob/master/txmatching/web/api/configuration_api.py#L31-L46

[kubantjan]

@rimmakam so in the end I will ask someone new to take over, so do not work on this anymore.

@abragtim please have a look and ask if something would not be clear.

[abragtim]

@kubantjan , I have a question to the statistic part of this issue.

There is a chance, that we will calculate cPRA in Txm Event without sufficient amount of donors. For example, if Txm Event has 2 donors, recipient have cPRA = 0% or 50% or 100%. There isn't enough sampling for cPRA statistics.

It can be partly solved by small condition at the end of the calculation. We can check if cPRA before last iteration is lower than ε (cPRA(n-1)iteration - cPRA(n)iteration < ε ). There is a big chance, that after n iterations cPRA tends to its true value.

I propose to return the message "Not enough data to calculate cPRA" in case of small sampling. Does it make sense or it isn't necessary for this issue?

[kubantjan]

For the moment I would sent it even for few patients, the user has to realize that cpra has sometimes limited value