-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Indications' appearing as adverse drug reactions in AEOLUS data #6
Comments
Hi @mbrush For fun, here are all the indications for imatinib (From the latest quarterly file 2016q4): I'll look into this. Is the plan still to ingest the data into your Scigraph instance through mygene? Or through dipper? Which would be easier? Additionally, there are still "indications" in the results that are neither adverse drug reactions nor original indications... Things like: |
Ok, I think I figured out how to extract this from aeolus. For my future self's reference: SQL query to extract indications (and count) for imatinib SELECT indi_pt, count(indi_pt) FROM aeolus.standard_case_indication
LEFT JOIN aeolus.standard_drug_outcome_drilldown ON aeolus.standard_drug_outcome_drilldown.primaryid=aeolus.standard_case_indication.primaryid
LEFT JOIN aeolus.concept ON aeolus.standard_drug_outcome_drilldown.drug_concept_id=aeolus.concept.concept_id
WHERE drug_concept_id = 1304107
group by indi_pt; You get 549 unique indications (as opposed to the 5213 outcomes). Here are the top 100, along with the count: |
Perhaps you are getting all symptoms/indications for which these patients were treated, not just indications specific for imatinib? It looks like all of the items on your list of "indications" above are appearing as 'outcomes' in the mydrug AEOLUS data as well (at least based on my spot checking several of them). So clearly the list above is conflating things besides imatinib's primary indications - either other indications found in imatiinib-treated patients, and/or ADRs/side effects they experienced following treatment. So, at this point, do you think we should make a ticket in the AEOLUS repo to ask if they have any thoughts on this issue? Or do you want to continue to play with the data to see if you can find a solution? At the end of the day, we just need to be sure that the 'outcomes' returned by the API for a drug like imatinib holds only true ADRs/side effects of the drug, and not things like primary indications for imatinib, or other/unrelated symptoms of patients who were given imatinib. Alternatively, we could return indications as well if these can be determined from the AEOLUS data, but they need to be annotated as such in the mydrug data (as is done for the mydrug SIDER data - which includes both but indicates which are 'indications' and which are 'side effects'). |
Yes, I'll make a ticket |
Hi Greg. Was the advice the AEOLUS folks provided w.r.t. how to filter indications from the outcomes results helpful? Are there other barriers to updating the mydrug data to filter out some/all of the indications? |
Hey @mbrush. What do you suggest as the best format for the data. For reference, an example of the current is below. {
"_id": "KTUFNOKKBVMGRW-UHFFFAOYSA-N",
"aeolus": {
"pt": "IMATINIB",
"inchikey": "KTUFNOKKBVMGRW-UHFFFAOYSA-N",
"outcomes": [
{
"case_count": 7315,
"id": "35809059",
"ror_95_ci": [ 14.59499, 15.318320000000002 ],
"ror": 14.952279999999998,
"name": "Death",
"code": "10011906",
"prr": 13.74818,
"vocab": "MedDRA",
"prr_95_ci": [ 13.447189999999999, 14.05591 ]
},
...
],
"drug_vocab": "RxNorm",
"unii": "BKJ8M8G5HI",
"drug_name": "imatinib",
"no_of_outcomes": 5213,
"drug_id": "1304107",
"drug_code": "282388",
"rxcui": "282388"
} The indications I get (for Imatinib, for example) look like this: {'indication_concept_code': '10009013',
'indication_concept_id': '35104378',
'indication_count': 4426,
'indication_name': 'Chronic myeloid leukaemia',
'indication_vocabulary': 'MedDRA'} Potential issues come in when have things like this: {
"case_count": 3436,
"id": "36718555",
"ror_95_ci": [ 1.9292599999999998, 2.06419 ],
"ror": 1.9955900000000002,
"name": "Insomnia",
"code": "10022437",
"prr": 1.98669,
"vocab": "MedDRA",
"prr_95_ci": [ 1.92124, 2.05437 ]
} An indication: {'indication_concept_code': '10022437',
'indication_concept_id': '36718555',
'indication_count': 54,
'indication_name': 'Insomnia',
'indication_vocabulary': 'MedDRA'}, Should Insomnia not be marked as an outcome because its also an indication? Also, looking at comparing the counts between indications and outcomes: I'm thinking a given drug's doc should just have all outcomes and all indications as separate fields and the user of the data is responsible for reconciling them. |
Hi @stuppie. I think for Biothings your suggestion is best:
As for why the AEOLUS data is this way - would you way that it is because 'outcomes' are considered more broadly than just adverse events/reactions, to include any symptoms experienced by the patient after treatment? So in cases when the indication that the drug was given for did not resolve, then this indication is reported as an outcome as well. This isn't entirely consistent with the language used in the AEOLUS paper - which describes this as an 'adverse event' dataset - but it's the only explanation I can think of for why the data is this way. Unless you have other ideas here? That said, when we pull this data into Monarch, we will want to use it as a source of true 'adverse event' data. So we would likely process the data to remove indications from the list of outcomes for each drug, so we can treat these as true adverse events in our data set. A complication here is that, based on my understanding of how ror and prr are calculated, these scores may be different if we remove the indications. So re-calculating these may be part of our transformation to generate a derived Monarch data set. A final thought on how you bring in the data: would it be in scope for BioThings to add a flag to outcomes that are also indications to indicate this fact for consumers of the data? e.g. an 'is_indicator' boolean attribute? Thinking this might help consumers with any confusion, and to more easily process the data to remove indications from outcomes if they so desire? Just a thought. |
I do not know. I don't see anything about it in the paper. Maybe this is a good question to ask @ntatonetti Also, I didn't know this before, by the Tatonetti lab has an API serving this data: |
so just perusing this ticket, may not have grokked it all Eg there are actually multiple relations here |
Good point @mellybelly - this data set would have much more predictive and analytical value if it we could stratify drug-outcome associations according to the indication for which the drug was initially given. We would be able to answer questions like "how often is a particular adverse event observed for drug X when given for indication Y, vs indication Z"? I'd guess it would be possible to generate this more nuanced dataset, given the granularity at which the FAERS data was collected (at a per patient level). But this kind of wrangling and analysis could be a fair bit of work, and may be something that Nick's team who generated the AEOLUS data set originally would be best suited to perform. My take is that in the short term, it should be straightforward to at least do as @stuppes proposes and (Disclaimer that I haven’t yet explored the Tatonetti lab APIs - so not sure if it would make any of these tasks easier.) |
I've added the indications to mydrug as separate fields, it will be live in a few days.
Yes, this is doable to query. I don't think we'd want to report all of this through mydrug, mostly because of the "all by all"-ness/large number of possible combinations. Here are the top ten most common drug <-> indication <-> AE relations: And for imatinib specifically: And the query, for my future self To extract actual value out of these, it would probably be necessary to do some indication and outcome ontology normalization/mapping to higher-level terms (What is the proper term for this? For example, treating "Cerebrovascular accident" and "Cerebrovascular accident due to right carotid artery occlusion" the same), and then recalculate the summary statistics. |
"following a meta-analysis published in the New England Journal of Medicine in 2007 that linked the drug's use to an increased risk of heart attack,[1] sales plummeted to just $9.5-million in 2012" |
Thanks for the update @stuppes, and getting the indications into mydrug (is it called mychem now?). And for the nice analysis of how we might proceed with the more complex drug <-> indication in which <-> AE associations. Another thing to consider if we want to make this a true drug-adverse event resource, besides removing primary indications, is to consider how to handle outcomes we suspect to be complications / symptoms caused by the primary disease rather than the drug. e.g. 'Death' is likely caused by CML in your examples above, not imatinib. Anyway, I am happy with the dataset with added indications for now, and holding off on the more nuanced dataset unless you are keen to tackle it. Sound good? If any use cases or demonstrators require this additional detail we can pick up the thread here. |
Wanted to follow up with a question we discussed offline about AEOLUS data, which describe adverse drug reactions (ADRs), using meddra terms to codify the adverse outcomes. Specifically, I noted the inclusion of 'outcomes' in the mydrug AEOLUS data that seem to be primary indications for a drug (i.e. what it is used to treat), rather than adverse drug reactions.
For example, the mydrug results for imatinib, which is used to treat various leukemias, and outcomes include things like "Leukaemia", "Chronic lymphocytic leukaemia", "Acute leukaemia".
In your parsing of AEOLUS data, was there any metadata that would tell you what medrra terms represent indications for a particular drug so these could be filtered from the results, or at least tagged as being indications rather than adverse reactions to the drug? This would be a significant improvement to the dataset you generate.
The text was updated successfully, but these errors were encountered: