Tech

Clinicaltrials.gov is one of the most valuable datasets in life sciences, containing hundreds of thousands of clinical trials spanning decades of research. When structured, this trial data can support everything from competitive intelligence and regulatory strategy to study feasibility and clinical trial design, serving as a foundational pillar for any modern life sciences data platform.

Despite its value, the dataset is notoriously messy and difficult to use. Each study is manually entered into free-text fields with no enforced structure, formatting standards, or standardized terminology. Even the simplest details vary widely. For example, as of this writing, there are 116 different variations of how “Type 2 Diabetes” appears in the database. This lack of standardization makes large-scale analysis slow, error-prone, and often impossible without significant preprocessing.

At Formation Bio, we set out to make this data usable. We built a system to ingest every trial on 

 and translate its unstructured text into a standardized, machine-usable format. The result is a dataset with over 6.5 million structured “study components”, which refer to any data element within the structure of a study – including endpoints, eligibility criteria, arms, doses, conditions, and more. Each component is normalized and labeled consistently, forming the foundation for the more complex systems that we build on top of this data. Let’s dive into how we did it.

With millions of data points spread across unstructured text, our first challenge was deciding how a “structured” clinical trial should look. We needed a framework that could be applied consistently across studies regardless of therapeutic area, writing style, or complexity.

We began by manually reviewing dozens of study designs across a range of clinical domains, trying to understand what they all had in common. Across these studies, we examined condition treated, study endpoints, inclusion/exclusion criteria, and arms/dosage data, among all the other critical elements in a clinical trial.

With guidance from our Clinical Development team, support from LLMs, and some time spent reading walls of text, we drafted an initial structure that showed strong commonality across the studies we reviewed, and captured the most important design elements of each one.

This first pass was relatively straightforward, essentially breaking each section of a study down into a concrete schema, similar to structures found in the AACT (Aggregate Analysis of 

This gave us a solid starting point, but it quickly revealed a key limitation. Many of the most important components, especially inclusion and exclusion criteria and study endpoints, were still just free text. If we wanted a data foundation that could be reused, compared, and analyzed programmatically, we needed to break these sections down much more precisely.

Let’s walk through an example. Take the eligibility criteria of the study 

With the exception of reformatted special characters, what you see here is exactly how the eligibility criteria are stored in the database – as a single, unstructured text field delimited by bullets. To structure these text fields, we took a few steps:

First, we used an LLM to break down the text into individual inclusion/exclusion criteria.

For each criterion, we parsed the text into a specialized JSON format specific to the text being parsed (e.g., endpoints and eligibility criteria have their own JSON formats)

Finally, we normalized the JSON using an LLM for general text processing (capitalization, parentheses, etc.).

After running step 1, a single exclusion criteria could read:

This was then passed into an LLM, which bucketed the criteria into a defined set of categories that would make them comparable across studies, such as “Medical Conditions and History,” “Lifestyle and Social Factors,” “Laboratory and Diagnostic Findings,” or “Demographic Information". Additionally, this process identified key pieces of information, including the attribute the criteria is measuring, the target value, and evaluation method of the criteria. For the above criteria, this looks like:

Once the criteria was distilled into a machine-usable format, words that were identified as unneeded specificity were removed.

Lastly, a final processing step normalized the text. This expanded abbreviations, removed redundant parentheticals, and standardized capitalization. The finished, fully processed study criteria looked like this:


Finally, we’re left with a finished first pass at a structured clinical trial, complete with critical free text fields (endpoints, criteria, arms/doses, etc.) structured and normalized in a machine-friendly manner.

Next, it was time to test our structure at scale. We wrote a script to programmatically parse any trial to conform to our structure. The script would ingest all data related to a clinical trial and pass it through our normalization process above.

As we wrote the script, our hope was that large-scale processing would uncover many identical components across trials, particularly within a single indication, where validated endpoints and population definitions are frequently reused.

These recurrences matter because they reveal which elements of clinical trials consistently occur across studies. They highlight the objectives, criteria, endpoints, and procedures that researchers rely on and that regulators have historically accepted. When we extract these recurring components into a single structured view, we can unlock a wide range of insights, such as which study features correlate with approval, which elements are more common in successful trials, how endpoints vary by phase, and much more. This becomes a powerful foundation for building more advanced analytics and applications across many functions.

With that in mind, we deployed our script across a subset of studies to see how well the approach held up in practice. The script ran successfully, but it surfaced several important learnings, especially around our goal of finding meaningful overlaps. Our first pass revealed three key takeaways:

Even with careful parallelization, passing any significant amount of data through a multistep processing and reprocessing pipeline that relies on LLMs at every stage is 

Overlapping components (e.g., criteria, endpoints) were present after processing, but weren’t as common as we’d hoped. Only about 9% of study components appeared in more than one study.

  database) were far too complex to deduplicate through structure alone. Many spanned multiple paragraphs and attempted to encode branching logic, making them extremely difficult to interpret consistently. Even when two endpoints were semantically identical, the phrasing varied so dramatically that our system struggled to treat them as the same.


The third takeaway involving the complexity of the endpoints was a major problem for us. Endpoints are one of the most critical components of a study’s design, and we wanted to be able to better understand when trials were using similar or different endpoints.

However, after a few iterations on the structural design of endpoints and several passes at the prompt we used to ingest them, it became clear that this was beyond the limit of what LLMs were capable of at the time. Our script was able to handle recurring eligibility criteria quite well, even with significant textual differences and more complex logical structures, but the inconsistent nature of endpoints prose proved too challenging for models to transform consistently.

For example, in one trial, a primary endpoint across two different studies might read:

Semantically, both these endpoints are saying the same thing, but our script was unable to take these two endpoint components, pass them through our generalized processing step for endpoints, and have them come out the other side as 

 JSON, which we needed for true standardization and consistency.

To address this problem, we experimented with vectorizing both the processed JSON and unprocessed plain text forms of the endpoint text. Vectorization converts text into numerical representations (embeddings) that capture semantic meaning, allowing us to compare endpoints that differ significantly in phrasing.

We tested multiple embedding methods and several clustering algorithms, each with different approaches to setting or pre-computing their parameters. Our hypothesis was that embeddings would allow us to group semantically similar endpoints more effectively, and that generating embeddings from a stringified version of our processed and normalized JSON might perform even better.

With the help of our clinical team, we built a ground truth dataset of endpoints that were semantically similar enough that a strong version of our algorithm should identify them as equivalent. We then experimented with embedding both the unprocessed plain text and the processed text, using K-Means clustering to test whether duplicates from our ground truth set would fall into the same clusters. For the embeddings, we compared TF-IDF embeddings, which use a traditional non-AI method for measuring string similarity, with OpenAI embeddings, which capture semantic meaning in a more sophisticated way.


After a large amount of experimentation, the clear winner was a two-step approach: processing the text with our existing algorithm, then embedding it using OpenAI embeddings.

This research also had an unexpected benefit. While our original approach to finding recurrences in eligibility criteria (i.e., processing the text and counting exact matches) worked reasonably well, we found that applying embeddings and clustering to those components increased the number of semantic duplicates our algorithm could identify, just as it had for endpoints.

At the end of this, we finally had a robust method for breaking each study into its core components as JSON, and a reliable way to programmatically measure the similarity of those components across studies.

Once we confirmed it was possible to clean the data effectively, it was time to clean 

 of it. After scaling up the script and conducting some careful cost modeling, we got the green light to ingest the past decade of studies from 

After two weeks of continuous runtime and several late-night stalls from unexpected bugs, the ingestion finally completed, landing within 10% of the midpoint of our projected cost range.

 ~260,000+ structured studies and 6,500,000 individual study components

, corresponding with all studies posted to 

 in the last decade, complete with categorization, structured logic, and OpenAI embeddings. This was our final structure across 260k+ studies:


After breaking down the data, including fields that previously had no delimiters in the AACT database and couldn’t be counted reliably, we were finally able to see the full distribution of study components. The numbers aligned with what you might expect from an average clinical trial. There were more secondary endpoints than primary endpoints, more exclusion criteria than inclusion criteria, and a generally high ratio of criteria to total endpoints. For the first time, we had a unified, standardized view of decades of clinical research, distilled into a format that could be used programmatically and serve as a foundation for more advanced analytics.

This dataset gave us a new way of reasoning about clinical precedent, comparing studies at scale, and understanding how trial designs evolve across indications. For the first time, we could trace patterns that had previously been buried in unstructured text scattered across hundreds of thousands of records.

More importantly, this foundation has unlocked entirely new capabilities. We can search and compare trials with precision, identify recurring design elements across therapeutic areas, study how endpoints rise and fall in popularity over time, and evaluate which components tend to appear in successful or unsuccessful programs. It also enables downstream analytics and systems that simply weren’t possible before, from feasibility modeling and competitive landscaping, to automated understanding of trial precedents.

This is only the beginning. By turning clinical research into structured, machine-usable data, we’ve created a foundation that we’ll be building on for a long time. In a future post, we’ll provide an in-depth exploration of the systems we’ve built on top of this dataset, including one that can generate a full clinical study design from a single prompt, complete with evidence grounded in real-world precedent.

How LLM-assisted processing transformed 260,000 unstructured clinical trials into 6.5 million structured components and embeddings

Structuring Clinical Trial Data at Scale

Pharma pipelines are constantly changing. Companies regularly conduct strategic reassessments of their portfolio, making decisions on which products to keep and which to cut. These decisions are rarely announced the moment they are made, if ever. A once-promising program might fade from the public record - unmentioned on earnings calls, missing from R&D updates, and omitted from SEC filings. They suddenly

fall silent, with little public information on what happened.

Some assets go dark because of scientific reasons, such as problematic safety data or lack of efficacy. These are challenging to rescue. However, some assets may be deprioritized for other reasons, such as loss of funding, strategic shifts, or the absence of an internal champion. Finding 

, the silent but potentially transformational “dark assets”, can be a goldmine of opportunities leading to new, more innovative therapies for patients around the world.

The question is, how? Traditional business-development workflows only surface what’s visible - mentions in company statements, active conference promotion, news articles and press releases, but they don’t capture what’s 

 being said. With thousands of active programs across the industry, it’s nearly impossible for teams to manually sift through data and track the quiet disappearances that happen every day.

This challenge is simple to describe, but difficult to solve. At Formation, we spent time building a system to canvas and monitor the world of potentially deprioritized assets and turn them into concrete signals for our BD team to act on.

To address this challenge, our team needed to define 

 as a signal. Silence is not just the absence of information, but the first sign of change.

When a company stops talking about a program, that decision ripples through its filings, press releases, and investor updates long before it ever shows up in databases or deal trackers. Each omission leaves clues as to the underlying strategic reasons, such as shifting focus, tightening budgets, or potential future divestiture.

Our first step became quite clear - to deploy an analytical method that could capture the 

of asset mentions in financial reports, news articles, and so forth as a distinct signal.

To do so, we built an automated system that listens across the public record, from SEC filings to earnings-call transcripts and press releases, and transforms both mentions and absence

of mentions into data. The system captures when and how an asset is discussed, while also tracking when a tonal shift occurs in communications (i.e. from confident to cautious), when an asset stops being mentioned (‘the silence’), and when that pattern begins to appear across multiple sources.

At its core, our system streamlines a process that would be impossible to manage manually at scale, continuously scanning three major forms of public disclosure: SEC filings (10-Ks, 10-Qs, and 8-Ks), earnings call transcripts, and press releases, to track how companies talk about their drug programs.


For each asset owned by a public company, the system asks three questions:

How is it being described? (positive, neutral, or negative tone)

Has that tone or frequency changed over time?

Using those inputs, each asset is assessed based on whether it is active and ‘noisy’, or whether it has fallen silent. The result is a dynamic, auditable list of assets that may be quietly falling out of focus, which our business development team can review for potential in-licensing opportunities.

Our ‘silence as a signal’ asset search process can be represented as a 

This three-layer data pipeline brings structure to unstructured public data and enriches it with scientific and transactional context.

Layer 1 – Creating a Structured Asset Ownership Dataset

Layer 1 answers the question of who actually controls each drug program, and when. We unify two pharma vendor data sources with company tickers and SEC identifiers to create a definitive ownership map. Marketed products and expired patents are filtered out so the focus remains on assets in development. This prevents false positives and ensures every subsequent signal is grounded in reality.

After a first pass, our pipeline output included over 8,000 distinct drug assets spanning approximately 1,100 public pharma companies. The programs covered a wide range of therapeutic areas, with oncology, immunology, and neurology together accounting for more than half of all identified assets. The breadth of data provided scale and diversity to the analysis, enabling the system to capture deprioritization trends across modalities, from small molecules to advanced biologics.

