Codex Clinical Form Studio

Inspiration

Building an electronic Case Report Form (eCRF) from a clinical trial protocol is still a highly manual and fragmented process.

Clinical teams must interpret protocol requirements, define data fields, configure validation rules, identify appropriate CDISC/CDASH concepts, review multiple revisions, and coordinate with engineering and QA teams before a form can be released. Even a small protocol amendment may require extensive manual comparison and retesting.

We wanted to explore a different approach: a clinical form engineering workflow in which the protocol specification is structured, version-controlled, AI-assisted, and continuously testable.

Codex Clinical Form Studio was inspired by the idea that clinical professionals should be able to collaborate with AI without directly editing application code. Codex helps translate clinical change requests into technical implementation, while clinical users remain responsible for reviewing and approving every important decision.

What it does

Codex Clinical Form Studio is an AI-assisted platform for building, reviewing, testing, and releasing CDISC-aligned eCRFs.

The workflow begins with a structured YAML specification generated from a clinical protocol. YAML acts as the source of truth for form fields, data types, validation rules, options, units, CDISC mappings, approval status, and version information.

Clinical users can then:

Review fields extracted from the protocol
Add, modify, reorder, or remove fields
Configure required fields, ranges, formats, and controlled options
Use natural-language instructions to propose form changes
Search for relevant CDISC/CDASH concepts
Review AI-ranked mapping candidates and explanations
Approve or reject proposed mappings
Generate a runnable HTML eCRF
Execute browser-based QA tests
Compare different versions of the form specification
Release an approved and tested version through GitHub CI/CD

The system follows a human-in-the-loop model. AI may recommend a field configuration, mapping, or correction, but a clinical user must approve the change before it becomes part of the approved specification.

When QA identifies a failure, the platform distinguishes between two types of problems:

A specification issue, where the YAML does not correctly describe the intended rule
A renderer issue, where the generated HTML does not correctly implement an approved YAML rule

This prevents the generated HTML from becoming disconnected from the approved clinical specification.

How we built it

We designed the platform around a specification-driven architecture:

Clinical Protocol → YAML Specification → Clinical Review → CDISC Mapping → eCRF Generation → Browser QA → Version Comparison → Deployment

The main components include:

ASP.NET Core and C# for the application backend
Blazor for the interactive clinical form authoring interface
YamlDotNet for parsing and generating version-controlled YAML specifications
OpenAI GPT-5.6 for protocol-aware analysis, CDISC candidate ranking, mapping explanations, QA root-cause analysis, and structured change proposals
Codex for implementing application features, generating and refining UI components, building automated tests, diagnosing failures, and improving the development workflow
Microsoft Playwright for .NET for browser-based validation of generated eCRFs
GitHub and GitHub Actions for version control, automated builds, QA execution, and deployment

Each field is represented as structured data rather than hard-coded HTML. The renderer reads the approved YAML and produces the corresponding input components and validation attributes.

For CDISC mapping, the platform retrieves possible concepts from an external terminology or standards service. GPT-5.6 evaluates the candidates using the field label, form context, datatype, unit, protocol description, and visit information. It then presents ranked suggestions with an explanation and confidence score.

The final mapping decision is made by the clinical user.

We also created a structured version comparison page that highlights:

Added fields
Removed fields
Modified data types
Required-status changes
Validation-rule changes
Controlled-option changes
CDISC mapping changes

After clinical approval and successful QA, the selected YAML version and generated eCRF can be committed to GitHub and deployed through an automated pipeline.

Challenges we ran into

One of the most difficult challenges was defining the correct boundary between AI automation and clinical responsibility.

The system needed to provide useful recommendations without presenting AI-generated mappings or form rules as authoritative clinical decisions. We addressed this by making approval status an explicit part of the YAML specification and requiring human confirmation before proposed changes could be released.

Another challenge was maintaining consistency between the specification and the generated application. Allowing users or automated tools to directly modify generated HTML could cause the deployed form to diverge from the approved YAML. We therefore treated HTML as a generated artifact rather than the primary source of truth.

Browser QA also introduced an important architectural question: when a test fails, should the system modify the YAML or the renderer? We created a root-cause workflow that first determines whether the approved specification is incorrect or whether the renderer failed to implement it.

CDISC mapping was another complex area. A clinical phrase may correspond to multiple possible concepts depending on its context, datatype, unit, and intended use. Instead of returning a single opaque answer, the system presents multiple ranked candidates with explanations and leaves the final decision to the clinical reviewer.

Finally, we had to balance the scope of a complete clinical platform with the time constraints of a hackathon. We focused on demonstrating one complete, traceable workflow rather than attempting to implement every CDISC domain, enterprise permission model, or CTMS integration.

Accomplishments that we're proud of

We are proud that the project demonstrates a complete workflow rather than an isolated AI feature.

A clinical user can move from a structured specification to an editable form, review AI-assisted CDISC recommendations, approve changes, generate an eCRF, run browser QA, compare revisions, and release a validated version.

We are especially proud of the following capabilities:

Using YAML as a traceable and version-controlled clinical specification
Keeping clinical users in control of AI-generated recommendations
Providing explainable CDISC/CDASH mapping candidates
Generating functional eCRFs from approved structured data
Testing form behavior in a real browser with Playwright
Detecting whether a QA failure originates from the specification or the renderer
Showing meaningful field-level differences between form versions
Connecting clinical approval and QA results to a GitHub deployment workflow

The project also demonstrates how Codex can participate throughout the software lifecycle—not only by generating initial code, but also by refining interfaces, implementing tests, diagnosing failures, and supporting iterative development.

What we learned

We learned that AI is most useful in regulated or clinical workflows when it does not attempt to replace domain experts.

The strongest workflow was not fully autonomous. It was a collaboration in which AI handled search, comparison, implementation, testing, and explanation, while clinical users provided context and made final decisions.

We also learned that structured specifications are critical for reliable AI-assisted development. Natural-language instructions are flexible, but YAML provides a stable contract between the protocol, clinical review process, renderer, QA system, and deployment pipeline.

Another important lesson was that generated code should not become an uncontrolled second source of truth. By regenerating the eCRF from approved YAML, we can preserve traceability and reduce configuration drift.

Browser automation also proved valuable beyond conventional software testing. In this project, Playwright acts as an independent verification layer that confirms whether clinical validation requirements are actually enforced in the deployed user interface.

Finally, we learned that Codex is most valuable when it is integrated across the development process. It helped connect product requirements, application code, automated testing, debugging, and deployment into a more continuous workflow.

What's next for Codex Clinical Form Studio

The next step is to expand the prototype into a broader clinical form engineering platform.

Planned improvements include:

Supporting additional CDISC/CDASH domains and controlled terminology
Adding more advanced cross-field and visit-level validation rules
Improving protocol amendment impact analysis
Generating clinical change summaries for reviewers
Supporting reusable form and field libraries
Adding role-based review and approval workflows
Introducing electronic signatures and complete audit trails
Integrating with CTMS, EDC, and clinical data management platforms
Exporting additional machine-readable clinical metadata formats
Supporting multilingual clinical form generation
Expanding automated accessibility and usability testing
Adding pull-request-based review workflows for clinical specification changes

We also plan to make the version comparison more clinically meaningful. Instead of only showing that a field changed, the platform could explain how the change may affect data collection, existing records, validation behavior, downstream integrations, and study operations.

Our long-term vision is to make clinical form development a transparent collaboration between clinical experts, engineering teams, QA systems, and AI agents—from protocol interpretation to production deployment.