Seeking input on services that the OHDSI Study Agent will provide

Hello!

My name is Rich Boyce and I am helping to lead/coordinate the new OHDSI Study Design Assistant project. The project is a part of the OHDSI Generative AI workgroup and has the goal of developing an AI Study Agent to support OHDSI researchers to more rapidly, accurately, and reproducibly determine research feasibility and design research studies using OHDSI tools, including HADES and Atlas/WebAPI.

The Study Agent will be service-architected, providing AI-informed services to other tools used by researchers through standardized API calls. This will enable integration of the Study Agent into a variety of tools used by OHDSI researchers. See here for more information, including on architecture and an initial proof-of-concept.

In this post, I am seeking input on the set of services that we should target for the Study Agent. I have started a list of services that I think will help a researcher go from a study idea to a well-specified research question, and then from a research question to a computable study specification, complete with computable outcome and exposure phenotypes and parameters for executing the study. If this topic is of interest to you, would you please comment, edit, and or make suggestions in reply or post them on the project github as issue tickets?

Below is the first draft of study agent services based on what I am calling “study intent” (a narrative description of the research question) :

NOTE: at no time for any of the services would an LLM see row-level data (this can be accomplished through the careful use of protocols (MCP for tooling, Agent Client Protocol for OHDSI tool ↔ LLM communication) and a security layer).

  • phenotype_recommendations: Suggest relevant phenotypes from the thousands of phenotype definitions available from various credible sources (OHDSI Phenotype library, VA CIPHER, a user’s own Atlas cohort definitions) for the study intent. Write cohort definition artifacts for any phenotype definitions the user accepts as relecant.
  • phenotype_improvements: Review selected phenotypes for improvements against study intent. Of the use accepts, write the new artifacts (JSON cohort definitions or Atlas cohort records)
  • phenotype_characterize: Generate R code that the user will run, or request the user’s permission to run Atlas services, to characterize the population of individuals that match a selected phenotype (i.e., same as a cohort characterization)
  • phenotype_data_quality_review: Check for likely issues and propose mitigation based on information from the Data Quality Dashboard, Achilles Heel data quality checks, and Achilles data source characterizations over the one or more sources that a user intends to use within the study. For issues that the use acknowledges , patch the artifacts (JSON cohort definitions or Atlas cohort records)
  • phenotype_validation_review: Generate Keeper code for the use to run that will enable them to review case samples from the population of patients meeting a selected phenotype definition. The agent will write the code to make the sample such that the user can compare performance characteristics with their sample to known for the phenotype from other sources where it was tested.
  • cohort_definition_build: Write the Capr code for a use to define a phenotype or covariate relevant to the study intent for which a cohort definition has not yet been defined.
  • cohort_definition_lint: Review cohort JSON for general design issues (washout/time-at-risk, inverted windows, empty or conflicting criteria) and for execution efficiency (unnecessary criterion nesting, sub-optimal logical ordering of criteria) and write the proposed patches (new JSON or new cohort definitions in Atlas)
  • concept_set_recommendations:Based on a phenotype or covariate relevant to the study intent for which a cohort definition has not been defined, suggest relevant concept sets from sources available to the user (concept set JSON, Atlas) to use in a new cohort definition. If the user accepts, create the concept set artifacts.
  • propose_concept_set_diff: Review concept set for gaps and inconsistencies given the study intent. If the user accepts, patch the concept set artifacts.
5 Likes

Thank you @rkboyce for leading this!

How about:

  • propose_negative_control_outcomes: Given a target (and optionally a comparator) recommend outcomes that are unlikely to be caused by the target (nor by the comparator)
  • review_negatve_control: Given a target and an outcome, judge whether they are unlikely to be causally related.
  • propose_comparator: Given a target, propose a comparator. This could leverage the OHDSI Comparator Selector tool.
2 Likes

@rkboyce a lot of phenotype_ has already been posted!!

How about:

  • protocol_generator: understand the PICO/TAR and write a templated protocol
  • background_writer: based on PICO/TAR and hypothesis - do (systematic) research and write document justifying study.
  • protocol_critiquer: given a protocol critique it if it has required components and for consistency.
2 Likes
  • phenotype_dataset_profiler: execute phenotype on multiple datasets and write an elevator pitch summary that compares which phenotype definition elements cause the biggest differences in cohort size (think CohortDiagnostics)
  • strategus_*: compose/compare/edit/critique/debug study specification (formulated using Strategus .json)
1 Like

adding to Gowtham - some “phenotype fit” checking if the phenotypes chosen make sense for the protocol. (separate from what I interpreted as the current phenotype recommendations which might have more to do with the specific components and implementation of an already given phenotype definition.)

This agent sounds so cool! For the protocol_generator, it might be beneficial if it could provide rationales for the choices of important components of the protocol. For example, why the specific active comparator is chosen. Besides, I anticipate it allows the revision of the protocol with a simple function and a little bit of hints from users.

Besides, what about a design_diagram function, which generates a figure illustrating the study design?

Thank you @XiaotongLi, @Gowtham_Rao, @schuemie , and @patrick.alba for the suggestions.

We had a productive discussion on the GenAI forum which led to some follow ups I will work on including:

  1. clarifying that the concept is possibly more clearly identified as a study design assistant that helps users leverage OHDSI tools to accomplish rigorous and reproducible OHDSI study designs (characterization, estimation, or prediction).

  2. I will refactor the service suggestions to mention the inputs, outputs, and validation approach.

  3. I will focus the next couple weeks of work on phenotype recommendations for target and outcome cohorts for incidence rate analyses.

    • On this point, can anyone point to interesting prior incidence rate analyses that would be good cases to use as cases for the next iteration of the tool?

Btw: AMIA fall symposium submission deadline is March 10th - any interest among this group on helping put together a submission about this work?

This area is moving fast, see projects that provide MCP with MIMIC and other datasets show some directions this area of development has been headed:

@Vojtech_Huser had the good idea of inviting the M3 folks to our WG. If we want to do that, I could try to reach them. Another approach might be to put together a panel discussion for the fall AMIA symposium or the OHDSI symposium. Thoughts?