Layer 2 captures what’s being said (or not) across public communications and defines when absence becomes meaningful. Assets are considered ‘silent’ after roughly 12–18 months without mention across major disclosure types, a threshold chosen to balance typical reporting cycles with genuine disengagement. Natural-language and LLM-based models detect mentions, measure tone (positive, neutral, or negative), and tag context such as 

 Importantly, not all signals are silent - some programs remain in discussion, but their tone has shifted. Our models flag these subtler changes in sentiment and language, as such tonal softening can often foreshadow future silence. Temporal analysis then tracks how enthusiasm rises or fades over time, turning both explicit absences and early tonal drift into quantifiable signals of shifting corporate focus. The output is a signal score that measures how each asset’s visibility and tone evolve - a proxy for where attention is moving next.

 assets go silent. We define silence as zero mentions across SEC filings, earnings calls, and press releases within a phase-adjusted look-back window (18-36 months). Each source contributes to a weighted deprioritization score, with SEC filings weighted most heavily for their regulatory relevance. To interpret the absence of communication, GPT-4o is used as a classifier and extractor - parsing disclosure tone (positive, neutral, negative), tagging context (pipeline cut, resource shift, under review), and normalizing event dates. This LLM layer transforms raw text into structured, explainable signals that can be cross-checked against trial outcomes, drug profiles, and web-search-based termination rationales. External web data further fills information gaps, capturing credible third-party reporting where vendor datasets are silent. The result is a unified deprioritization record that not only flags silence but interprets its cause - distinguishing between strategic pauses, funding constraints, and genuine scientific dead-ends, allowing us to truly identify valuable “dark assets.”

This layered design allows the system to move from detection to interpretation, transforming raw disclosure text into actionable intelligence for business development.

With this system, we’ve turned what was once a manual, document-by-document search into a scalable discovery system. Instead of combing through filings and transcripts line by line, BD teams can now surface potentially available assets through structured, time-aware filters.

This acceleration gives BD teams a critical timing advantage: the ability to identify possible out-licensing or partnership candidates slightly earlier than competitors, when discussions are more open-ended.

The framework doesn’t replace human judgment; it expands bandwidth. Analysts can now focus on high-context follow-up rather than initial screening, moving from thousands of assets to a short list of silence-defined leads in minutes.

For each candidate, the system also provides an initial LLM-generated hypothesis - a lightweight explanation of what might be driving the pause, drawn from trial outcomes, public tone, and web evidence. These hypotheses aren’t conclusions but starting points, helping BD prioritize where to look next.

A concrete example of predictive signal detection comes from AZD2693, an AstraZeneca asset in NASH (nonalcoholic steatohepatitis). This asset was processed for having 0 explicit mentions in earnings call transcripts and press releases during a run of the pipeline in August. Our system was able to identify signals that flagged it as a potentially “dark” asset.

AstraZeneca announced it was discontinuing the program following disappointing Phase 2 data. 

This example underscores how the deprioritization pipeline provides alpha, giving us early intel into assets and portfolios that can be valuable in a number of different contexts.

Another example is BMS-986406, an oncology asset. At time of writing, major industry databases still list the program as being in Phase 1 development, and even a basic web search for “BMS-986406 discontinuation” shows no indication that the program has ended. However, our system detected silence - no recent mentions in SEC filings, press releases, or earnings-call transcripts - and follow-up review confirmed that BMS’s own public pipeline listings make no reference to the asset, nor does it appear on any active development page. BMS has not declared a discontinuation of the asset explicitly, but the absence of acknowledgement may give us hints of what’s to come.

When taken in aggregate, these quiet mismatches of explicit announcements and corporate reality may reflect upcoming portfolio divestitures or reprioritizations, or give us an updated view of company valuations at a given point in time. As you can imagine, there are many assets such as these, all which provide useful signals for our team to further evaluate.

The system is by no means “complete.” Building the deprioritization pipeline surfaced several lessons that shaped its evolution and will continue to be refined:

 Life science data surrounding asset ownership often lacks precision given real-time changes and the complexity of M&A deal contracts. We improved upon this by triangulating data sets from different vendors together to significantly improve data accuracy.

 Drugs often appear under multiple names - research codes, brand names, and generics. Standardizing across these identifiers reduced duplicate records and ensured consistent tracking.

 LLM prompts were refined in collaboration with human life science experts, such as our BD team, to better capture the nuances of what “deprioritized” means in practice, improving accuracy across tone and context classifications.

Each of these lessons tightened the system’s precision, reliability, and speed - turning an experimental search process into a scalable intelligence framework. We’re excited to continue improving on it and iterating from future learnings.

