CQS work-around to incorporate Multiomics EHR

[GitHubbit]

I am following up on trying to incorporate Multiomics EHR Risk (via BTE/Service Provider) into CQS Path A's workflow

Context: https://ncatstranslator.slack.com/archives/C022EL8D3AB/p1694044336256809

Question: Can the SmartAPI registration for Multiomics EHR be updated to support "lookup" and "fill", and other operations, as required by The Clinical Data Committee's CQS? And can this be broadcast?

BTE response: The existing SmartAPI registration for Multiomics EHR Risk KP API cannot be updated to support "lookup" and "fill" because the underlying API doesn't support those operations (or any form of TRAPI query, for that matter). If you click on the "Source URL" link, that will take you to https://raw.githubusercontent.com/Hadlock-Lab/clinical_risk_kp/master/ehr_risk_kp.yaml (which is the static version of https://github.com/Hadlock-Lab/clinical_risk_kp/blob/master/ehr_risk_kp.yaml). And in that file, servers.url points to https://biothings.ncats.io/multiomics_ehr_risk_kp. That API endpoint is not a TRAPI endpoint.

So how does Multiomics EHR API get called using TRAPI then? BTE serves as a TRAPI wrapper around the Multiomics EHR API, using the SmartAPI annotation to translate the inputs and outputs. Specifically, it is using the x-bte-kgs-operations and x-bte-response-mapping sections of the SmartAPI annotation to consume/output TRAPI. So that means you can send TRAPI queries to and get TRAPI responses from https://bte.transltr.io/v1/smartapi/d86a24f6027ffe778f84ba10a7a1861a/query.

So as I see it, if the workflow runner wants to get Multiomics EHR content, there are a two short-term options that I can see:

Create a special lookup table within your system so that when Multiomics EHR content is wanted, it knows to send that query to https://bte.transltr.io/v1/smartapi/d86a24f6027ffe778f84ba10a7a1861a/query Create another SmartAPI registry entry for "Multiomics EHR Risk KP TRAPI endpoint" and do a full TRAPI annotation (following the annotation pattern for natively TRAPI resources like Aragorn, for example). While this may serve your purpose, this is not a registration that our team would want to create or support, because it would mean that each KP served through BTE would have two entries in the SmartAPI registry, and that runs counter our view of how these various resources should be represented. We of course can discuss longer-term and more permanent solutions, but these are non-trivial and would need to be discussed and prioritized accordingly...

@GitHubbit (Kamileh) @andrewsu @jdr0887 @maximusunc @uhbrar @karafecho @CaseyTa

[karafecho]

Thank you, @Kamileh!

@maximusunc @uhbrar : What do you think about the available options for incorporating Multiomics EHR Risk Provider into the Path A workflow query? I'm thinking that we should (1) refine the existing Path A query for prod deployment in the winter release, relying on cohd and icees-kg as input for the first hop, and, in parallel (2) consider/test options for incorporating Multiomics EHR Risk Provider as input for the first hop in the spring release.

Re (2), one option not mentioned yet is to refactor Multiomics EHR Risk Provider as an Automat KP, but that will require discussion.

I'll add this to the agenda for the next TCDC meeting.

[maximusunc]

I'm not really a fan of either option, and I still see difficulties in being able to query Multiomics directly. The ARAs are the ones that need to be able to query it directly for that first hop, so the lookup table can't really live in the workflow runner. I think either BTE needs to include a way to route queries to specific underlying KPs (maybe as a TRAPI field in the message?) or I do like Kara's idea of just making it an Automat KP. Automat is a TRAPI wrapper just like BTE but it exposes each KP separately and we could then treat it just like we do ICEES-KG now.

@karafecho I think that game plan sounds good.

[CaseyTa]

@GitHubbit Do you know if the qualified predicate used by EHR Risk is unique to EHR Risk? If so, could it work to register a separate "Path A.2" in CQS that is essentially the same as Path A but only has EHR Risk's qualified predicate instead of the correlated_with?

[GitHubbit]

@CaseyTa

• "associated_with_likelihood_of" is unique to EHR KP
• "increased" and "decreased" are the qualifiers, so the full predicate becomes "associated_with_increased_likelihood_of", and "associated_with_decreased_likelihood_of"
• "correlated_with" is not used by EHR KP, but is used by other KPs within Multiomics :)

[karafecho]

@GitHubbit : Do you want to create a new JSON file here: https://github.com/NCATSTranslator/Clinical-Data-Committee-Tracking-Voting/tree/main/GetCreative()_DrugDiscoveryRepurposing_RarePulmonaryDisease/Path_A? That way, we can test Casey's workaround.

@gglusman : Is there a unique predicate (or predicate + qualifiers) that we can leverage to selectively target Multiomics Clinical Trials Provider? For example, biolink:in_clinical_trials_for (assuming this is or will be in the model)?

[GitHubbit]

@karafecho I'll get working on the JSON file. I will coordinate with BTE to see if it checks out. MolePro indirectly sources clinical trials information as well, so I am not sure if they are also using the biolink:in_clinical_trials_for predicate. I will clarify with them and get back to you here.

Edit: I believe there will be a predicate exclusive to Clinical Trials KP, but I cannot guarantee that other KPs won't use it in the future. MolePro uses the "treats" predicate

[karafecho]

Per Evan, Max, and Chris B:

The SRI team is fine with working with the Multiomics EHR Risk Provider team to refactor their KP as an Automat KP.

There is no need to make duplicate infores id's to support both BTE and Automat. Rather, Multiomics EHR Risk Provider would have one primary knowledge source, infores:multiomics-ehr-risk-kp, but with two aggregator knowledge sources, one being BTE and the other being Automat. The CQS would then include an allowlist parameter for Path A that would point to infores:automat-multiomics-ehr-risk-kp.