Tuesday, May 12, 2026

Can AI Develop a Clinical Trial Budget Calculator?

Over the last months, I have been experimenting with whether modern AI-assisted development platforms can support the creation of structured operational and budgeting systems for clinical research.

One interesting experiment was the development of a simplified Clinical Trial Budget Calculator (CTBC) using the AI-assisted platform Base44.

The result is a working prototype application:

https://ledger-flow-76f4f135.base44.app/

(The application currently requires free authorization via Google or email.)


Proposed Workflow

The idea behind this prototype is relatively simple:

1. Read and Parse Study Documents

The system should be able to read:

  • clinical trial protocols,

  • RFPs,

  • study outlines,

  • assumptions documents,

  • or similar operational materials.

The goal is to identify both:

  • protocol-driven cost drivers
    (visits, patients, countries, monitoring frequency, timelines, data complexity, etc.)

and

  • non-protocol operational assumptions
    (project management effort, vendor oversight, startup activities, reporting effort, risk assumptions, contingency logic, and operational overhead).

2. User Validation and Assumption Review

AI-generated assumptions should not be accepted automatically.

The user should be able to:

  • review extracted assumptions,

  • correct inconsistencies,

  • validate operational logic,

  • adjust effort estimates,

  • and update reusable budgeting rules.

This includes reviewing:

  • work units,

  • milestone structures,

  • role composition,

  • frequencies,

  • and calculation logic.

3. Budget Estimation

Once assumptions and rules are validated, the system generates:

  • workload estimates,

  • milestone rollups,

  • resource effort calculations,

  • and budget projections.

The objective is not full automation, but structured support for feasibility assessment and operational budgeting.


Example of a prompt for App generation:

Build a modern web application called:

Clinical Trial Budget Calculator (CTBC)

Purpose:
Create a scalable, protocol-driven clinical trial budgeting and operational planning application.

The application should transform:

  • protocol assumptions,

  • operational assumptions,

  • reusable work units,

  • project timelines,

  • countries/sites,

  • and role-based effort models

into:

  • detailed budget lines,

  • workload calculations,

  • milestone rollups,

  • dashboards,

  • and timeline views.

The app should support:

  • assumption review,

  • calculation validation,

  • scenario planning,

  • and future AI-assisted automation.

The design must remain understandable, modular, and scalable.


CORE CONCEPT

The budget engine calculates:

Approved Assumptions
× Work Units
× Unit Composition
× Quantity
× Locations
× Time Phases
× Bill Rates

Detailed Budget Lines

The system must support:

  • labor costs,

  • pass-through costs,

  • vendor costs,

  • investigator grants,

  • and future forecasting.


IMPORTANT DESIGN PRINCIPLES

  1. Separate:

  • protocol facts,

  • operational estimates,

  • benchmark assumptions,

  • and calculated values.

  1. Do NOT directly use extracted protocol values in calculations until they are reviewed or approved.

  2. The application must provide:

  • calculation traceability,

  • validation,

  • review workflow,

  • and assumption transparency.

  1. The application is NOT:

  • a validated CTMS,

  • eTMF,

  • ERP,

  • accounting system,

  • or regulatory system.

It is:

  • a budgeting and operational planning assistant.


MAIN MODULES

1. Study Setup

Fields:

  • Study Name

  • Protocol Number

  • Sponsor

  • Indication

  • Study Phase

  • Study Design

  • Currency

  • Status

  • Description


2. Protocol Upload

Allow upload of:

  • protocol PDFs

  • RFPs

  • contracts

  • amendments

  • scope documents

Fields:

  • Study ID

  • Document Name

  • Document Type

  • Upload Date

  • Parsing Status

  • Version


3. Protocol Assumptions Extraction

The system should parse uploaded protocols and extract:

  • enrollment

  • sites

  • treatment duration

  • follow-up windows

  • visit schedule

  • procedures

  • labs

  • ECG

  • PK sampling

  • imaging

  • questionnaires

  • central lab requirements

  • IRT/IWRS

  • safety follow-up

  • visit burden

Store extracted information in a review table.

Fields:

  • Assumption ID

  • Study ID

  • Source Document

  • Assumption Category

  • Extracted Assumption

  • Value

  • Unit

  • Source Page

  • Source Section

  • Confidence Level

  • Review Status

  • Reviewed By

  • Review Date

  • Notes


4. Operational Assumptions

Allow manual assumptions for items NOT usually found in protocols:

Examples:

  • countries

  • country allocation

  • site allocation

  • CRF pages

  • queries per subject

  • monitoring frequency

  • monitoring strategy

  • bill rates

  • investigator grants

  • travel assumptions

  • startup duration

  • closeout duration

  • contingency

  • vendor assumptions

Fields:

  • Assumption Name

  • Category

  • Value

  • Unit

  • Assumption Type

  • Rationale

  • Scenario

  • Review Status


5. Time Phases

Support:

  • Initiation

  • Startup

  • Enrollment

  • Treatment

  • Follow-up

  • Data Cleaning

  • Database Lock

  • Closeout

Fields:

  • Phase Name

  • Start Date

  • End Date

  • Duration

  • Scenario

  • Notes


6. Locations

Support:

  • Region

  • Country

  • Site

  • Site Group

Fields:

  • Country

  • Region

  • Site Name

  • Site Count

  • Enrollment Count

  • Country Multiplier

  • Grant Multiplier

  • Travel Multiplier


7. Roles and Rates

Examples:

  • CRA

  • Lead CRA

  • Project Manager

  • CTA

  • Data Manager

  • Safety Specialist

  • Regulatory Specialist

  • Medical Monitor

  • Biostatistician

  • Vendor Manager

