LLM agent for clinical trials

[DiTo97]

would love to set up a conversational agent able to carry out analytics on clinical trials data (e.g., ODM). The clinical trials might be hypothetical, meaning they have not been carried out yet and only the study definition and protocol is provided. In that case, the study should be linked to one or more FHIR servers, from which real-world data (RWD) relevant to the study should be fetched and extracted.

is the library mature enough for such a use case? I was thinking if converting the RWD to SQL might help extract data for clinical trials, but not being familiar with the library, I am not too sure if that's even feasible in the current state.

[dogversioning]

So we're not quite at that point, mostly on the live FHIR querying side of things.

What could be done today:

• The ETL pipeline could extract, up front, the resources from a FHIR server that we currently support (which is a subset, but contains enough to cover the majority of clinical study use cases) as a one time operation or a scheduled job, into a data warehouse.
• You could attempt to point your LLM agent at this data set for extracting data from these tables.
  • This might be easier using a cumulus library study to flatten tables, but note that due to our funding source we're heavily leveraging the FHIR US Core profile, so if that's not desirable and your LLM agent can't handle unnesting complex tables, some work might be needed to create the base tables for your queries.

Part of our philosophy is to try and get as much data out via the ETL and worry about defining study cohorts after the fact, so that we don't have to constantly go back to the FHIR servers, and have more control over what kind of requests are being made of them. But if you get a large set of data out via ETL, then you should be able to iterate on hypothetical clinical trials.

Our ML/LLM infrastructure at the moment is more aimed at feature detection in flight during extraction, so we don't have an API/tuning prompts for this kind of interaction yet, though it is something that we've talked about in the future - no timeline on this yet.

If you try something like this, I'm sure we'd be very interested in hearing how it goes/if you run into roadblocks.

[DiTo97]

Thanks for the detailed response, @dogversioning.

have a couple of questions about our use case, and would be happy to chat if you deem that faster.

The ETL pipeline could extract, up front, the resources from a FHIR server that we currently support (which is a subset, but contains enough to cover the majority of clinical study use cases) as a one time operation or a scheduled job, into a data warehouse.

• is there a list of the resources you currently support? which data warehousing platforms are supported?

This might be easier using a cumulus library study to flatten tables, but note that due to our funding source we're heavily leveraging the FHIR US Core profile, so if that's not desirable and your LLM agent can't handle unnesting complex tables, some work might be needed to create the base tables for your queries.

• what cumulus library would you suggest?
• I am not too familiar with the ecosystem, so I am not aware of the depth of nesting you have;
• rationale is that LLMs should be better at writing SQL code to extract data from, then doing so from tree-like structures;
• how different would the result be doing so rather than injecting FHIR queries in ODM documents, with a smart-on-FHIR client? what would be the advantages and disadvantages of using one approach rather than the other?

Part of our philosophy is to try and get as much data out via the ETL and worry about defining study cohorts after the fact, so that we don't have to constantly go back to the FHIR servers, and have more control over what kind of requests are being made of them. But if you get a large set of data out via ETL, then you should be able to iterate on hypothetical clinical trials.

• that is pretty much in line with our goals in case we are working with hypotheticals and not with grounded clinical trials!

[dogversioning]

* is there a list of the resources you currently support? which data warehousing platforms are supported?

There certainly should be! We'll add that to our docs. In the interim, this issue containing Epic permissions to request lists all the resources we're supporting.

We're currently setup to run in AWS and manage queries in Athena, and we're using DuckDB locally for testing; it could be used for real use cases depending on the data size. Azure is in our roadmap but it's not scheduled currently; that's probably at least a year out.
Anything that is Presto/Trino-ish :should: work, but may come with some hiccups.

* what cumulus library would you suggest?

In our project nomenclature, Cumulus Library is the framework we developed to create SQL queries against the data store. The docsite gets into the nitty gritty, but it basically provides a runner framework for executing queries against a datastore

* I am not too familiar with the ecosystem, so I am not aware of the depth of nesting you have;
* rationale is that LLMs should be better at writing SQL code to extract data from, then doing so from tree-like structures;

Our first pass transformation takes the root elements of a given resource and treats those as columns, and if there's more underneath, it creates array/row objects that may take some unnesting. For example, on the Condition resource, the recordedDate field would be a date column, whereas the category column would contain an array of structs, and the coding struct itself would contain an array of structs. Extensions can allow a lot of this nested struct/array behavior - it might be a prompt engineering exercise to get this data out successfully.

Our second pass transformation, in the Cumulus Library mentioned above, does produce flat tables - but they are currently all based on the US Core v4 profile, and you have to be a bit careful about using DISTINCT statements on things like ID fields to accomodate all these arrays we're unnesting. If that's ok, that would give you flat tables that would play nicer with typical agent use cases.