AI-enabled asset search, now and into the future

With this system, the bottom line is simple - we turned corporate silence into a measurable indicator of deprioritization, giving our asset search teams a new way to see what others may overlook and to act before the market catches up.

Our work here is just beginning. There are many more opportunities ahead, and we’re quickly building toward a future where we can continuously monitor the entire landscape of assets in real time - more to come.

Deprioritized asset search is just one of the many capabilities we’ve built in Atlas, our proprietary AI Drug Hunting platform. To learn more about our platforms, see

Technology

Learn more about how we bring together tech and drug development expertise.

How Formation looks for “dark assets”– silently deprioritized candidates that may reveal hidden opportunity

Searching Across Silence

 of this series, we explored the architecture behind 

, our GenAI-powered recruitment tool that streamlines patient recruitment for clinical trials. We detailed how Muse leverages OpenAI’s 

, dynamic workflows, and strategic automation to generate high-quality recruitment content efficiently.

The Technical Architecture Powering Our AI Recruitment Tool Muse 

Introducing Muse

In this follow-up, we’ll take a deeper look at the execution layer that powers Muse’s assistants—focusing on how the Threads API ensures contextual continuity, how assistants orchestrate multi-step workflows, and how users interact with and refine AI-generated content. We’ll also discuss some key challenges we’ve encountered, including improving content quality with limited user input, ensuring creative consistency, and learning from structured reasoning models. By addressing these challenges, we’re continuously evolving Muse into a more adaptable and intelligent system for clinical trial recruitment.

This project relies heavily on OpenAI Assistants and, more importantly, the Threads API. Threads provide a structured way to maintain execution history and context—essential for managing multi-step workflows.

Additionally, the API’s ability to automatically query the vector store for relevant material simplifies assistant configuration. This means vector lookups don’t need to be explicitly defined in workflows, making the system more user-friendly.

The assistant gathers all necessary material before execution, tailored to its role:

 – Strategic context is dynamically assembled, as described earlier.

For validation assistants – A structured process runs:

Retrieves descriptions of both the content-producing assistant and the validation assistant.

Extracts all relevant material from its vector store to create a validation guideline document.

Caches the result for future reuse, avoiding redundant processing.

This gathered context is inserted into the thread. So far, context window limits haven’t been a concern, as threads remain well within OpenAI’s maximum context length.

The assistant executes all defined task steps sequentially.

If the workflow involves dynamic branching, the assistant:

Clones the parent thread for each item, running subsequent steps in parallel.

The process continues until all nodes in the workflow tree complete execution.

Most assistants output data that must conform to a specific database model or JSON schema, ensuring smooth integration with front-end components. Once finalization is complete and broader orchestration nears completion, the data is presented to the user.

While advanced AI models and well-designed assistants significantly enhance content generation, they aren’t yet capable of consistently delivering expert human-level performance. To ensure high-quality outputs, users can interact with and refine the content in multiple ways:

Users can open a dedicated chat session on any generated content. (See image below)

These chats extend the original OpenAI Thread API execution, meaning:

Users can explore the reasoning behind the AI’s output, discuss source materials, or guide content in a new direction.

The AI retains context from the original workflow, allowing for informed and coherent responses.

If the conversation results in a rewrite, users can apply the change instantly, with updates reflected in the application. The chat interface is powered by real-time streaming via Server-Sent Events (SSE), ensuring a fast, responsive experience similar to a typical ChatGPT session.

Users can directly edit content for more precise control.

For richly formatted content (e.g., advertisements), the system:

Converts them into Markdown for easy editing.

Restores them to their original rich format using a lightweight structured-output LLM upon saving.

While validator feedback is applied automatically to the initial output, any manual edits trigger a one-minute validation process to review the changes. Users can accept or reject validator recommendations. Over time, user feedback from this manual review will help refine automatic validations, improving relevance, accuracy, and inclusivity.

This collaborative feedback loop ensures that AI-generated content continues to evolve and align with expert human judgment.

While Muse produces robust outputs, there are still key areas for improvement as development progresses.

1. Enhancing Content Quality with Limited User Input

One of the biggest challenges is ensuring novel and insightful content generation, even when user-provided data is sparse. A promising solution is to introduce more agentic behavior, enabling the system to:

Autonomously determine when additional real-world data is needed.

Select appropriate external sources to supplement missing information.

