Missing lookup keys for SLCO1B1 alone in drug recommendations

[davidyuyuan]

A call to the CPIC database https://api.cpicpgx.org/v1/rpc/recommendation_lookup?diplotypelookup={%22SLCO1B1%22:%20{%2237%22:%201,%20%2215%22:%201}}&order=drugname does not return recommendations for Rosuvastatin.

I saw the statement “Prescribe desired starting dose and adjust doses of rosuvastatin based on disease-specific and population-specific guidelines. Prescriber should be aware of possible increased risk for myopathy especially for doses >20 mg” three times all realted to the SLCO1B1 decreased function alone or with ABCG2 normal function or decreased function in https://files.cpicpgx.org/data/guideline/publication/statins/2022/publication.pdf. Also, The diplotype *15/*37 in the REST call is defined as SLCO1B1 Decreased Function in the spreadsheet of SLCO1B1_Diplotype_Phenotype_Table.

cpic_db=# select * from recommendation_view where drugname='rosuvastatin'; returns 27 rows with lookup keys all combined with ABCG2 for example {"ABCG2": "Poor Function", "SLCO1B1": "Decreased Function"}. This explains why a recommendation for the drug rosuvastatin was not returned for SLCO1B1 alone.

This is related to the sertraline issue that we are discussing in #48. However, the table 2 in the guidelines listed the recommendation for SLCO1B1 decreased function alone in this case. It's combined with ABCG2 in table 5.

Can you please take a look to see if additional lookup keys for SLCO1B1 alone can be defined?

[whaleyr]

For the statin guideline: each drug uses its own set of genes to make recommendation matches. Like you saw, rosuvastatin uses ABCG2 and SLCO1B1. You can see this by issuing the following query:

cpic=# select distinct jsonb_object_keys(lookupkey) as required_genes
from recommendation_view
where drugname='rosuvastatin';
 required_genes 
----------------
 ABCG2
 SLCO1B1
(2 rows)

In fact, I would recommend you do this check for each drug you're trying to match recommendations for. That way you know which genes to include in the lookupkey comparison.

Since it seems like you're trying to build a product off of this data I would highly highly recommend that you stop using recommendation_lookup and instead do the diplotype to phenotype translation in your own code. The code for recommendation_lookup is not robust enough for production (as I mentioned in #48). In your application logic you should do one step to translate your diplotype values to phenotypes (via the diplotypes view), then combine those phenotypes into query parameters you can query against recommendation_view. Part of that application logic should also handle filling in "No Result" values for genes that are necessary for two-gene recommendation lookups.

We're not going to create rows for SLCO1B1 alone because 1) we can handle that situation at the application layer and 2) that would entail a system-wide rewrite for how we handle recommendation data.

That being said, if you're going to query recommendation_view directly you don't need to specify an ABCG2 phenotype. You can do a submatch for the lookup key like so:

cpic=# select lookupkey, drugrecommendation from recommendation_view
where drugname='rosuvastatin' and lookupkey @> '{"SLCO1B1": "Decreased Function"}';
                            lookupkey                             |                                                                                                                                                      drugrecommendation                                                                                                                                                      
------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 {"ABCG2": "Poor Function", "SLCO1B1": "Decreased Function"}      | Prescribe ≤10mg as a starting dose and adjust doses of rosuvastatin based on disease-specific and specific population guidelines. If dose >10mg needed for desired efficacy, consider an alternative statin or combination therapy (i.e., rosuvastatin plus non-statin guideline directed medical therapy) (PMID: 30423391).
 {"ABCG2": "Decreased Function", "SLCO1B1": "Decreased Function"} | Prescribe desired starting dose and adjust doses of rosuvastatin based on disease-specific and specific population guidelines. Prescriber should be aware of possible increased risk for myopathy especially for doses >20mg.
 {"ABCG2": "Normal Function", "SLCO1B1": "Decreased Function"}    | Prescribe desired starting dose and adjust doses of rosuvastatin based on disease-specific and specific population guidelines. Prescriber should be aware of possible increased risk for myopathy especially for doses >20mg.
 {"ABCG2": "No Result", "SLCO1B1": "Decreased Function"}          | Based on SLCO1B1 status, prescribe desired starting dose and adjust doses of rosuvastatin based on disease-specific and specific population guidelines. Prescriber should be aware of possible increased risk for myopathy especially for doses >20mg. ABCG2 genotype result is not available.
(4 rows)

You will get back 4 rows for the 4 different possible values of ABCG2. The Table 2 text you point out is in three of the rows for Decreased, Normal, and No Result but if you know ABCG2 is Poor Function then the recommendation is different. This is why it's of utmost importance that you explicitly specify whether you have an ABCG2 value or not because it matters. The database is not an exact replica of the publication, we do not separate tables 2 and 5 (or 3 or 4 for that matter).

Now, that being said, the database is out in the open. If you want to fork it and modify values or data structures to suit your own preferences I can't stop you. Also, if you want to query things differently you're welcome to do that too. However, this is the way that we've found works for our use case and we think it's the most transparent about what the data represents.

If you want to see an example of us handling single gene lookup for double gene guidelines on the application layer, go check out our GSI at ClinPGx. There you can enter just he SLCO1B1 diplotype and we return the correct recommendation to you. Technically, that's using a different DB but the algorithm and data structures are basically the same.

[davidyuyuan]

Thank you for explaining the design behind the schema and data structure. Yes, I am trying to build a product off of this data. I will follow your advices stop making RPC calls to the function of recommendation_lookup.

Do I understand correctly that the lookupkeys for a given drug always have the following properties?

1. They have a fixed length.
2. They are always defined as the longest composite lookupkey for required and optional genes, for example {"gene_a": "No Result", "gene_b": "No Result", ... "gene_z": "Decreased Function"} if there are 26 genes.
3. The value "No Result" is reserved for the recommendations requiring fewer gene phenotypes in the lookup.

If yes, I think that I can replace the call to the function recommendation_lookup with 3 REST calls to recommendation_view and diplotypes. Please let me know if the assumption above is correct.

[whaleyr]

1. I'm not quite sure what you mean by "fixed length". The lookupkey values in the recommendation table, for a given drug, will always have the same number of keys (gene symbols) in it. But that doesn't really matter, the way you query stays the same whether its fixed or not.
2. We make distinction between "required" and "optional" genes. If a gene is used for lookup it's in the key.
3. The value of "No Result" is specified when the recommendation applies when that gene has no result

The easiest way to think of it is: you need to cobble together a "query" lookupkey that has all the phenotypes for all the genes you want to query (whether you have a value or not) and then do a "contains" JSON predicate which will match to all possible recommendations that match those given phenotypes.

For example:

select lookupkey, drugname, population, drugrecommendation from recommendation_view
where lookupkey <@ '{"ABCG2": "No Result", "SLCO1B1": "Decreased Function", "CYP2D6": "1.0", "CYP2C19": "Poor Metabolizer"}'
order by drugname, lookupkey;

That query lookupkey has 4 gene phenotypes specified including one gene that we don't have a value for (which is why it's "No Result"). There is no recommendation that uses all 4 of those genes. But the <@ predicate just says any subset will match. Therefore you will get back all recommendations that match any part of that. This ends up being 37 recommendations for a bunch of different drugs (including rosuvastatin).

[davidyuyuan]

Thanks for confirming the so-called "fixed length" (aka the same number of keys/genes for a given drug). I agree that it doesn't really matter when a query is built with <@ or cd. My previous implementation was improved following your advices here.

You current schema and data structure work with my implementation. Please close this issue. Thank you for your help.