2021 Functional Goals #29
Conversation
|
So I think I heard on yesterday's Architecture call that the scope is moving away from drug repurposing and towards target landscaping. @southalln @sstemann @cartmanbeck is that right? Can we flesh out that part of this a bit? |
|
That is correct, and I will let Noel talk more about what that really means, but in my mind, it's simply a broadening of the same question... not only what drugs can treat a disease, but what targets COULD a drug to treat the disease be designed to target? It broadens the scope, but fundamentally is getting at a similar idea. |
|
It's certainly getting at a similar idea / biology / set of queries, but I think we need to be as clear as we can on what the specific goals are - Is target landscaping the goal, or target landscaping + drug repurposing is the goal, or target landscaping is the goal and drug repurposing is a stretch goal, or some other formulation? |
|
@cartmanbeck @cbizon - in the clinical working group we've been thinking in a drug repurposing direction. @qianzhu2018 @karafecho @CaseyTa how do you read the conversation above relative to our work? Do we need to change direction or do the kinds of questions we've been considering fit comfortably within @cartmanbeck's "broadened" question? |
|
Maybe we should be thinking about this in terms of what kind of graph/answer set we need to assemble to allow a user to ask questions about diseases and treatments. That gives us a concrete goal to shoot for and allows NCATS to have some degree of flexibility in exactly what question they ask during a demo. |
|
tagging the committee @NCATSTranslator/architecture-core for follow up |
|
Just for clarity – Target Landscape was introduced at the same time as drug repurposing during the Translator Trajectory presentation<https://drive.google.com/file/d/1gVSsgwho2F2xt7t2w_2r2NEwlUERKUik/view?usp=sharing> (slide 2) which I’ve also included in the PM Repo<https://github.com/NCATSTranslator/TranslatorPM/blob/main/How%20to:%20%20Announcements.md> at the Relay on Monday and Friday. While these two are related, I wouldn’t say we’ve broadened the scope but are just wanting to make sure that both are approaches scoped for the December demo (and product launch).
From: cbizon <[email protected]>
Sent: Wednesday, February 24, 2021 2:33 PM
To: NCATSTranslator/TranslatorArchitecture <[email protected]>
Cc: Stemann, Sarah (NIH/NCATS) [C] <[email protected]>; Mention <[email protected]>
Subject: Re: [NCATSTranslator/TranslatorArchitecture] 2021 Functional Goals (#29)
So I think I heard on yesterday's Architecture call that the scope is moving away from drug repurposing and towards target landscaping. @southalln<https://github.com/southalln> @sstemann<https://github.com/sstemann> @cartmanbeck<https://github.com/cartmanbeck> is that right? Can we flesh out that part of this a bit?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#29 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJEL5IWFX4ST2TNA3X42JMLTAVH6ZANCNFSM4YBLA6ZA>.
|
|
@sstemann : Thanks for the clarification. I do have a question, however. Specifically, I'm wondering how to interpret the third bullet "[redefining disease]". This question has been raised in various discussions, so I want to make sure I understand the intent. Thanks! |
This is something that has been part of the hopes for Translator since its inception, the idea being that we would use data to define diseases not based on similar phenotypes but based on real genetic, pathway, and other mechanistic data. I hope we can get to that point with Translator, but it's a big ask, admittedly. |
|
Indeed! 'Redefining disease' or 'data-driven clinical regrouping' is clearly part of the vision for Translator. It's just that the closed brackets confused me. :-)
|
|
Can we try to draft some actionable requirements to guide our development for Dec? |
|
I would like to raise some issues regarding the notion of "drug repurposing" which we need to consider if we make this a major functionality. Clearly, was diatomsRcool describes is not very realistic (yet): "For example, for drug repurposing, will a use submit the name of a disease as input and expect as output a list of potential repurposed drug treatments?" Drug repurposing starts with formulating a biological repurposing strategy - only then can we formulate a meaningful query. There are different classes of repurposing strategy - some examples below: (2) IDENTIFTCATION OF INTERSECTS IN THE MOLECULAR PATHOGENESIS PATHWAY: "In disease disease X, protein kinase K is over active - and there are so many kinase inhibitors looking for indications - is there one that inhibits K"? This strategy also has been pretty successful, but is more recent. (3) IDENTIFICATION OF OVERLAPPING PATHOPHYSIOLOGY: .... (this is an older strategy...) The point is: the user will first have to come up with the repurposing strategy, and formulate the query. And only then perform the query. The Translator cannot do the former for you |
|
I completely agree with @suihuang-ISB. Drug repurposing queries need to have an underlying rationale that defines how the query should be formulated, as there are multiple perspectives from which to approach "drug repurposing." For example, Sui's first example may benefit from the discussion of "opposite-of" predicates in the BioLink repo: biolink/biolink-model#656. |
|
Great! This is exactly the kind of things we need to articulate in order to formulate actionable software requirements. We can take one of those queries and fully flesh out what it would take to make it happen. Then move to the next. |
|
As a user, I want to query translator for a disease phenotype and get back a list of candidate drug treatments with a side effect that is the opposite of that phenotype. |
|
I'm confused about process here. Typically, a PR discussion is more narrowly about whether to accept or reject the content of the pull request and the discussion thread is buried after a decision is made. The present question is whether we should add this stub document to the arch repository. However this discussion includes a lot of proposals for what could be future PRs that would add very important specificity to the stub document. That discussion is very important, and should be happening somewhere, but probably not in a PR discussion thread? Moreover, I love the idea that we "fully flesh out" the user stories listed here, and that work should probably be assigned to someone, but it's tough to do that in a PR discussion thread and hold anyone accountable. What should the process for all this be? |
|
I think you make a good point @southalln . I think we need to do a bit of work to define processes of the kind you discuss, and bring together some of the streams of requirements. But this PR is probably not a good place for all of that discussion. So if we can refocus on this particular stub, what I think we need is:
|
The purpose here is to create a document that we can use as a way to agree on the scope of work for 2021, and specifically what functionality to we want to be able to demonstrate by the end of the year.
We may use this folder as a place to store evolving use cases as well as we develop them.
At the moment, we are starting with some very high level goals from NCATS, but through discussion on this PR and the call we should get more specific.