* how different would the result be doing so rather than injecting FHIR queries in ODM documents, with a smart-on-FHIR client? what would be the advantages and disadvantages of using one approach rather than the other?

I think this is a question of choosing the problem you want to solve.

Cumulus tries to create data warehouses for analyst users who may not know/care about FHIR. It does this by doing a lot of heavy churning up front, specifically leveraging the bulk FHIR protocol, and it produces outputs designed for ingestion by specific cloud tooling. Once you've got it set up you should have a repeatable process for users, and it's easy to share study definitions with other institutions running the framework, but there is an upfront engineering cost to pay to get to this point.

Running FHIR queries against documents is less perscriptive. If you've got FHIR tooling in place, or a path from an LLM agent to a FHIR query, you should be able to run against different vintages of FHIR data from different sources. But it will be a bit more ad hoc, harder to share, and require smaller/more frequent trips to the source (or creating a shadowing server to mirror your production infrastructure). My intuition, I think similar to yours, is that this will be a little harder to get an LLM agent to run queries against.

[DiTo97]

There certainly should be! We'll add that to our docs. In the interim, #5 containing Epic permissions to request lists all the resources we're supporting.

thanks for the list. will make sure it is comprehensive enough, but it seems like it at first glance!

We're currently setup to run in AWS and manage queries in Athena, and we're using DuckDB locally for testing; it could be used for real use cases depending on the data size. Azure is in our roadmap but it's not scheduled currently; that's probably at least a year out.
Anything that is Presto/Trino-ish :should: work, but may come with some hiccups.

the whole project has been designed for GCP, but having that single AWS dependency might be manageable.

Our first pass transformation takes the root elements of a given resource and treats those as columns, and if there's more underneath, it creates array/row objects that may take some unnesting. For example, on the Condition resource, the recordedDate field would be a date column, whereas the category column would contain an array of structs, and the coding struct itself would contain an array of structs. Extensions can allow a lot of this nested struct/array behavior - it might be a prompt engineering exercise to get this data out successfully.

Our second pass transformation, in the Cumulus Library mentioned above, does produce flat tables - but they are currently all based on the US Core v4 profile, and you have to be a bit careful about using DISTINCT statements on things like ID fields to accomodate all these arrays we're unnesting. If that's ok, that would give you flat tables that would play nicer with typical agent use cases.

now it is all much clearer! US core v4 is built on top of FHIR R4, isn't it? so I think it could be okay. regarding the danger of using DISTINCT statements on such fields, do you have any example or use case in mind where that might be needed? I agree that a flattened representation would make the overall pipeline much easier to handle in later stages.

after reading the docsite, I would say the whole process is quite straightforward. what worries me the most is the study definition config required to trigger the cumulus library pipeline, as I see more than one manual steps depicted in the docs, while all that should happen automatically in the best case scenario, study definition config included. as for the SQL querying, I see that you put a lot of effort in the helper class which streamlines and facilitates access to the flat tables. how much easier would you think that would be using the helper class instead of relying on standard SQL querying? The helper class might seem the most logical choice, but considering it's the LLM agent job to generate the querying code at runtime, I am wondering if there are enough examples in the docsite to make a model command the helper library with ease and accuracy most times.

in general, the ideal use case would be for a clinician to upload a clinical study definition (possibly with data) in the ODM format, as well as a PDF document depicting the accompanying study protocol. clinicians should have the possibility to add a bunch of FHIR servers to fetch or enrich the available data from with the necessary authorization. after some local pre-processing takes place on the ODM and the PDF files, the ETL pipeline fetching data from each FHIR server into a more compact representation should trigger.

Running FHIR queries against documents is less perscriptive. If you've got FHIR tooling in place, or a path from an LLM agent to a FHIR query, you should be able to run against different vintages of FHIR data from different sources. But it will be a bit more ad hoc, harder to share, and require smaller/more frequent trips to the source (or creating a shadowing server to mirror your production infrastructure). My intuition, I think similar to yours, is that this will be a little harder to get an LLM agent to run queries against.

yeah, I fully agree that the ETL option could make it easier for the downstream LLM agent to operate.

[mikix]

Embarrassed that we didn't have an obvious list of supported resources, I made one.

[dogversioning]

now it is all much clearer! US core v4 is built on top of FHIR R4, isn't it? so I think it could be okay.

Yep, that's correct.

regarding the danger of using DISTINCT statements on such fields, do you have any example or use case in mind where that might be needed? I agree that a flattened representation would make the overall pipeline much easier to handle in later stages.

