CQS work-around to incorporate Multiomics EHR

[GitHubbit]

Following-up: https://ncatstranslator.slack.com/archives/C022EL8D3AB/p1694044336256809

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?

@andrewsu @maximusunc @jdr0887

[andrewsu]

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...