This evolution would make Muse more proactive in filling contextual gaps and ensuring high-quality outputs regardless of input variability. There is also an opportunity here to leverage Deep Research as well.

2. Improving Consistency in Creative Outputs

Muse’s most valuable contributions—such as identifying insightful patient groupings—require a level of creative ingenuity that can be challenging for a non-deterministic system.

Current Limitation – Some projects don’t always produce the most optimal results due to the inherent variability in LLM-generated outputs.

Potential Solution – Incorporating self-evaluation logic, allowing the system to:

Assess whether its initial response sufficiently meets task requirements.

Iterate or refine its approach before finalizing an output.

Models like o1, which follow a chain-of-thought reasoning approach, tend to deliver more consistent responses in structured tasks. This is because they allow for continued processing when initial outputs fall short.

While directly integrating o1 isn’t feasible due to cost, speed, and creative performance trade-offs, adopting similar recursive reasoning techniques within our workflow could enhance consistency and output quality.

By addressing these challenges, Muse will become even more adaptive, intelligent, and reliable in generating high-value content.

Muse represents a major step forward in AI-driven patient recruitment, but its true power lies in its ability to evolve. By leveraging OpenAI’s Assistants and Threads API, we’ve built a system that not only streamlines content creation but also fosters meaningful user collaboration. With real-time interaction, validation loops, and dynamic workflow execution, Muse ensures that AI-generated content remains accurate, compliant, and adaptable to the unique needs of each clinical trial.

However, our work doesn’t stop here. Challenges like enhancing content quality with limited input, improving creative consistency, and adopting more structured reasoning techniques will shape our next phase of development. By integrating smarter decision-making, refining validation processes, and continuously learning from user feedback, we aim to make Muse an even more intelligent and proactive tool.

As we push the boundaries of AI in clinical trial recruitment - and across clinical development in general - we’re excited about what’s ahead, and we look forward to sharing more innovations that bridge the gap between automation and human expertise.

Interested in joining our team to work on AI for clinical development? Check out our open roles 

Careers

, our GenAI-powered recruitment tool that streamlines patient recruitment for clinical trials. In this post, we’ll take a deeper look at the execution layer that powers Muse’s assistants.

Deep Dive into the AI Features and Technical Implementation of Muse

Patient recruitment has long been one of the toughest hurdles in running a clinical trial

. Defining a patient recruitment strategy and crafting recruitment materials that engage participants within regulatory guidelines—and ensuring they appeal to the diverse range of individuals needed for a trial to deliver accurate and meaningful results—is no small feat, and typically takes many months across a number of distinct teams. This challenge is frequently a bottleneck and a major-cost driver in the process of drug development.

Formation Bio’s AI system for patient recruitment

, represents a novel approach to overcome this challenge, harnessing the latest in GenAI technology to streamline the recruitment process for clinical trials (Figure 1). Its architecture is built around OpenAI's Assistants API tools (Figure 2). From a small handful of trial-relevant documents, Muse is able to produce everything ranging from prescreening questionnaires to fully-realized ads in a matter of minutes. Most importantly, it will synthesize a wide range of incoming information into strategic insights and various target audiences, and adapt the created content to best align with each of these audiences. The application of GenAI continues after initial creation, with conversational agents and sophisticated automatic validation enabling users to edit and adapt this content precisely to their target populations in a quick and intuitive manner.

In this post, we’ll explore the high-level architecture and key components that power Muse, offering a behind-the-scenes look at how we leverage OpenAI’s LLMs to create an efficient and effective tool for crafting recruitment strategies and content. We'll start by going over our data inputs, do an overview on Assistants, how Assistants are orchestrated and executed, how users interact with the Assistant outputs, and any challenges or additional opportunities to explore.

Muse’s outputs are entirely based on the data provided by the user, supplemented only by industry rules and guidelines that inform validation processes. Typically, user-provided documents include a study protocol, which outlines the eligibility criteria and objectives of a clinical trial. However, users can upload any relevant information to enhance Muse’s understanding.

Common sources of additional data include:

 – Background on the disease, including symptoms and impacts that may not be detailed in the protocol.

 – Statistical insights into the target patient population.

 – Information on existing treatments and competitors.

Once these files are processed and stored in a vector database, Muse’s AI assistants are ready to generate insights.

Each discrete task is handled by a dedicated OpenAI Assistant, which leverages machine learning and natural language processing (NLP) to analyze text, generate responses, and provide relevant information based on extensive training data. These assistants process user input, predict the most appropriate response, and can utilize tools such as web search or calculations to enhance their outputs.

