Vitra

• 

  Vitra

Inspiration

Clinical research teams face a demanding task: reviewing detailed study requirements against patient information to identify potential participants. Eligibility criteria can involve diagnoses, medications, lab values, and treatment history, making it difficult to track which requirements are supported and which need further review. We built Vitra to help researchers organize that work. By structuring trial criteria, showing the evidence behind each potential match, and highlighting missing information across a synthetic cohort, Vitra aims to make candidate review clearer and help teams identify what to investigate next. We also wanted patients to better understand the studies they explore, giving researchers and participants a clearer starting point for conversations while leaving screening and enrollment decisions with the study team.

What it does

Vitra is a two-sided clinical trial discovery and review platform centered on helping researchers inspect potential candidates. Researchers can explore real ClinicalTrials.gov records, parse eligibility criteria, and compare them with fictional patient profiles. Each requirement is displayed as:

• MET: Available evidence supports the requirement.
• NOT MET: Available evidence conflicts with the requirement.
• UNKNOWN: Information is missing or the requirement needs manual interpretation. Each result includes its supporting evidence and original criterion wording, helping researchers understand what warrants further review. Recruitment Bottleneck Intelligence summarizes conflicts and missing information across the synthetic cohort. Researchers can inspect these patterns and update simulated candidate workflow statuses. Patients can explore and save studies, then ask questions through a trial explainer grounded in the selected study’s actual information. Vitra identifies potential matches for review. It does not determine medical eligibility or replace official screening.

How we built it

We built the interface with React, Vite, JavaScript, and CSS, and used Python, FastAPI, and Pydantic for the backend and data validation. The ClinicalTrials.gov API supplies real public study records. Our synthetic patient module imports FHIR R4 records, normalizes supported clinical fields, and preserves provenance so researchers can trace evidence back to its source. Deterministic rules evaluate supported eligibility requirements. Google Gemini assists with patient-friendly explanations, while the server attaches original source citations and checks generated responses. Firebase Authentication and Cloud Firestore support account and data features. We also created a deterministic judging mode with dated trial snapshots and fictional profiles, allowing the core workflow to run without an external API or AI connection.

Challenges we ran into

One of our hardest challenges was preserving the meaning of clinical criteria. Negation, exclusions, treatment timing, and compound requirements can change how a rule should be evaluated. We chose to flag unsupported wording for researcher review rather than guess. AI citations were another challenge. Generated excerpts could differ from the original record, causing validation failures. We changed the design so the model selects source identifiers and the server supplies the unchanged source text. Integration also required careful debugging. We fixed inconsistent sidebars, stale backend connections, dependency issues, and official study pages that did not survive a refresh correctly.

Accomplishments that we're proud of

We connected real trial discovery, synthetic patient data, criterion-level matching, recruitment insights, and sourced explanations into one demonstrable researcher workflow. Researchers can move from a study’s original criteria to candidate evidence, inspect missing-data barriers, and record simulated review progress while keeping uncertainty visible. Our QA work produced 68 passing backend tests, 20 passing JavaScript tests, and seven passing browser tests, alongside a successful production build. The browser tests include the offline judging workflow, mobile controls, navigation consistency, and saved workflow updates.

What we learned

We learned that a useful researcher tool needs to explain its results. Reviewers need to see the original requirement, the supporting evidence, and the information that is still missing. Uncertainty therefore became a visible part of the product. Missing information remains UNKNOWN, helping researchers distinguish an unresolved question from a known conflict. We also learned that AI explanations and clinical matching need different responsibilities. AI can make information easier to understand, while deterministic rules make supported comparisons reproducible and auditable. Testing the complete workflow revealed issues that individual components did not expose, especially around navigation, persistence, and service failures.

What's next for Vitra

We want to expand the supported eligibility rules, improve how researchers review unresolved criteria, and validate the matching behavior with clinical research professionals. We also want to evaluate whether the workflow helps research teams review candidates more consistently and identify missing screening information sooner. Vitra remains a synthetic-data prototype. We have not measured real recruitment outcomes or clinically validated its matching, but we have built a foundation for clearer, more transparent candidate review.

Built With

• clinicaltrials.gov-api
• cloud-firestore
• css
• fastapi
• firebase
• google-gemini
• javascript
• leaflet.js
• openstreetmap
• pydantic
• python
• react
• uvicorn
• vite