Fields:

  • Role Name

  • Department

  • Seniority

  • Hourly Rate

  • Currency


8. Work Unit Library

Reusable operational units.

Examples:

  • PSV

  • SIV

  • RMV

  • COV

  • Weekly Sponsor Call

  • Query Management

  • SAE Review

  • TMF QC

  • Vendor Oversight

  • Database Lock

Fields:

  • Work Unit Name

  • Milestone

  • Deliverable

  • Description

  • Unit Type

  • Default Quantity Logic

  • Linked Assumption

  • TMF Deliverable

  • WBS Code


9. Work Unit Composition

Each work unit can contain multiple components.

Example:

RMV Trip Report:

  • CRA II Visit → 8h

  • CRA II Travel → 2h

  • CRA II Report Writing and Filing → 2h

Weekly Sponsor Call:

  • PM → 1h

  • Project Director → 1h

  • CTL → 1h

  • Data Manager → 1h

  • Medical Monitor → 1h

  • Vendor Manager → 1h

Fields:

  • Work Unit

  • Role

  • Activity

  • Hours per Unit

  • Fixed Cost

  • Notes


10. Milestones

Hierarchy:

Study
→ Phase
→ Milestone
→ Work Unit
→ Budget Line

Milestones should roll up:

  • work units

  • hours

  • costs

  • timelines

  • deliverables

Fields:

  • Milestone Name

  • Phase

  • Start Date

  • End Date

  • Status

  • Budget

  • Hours

  • Deliverables


11. Deployment Plan

Deploy work units across:

  • phases

  • countries

  • sites

  • years/months

Fields:

  • Study

  • Scenario

  • Work Unit

  • Phase

  • Country

  • Site

  • Year

  • Month

  • Quantity


12. Budget Engine

Generate detailed budget lines dynamically from:

Approved Assumptions
× Work Units
× Unit Composition
× Deployment Plan
× Locations
× Rates

Generated fields:

  • Budget Line ID

  • Study ID

  • Scenario

  • Phase

  • Milestone

  • Country

  • Site

  • Year

  • Month

  • Work Unit

  • Role

  • Quantity

  • Hours per Unit

  • Total Hours

  • Bill Rate

  • Labor Cost

  • Pass-through Cost

  • Total Cost

  • Source Assumption

  • Validation Status

Budget line IDs should support hierarchy:
1.1.0.5.4.3


13. Pass-through Costs

Support:

  • investigator grants

  • central labs

  • ECG vendor

  • PK bioanalysis

  • imaging

  • eCOA

  • EDC

  • IRT/IWRS

  • travel

  • translations

  • regulatory fees

  • insurance

  • archiving

  • drug supply

  • IP cost

If exact values are unknown:
mark as:

  • Requires Manual Input

  • Sponsor Supplied

  • Excluded


14. Validation and Review

Very important.

The app must validate:

  • missing assumptions

  • inconsistent deployment

  • missing rates

  • missing locations

  • duplicate work units

  • invalid dates

  • empty milestones

Validation dashboard:

  • Errors

  • Warnings

  • Missing Inputs

  • Review Required

Add:

  • Draft

  • Reviewed

  • Approved

  • Locked

calculation statuses.


15. Scenarios

Support:

  • Base Case

  • Low Case

  • High Case

  • Amendment Scenario

  • Change Order Scenario


16. Dashboards

Show:

  • total budget

  • labor vs pass-through

  • cost by country

  • cost by phase

  • cost by milestone

  • cost by role

  • cost by vendor

  • cost by year/month

  • top cost drivers


17. Timeline / Gantt View

Add simple Gantt-style visualization:

  • phases

  • milestones

  • start/end dates

  • budget

  • hours

Filter by:

  • study

  • scenario

  • country

  • phase


18. EXPORTS

Support export to:

  • Excel

  • CSV

  • Google Sheets

  • Power BI friendly tables


19. USER EXPERIENCE

Workflow:

Create Study
→ Upload Protocol
→ Review Extracted Assumptions
→ Add Operational Assumptions
→ Define Deployment
→ Generate Budget
→ Validate
→ Review Dashboard


20. FUTURE SCALABILITY

Design architecture so future versions can support:

  • TMF integration

  • CTMS integration

  • ERP integration

  • forecasting

  • invoicing

  • scenario simulations

  • AI-generated work units

  • amendment comparison

  • protocol version comparison

  • resource forecasting

  • earned value management


21. DESIGN STYLE

The application should:

  • look modern and professional

  • be visually clean

  • support editable tables

  • support filters

  • support drill-down

  • support dark/light mode if possible

  • support scalable database architecture

Keep the interface understandable even for non-technical users.

Current Limitations and Open Discussion

At the current stage, freely available AI-assisted development platforms are still insufficient to fully support the complexity of clinical trial budgeting and operational modeling.

While prototypes can already be generated surprisingly quickly, major challenges remain around:

  • validation,

  • consistency,

  • reusable rule structures,

  • protocol interpretation,

  • scenario management,

  • and reliable downstream calculations.

This experiment is therefore only an early exploration of what may become possible in the future.

The broader conceptual direction behind this work is described here:

Exploring AI-H Budgeting Framework for Clinical Trial Financial Feasibility: A Conceptual Analysis
https://doi.org/10.5281/zenodo.15651378

Anyone interested in:

  • AI-assisted budgeting,

  • operational modeling,

  • protocol-driven planning,

  • or clinical trial financial feasibility

is welcome to share ideas or comments below this blog post.


No comments:

Post a Comment