Going back to that example above of Condition.category, if there were two coding systems in that field, we create two corresponding rows in that table for the same resource ID- basically, we're trying to limit the need for an analyst to do cross-joins where possible. So we're assuming that a user will be using one coding system for search, or providing a list to walk down, or otherwise doing some kind of filtering operation - or, if they are just trying to get a count of all conditions occuring after a certain date, they should make sure that the condition.id field is part of a distinct clause. This kind of coding/codeableconcept behavior is pretty common across the resource tables.

after reading the docsite, I would say the whole process is quite straightforward. what worries me the most is the study definition config required to trigger the cumulus library pipeline, as I see more than one manual steps depicted in the docs, while all that should happen automatically in the best case scenario, study definition config included. as for the SQL querying, I see that you put a lot of effort in the helper class which streamlines and facilitates access to the flat tables. how much easier would you think that would be using the helper class instead of relying on standard SQL querying? The helper class might seem the most logical choice, but considering it's the LLM agent job to generate the querying code at runtime, I am wondering if there are enough examples in the docsite to make a model command the helper library with ease and accuracy most times.

My intuition is that the helper class for an LLM agent is probably a non-starter today - we'd need a lot more very low level documentation for that to be accurate. Prompt tuning with the table schemas and some guidance about linking the resources together might be easier to MVP, though I suspect this is going to be the trickiest part to wrangle.

You might? be able to build up a corpus with that MVP for a few dozen cases, and then that might get you to something that could more easily integrate with something like our helper class - but I think that's also a question of 'is this for exploration or for productizing'.

[DiTo97]

thanks again for the availability, @dogversioning, much appreciated!

My intuition is that the helper class for an LLM agent is probably a non-starter today - we'd need a lot more very low level documentation for that to be accurate. Prompt tuning with the table schemas and some guidance about linking the resources together might be easier to MVP, though I suspect this is going to be the trickiest part to wrangle.

that's what I felt myself, unless a small code generation LLM is trained via reinforcement learning in self-play using the helper library with the little amount of documentation and examples that are currently provided; prompt tuning might be it!

You might? be able to build up a corpus with that MVP for a few dozen cases, and then that might get you to something that could more easily integrate with something like our helper class - but I think that's also a question of 'is this for exploration or for productizing'.

everything that we have been discussing is oriented towards early exploration, so the more approaches the merrier.

I will add two more questions:

• how difficult would you deem creating the study config to be, assuming that should be done automatically by some model?
• is there any reason why the Questionnaire resource is outside the pool of supported resources or by chance?

In general, I see two major benefits for us with cumulus:

• untying a specific ODM clinical trial from its FHIR sources, avoiding repetition, by creating a common intermediate layer
• applying anonymization techniques to whole bulks of FHIR servers, instead of repeating that operation for each study

what is still not clear to me is if there is a preferred approach to reflecting changes to the FHIR server in its export

[mikix]

Is there any reason why the Questionnaire resource is outside the pool of supported resources or by chance?

Mostly we haven't gotten to it. We are most interested in resources in US Core v4, and I don't think Questionnaire is (though looks like it's in v6).

So without a US Core profile and without needing Questionnaire ourselves, we just haven't prioritized it.

What is still not clear to me is if there is a preferred approach to reflecting changes to the FHIR server in its export

Sorry, I'm not 100% sure I understand - can you expand on this?

[DiTo97]

thanks, makes total sense!

The question was what happens when (after some time) the FHIR server's data changes. is there a way to keep the bulk export aligned with the server data or would that be just a matter of re-exporting the server data all over again (anonymization included)?

[mikix]

Ah gotcha.

Exporting changes
If you are using a server that supports meta.lastUpdated and the _since bulk export parameter, then you can use that to export just the data that changed since you last did an export. (if you are using cumulus-etl's builtin exporter, you can pass --since to grab new data)

If your server doesn't support that (like Epic still does not), hopefully it at least implements _typeFilter, so you can craft some date queries yourself and grab newly created resources. That's a bit more manual work (most resources have a date= filter, but not all). And that won't grab resources which have had corrections/updates. Only new resources. But... the server doesn't support meta.lastUpdated, so 🤷 I dunno what else to do (except a full fresh export).

Handing that to Cumulus
As far as Cumulus ETL is concerned, you can mostly just throw data at it and it will be fine.

• Rows with never-before-seen id values will be inserted, like you expect.
• But rows with existing id values (and a newer meta.lastUpdated field) will be overwritten with the new data. (If your server doesn't have lastUpdated, then you are advised to ETL in the same order you exported resources, to avoid overwriting new data with old, since we can't safeguard that for you.)
• Anonymization is kept the same between runs because we store the randomization "salt" value in the codebook.json file in the PHI/build dir (the 3rd positional argument to the ETL).