Clinical trial protocols are dense legal documents — often 200+ pages — that define every aspect of a study. They're simultaneously contracts, scientific plans, and operational blueprints. Protocol Explorer demonstrates what it looks like when this complexity is made navigable, machine-readable, and actionable through structured design.
The problem
During my time at Signalpath and IBM Watson Health, I worked directly with clinical trial operations teams. The pain points were consistent:
- Fragmentation — Protocol data lives in Word documents, spreadsheets, and multiple downstream systems (EDC, CTMS, IRT). Each requires manual re-entry.
- Versioning chaos — Amendments cascade through every system. There's no single source of truth.
- No machine-readability — PDF protocols can't feed directly into operational software. Humans re-type structured data from unstructured documents.
The industry standard, CDISC's Unified Study Definitions Model (USDM), addresses this by decomposing protocol content into JSON structures that flow automatically into trial systems. But few teams have seen what this looks like in practice.
Design goals
Make the structure visible. Protocol Explorer isn't a PDF reader — it's a demonstration of structured protocol architecture. Four views:
- Objectives — Primary, secondary, and exploratory endpoints organized by tier
- Population — Inclusion/exclusion criteria presented as parallel lists
- Schedule — Visit windows and activities rendered as a timeline
- Data Model — Machine-readable JSON showing how content maps to USDM fields
Show, don't explain. Instead of describing the CDISC standard, the interface is the standard. Users can explore a realistic Phase III protocol structure, copy the JSON, and see how human-readable content and machine-readable data coexist.
Design for clinicians and engineers. Clean, restrained typography for readability alongside monospace fonts and syntax highlighting for technical credibility. The interface bridges both audiences without feeling like a developer tool or an oversimplified dashboard.
Clinician chat interface
The second half of this project is a prototype chat interface layered on top of the same protocol data. It demonstrates a pattern that I think is underexplored in clinical trial software: using structured protocol data as the grounding layer for a natural-language interface.
A clinician using a real system built on USDM-compliant data could ask questions like:
- "Is this patient eligible given their eGFR result?"
- "What's the visit window for Week 12?"
- "Which sites have capacity to enroll?"
- "What adverse events need to be reported within 24 hours?"
The prototype here is keyword-matched and fictional — no LLM, no database. But the interaction model is real: when protocol content is structured rather than buried in PDFs, it becomes queryable. The same JSON that configures an EDC system can ground an AI assistant, populate a patient-facing app, or answer a coordinator's question in plain language.
This is the core argument for digital protocols: structure unlocks surface area.
Implementation
Built as two self-contained React components — the protocol viewer and the chat interface — with no external dependencies except lucide-react for icons. Styled with Tailwind CSS and designed to be:
- Self-contained — Drop into any React app or framework
- Composable — The viewer and chat are independent; either can be used standalone
- Responsive — Works across desktop and mobile viewports
- Accessible — Keyboard navigation, semantic HTML, clear focus states
The architecture is ready for module federation or monorepo deployment. Swapping the keyword-matched chat responses for a real LLM grounded on live USDM data would require changing one function.
Data model
The underlying data structure mirrors CDISC USDM v3.0:
{
studyObjectives: [
{ id, tier, statement, endpoints: [...] }
],
populationDefinition: {
inclusion: [...],
exclusion: [...]
},
scheduleOfActivities: [
{ visit, window, activities: [...] }
]
}This isn't a full protocol builder — it's a demonstration layer showing how decomposed protocol content can be rendered, navigated, and exported. The data lives in plain JavaScript objects, not a database, making it trivial to swap in real study data.
Context
This project synthesizes patterns I observed at:
- Signalpath — Working with sponsor teams managing multi-site trials and navigating protocol amendments
- IBM Watson Health — Building software that ingests protocol data and surfaces it to operational users
Outcomes
Protocol Explorer serves as:
- A design reference for teams implementing USDM-compliant systems
- A conversation tool for explaining digital data flow to non-technical stakeholders
- A proof of concept for clinician-facing chat interfaces grounded on structured protocol data
- A portfolio piece showing how I think about information architecture in regulated industries
This project is a working demonstration you can click through, query, and break, demonstrating why structured protocol data matters and what it looks like when done well.