Our implementation extends beyond OpenAI’s standard framework. In addition to configuring system prompts and key parameters (e.g., temperature), we design multi-step assistant workflows, chaining prompts together to generate more sophisticated and context-aware outputs.

Our AI assistants are grouped into three key categories, each designed to handle distinct aspects of the workflow:

 – Focused on research and analysis that inform content creation.

 – Establishes a standardized set of terms to ensure medical terminology remains accessible across all materials.

 – Extracts novel aspects of the trial from protocols and research, identifying unique characteristics that differentiate the study. For example, it may combine protocol details with treatment landscape data to highlight a drug’s distinctive effectiveness.

 – Uses attributes to identify meaningful patient groupings, allowing for more targeted and relevant outreach

 – Leverage strategic outputs to generate recruitment materials tailored to the identified segments.

 – Evaluate content through various lenses (e.g., IRB compliance, see image from Muse below) and provide structured feedback.

These assistants use dedicated vector stores containing regulatory guidelines and industry best practices to deliver precise, context-aware recommendations—similar to a human reviewer.

The IRB must approve all direct advertising materials for clinical trials before they can be used. In traditional workflows, this leads to significant back-and-forth revisions to ensure compliance. Many regulatory requirements are subtle—for example:

Ensuring the tone doesn’t overpromise or imply a guaranteed positive outcome.

Avoiding excessive emphasis on financial incentives for participants.

By equipping an assistant with IRB regulatory documents and defining a multi-step review process, we can surface IRB-like feedback early in the content creation process. This reduces compliance issues and minimizes last-minute revisions when the material is formally reviewed.

Manually programming and managing dependencies across multiple assistants would be both time-consuming and brittle. To keep our application flexible and support the seamless addition of new agents at any level, we designed it with a loosely coupled architecture in two key ways:

Each assistant’s workflow is configurable through a no-code interface, allowing users to chain prompts together into multi-step processes. For example, when defining an assistant to generate patient segments, the workflow might include:

 – Analyzing all generated attributes to identify meaningful patterns.

 – Identifying underserved populations or traditionally hard-to-recruit groups that might be a good fit for the trial.

 – Enriching identified segments with expected race, age, and demographic insights to guide content adaptation.

To enhance efficiency, we enable dynamic branching, where each workflow step clones the parent thread and executes in parallel with other branches (see 

Not all strategic elements are equally relevant to every assistant. Instead of manually defining these relationships, we allow assistants to self-determine relevant context at runtime by:

Analyzing their own description and comparing it with the descriptions of strategic assistants.

Automatically inserting relevant strategic outputs at the beginning of new threads to ensure contextual awareness.

This approach ensures assistants operate with the right strategic context without requiring explicit dependencies, making the system highly adaptable and scalable.

To illustrate how dynamic context gathering works, consider a simplified version of the Prescreening Form creation process. The system automatically pulls in relevant strategic outputs while filtering out unnecessary ones. 

It accepts outputs from strategic assistants that extract Inclusion/Exclusion (I/E) criteria and the glossary, ensuring consistency in terminology and regulatory compliance.

It excludes study-differentiating attributes, recognizing that these are more relevant for advertising rather than the strict guidelines required for prescreening forms.

Efficient Processing via Dynamic Branching

After the question outlining step, we employ dynamic branching to streamline execution:

Each question is assigned its own parallel subprocess, rather than processing the entire questionnaire at once.

This allows multiple evaluation and rewriting prompts to run concurrently, ensuring faster, more focused refinement of each question.

By leveraging context-aware selection and parallelized execution, our system maintains precision while optimizing efficiency.

This flexibility has significantly improved the quality of Muse’s outputs, allowing developers and domain experts to easily refine and adjust workflows without requiring Python expertise. By lowering the technical barrier, our system enables seamless collaboration and continuous optimization.

When generating content for a project, assistants are executed in a structured sequence:

These assistants analyze key inputs, such as glossary terms, eligibility criteria, and study attributes, providing foundational context.

Once strategic assistants complete, content assistants leverage their outputs dynamically, as described earlier.

Tech

Structuring Clinical Trial Data at Scale

Searching Across Silence

Deep Dive into the AI Features and Technical Implementation of Muse

The Technical Architecture Powering Our AI Recruitment Tool Muse

Formation Bio's AI Vision Statement