Inspiration
Medical research is published continuously across hundreds of journals and medical conferences but clinicians rarely have time to monitor every source, verify each abstract, and be exposed to the latest data. This can have dire consequences for patients. For instance in my practice of Medical Oncology lack of awareness of latest data about KRAS inhibition can prevent patients from being able to access these life saving drugs.
I wanted to create a system that could transform newly published research into an engaging broadcast without sacrificing editorial control or scientific traceability. The goal was not to automate medical judgment. It was to automate the repetitive work around discovery, organization, and learning bringing written text into an audio and video format for better learning.
What it does
ConferenceHype turns newly published medical literature into video briefings.
The platform:
• Monitors more than 100 medical journals using PubMed as the authoritative article source, with publisher RSS feeds used as supplemental discovery signals.
• Retrieves titles, citations, publication metadata, and available abstracts.
• Rejects title-only, incomplete, erratum, insufficient-content, and other unsuitable records.
• Converts quality-passed articles into structured, source-attributed review cards.
• Preserves Background, Methods, Results, and Discussion when those sections are available.
• Places new cards into a pending-review queue rather than publishing them automatically.
• Lets an operator select a date, time, journals, conferences, and news sources for a program.
• Creates a visible presentation sequence that the operator can review, edit, reorder, approve, reject, or replace.
• Supports a mixed 60-minute broadcast and focused 30-minute single-journal broadcasts.
• Generates deterministic narration, applies medical pronunciation rules, and replaces empty content with music rather than narrating failure messages or placeholders.
• Renders the complete program before release, uploads it publicly to YouTube, and keeps the website, database, and YouTube handoff aligned to the same video.
Every broadcast card contains its supporting citation. ConferenceHype provides educational AI commentary and is not medical advice or independent medical reporting.
How we built it
ConferenceHype is a Next.js and TypeScript application deployed on Vercel, with Supabase providing the editorial database, scheduling state, card inventory, presentation sequences, broadcast writeouts, and delivery state.
The journal pipeline searches PubMed for each enabled journal, reconciles optional publisher RSS results, classifies every article, and builds cards deterministically from available source content. Quality gates prevent incomplete or unsuitable cards from reaching the review queue.
The operator-facing admin workflow separates card creation from broadcast provisioning. An operator first selects the date, time, and intended sources, then creates and reviews the presentation sequence. Only after that review does the operator create or start the broadcast.
The rendering pipeline uses FFmpeg and Kokoro text-to-speech to produce a complete video. It normalizes the program to its intended duration, uses stored music for unfilled intervals, uploads the finished artifact to YouTube, and verifies that YouTube, Supabase, and ConferenceHype all reference the same result.
GitHub Actions performs journal ingestion, card generation, regression testing, production rendering, upload, cleanup, and delivery verification.
I used Codex with GPT-5.6 as an engineering collaborator throughout Build Week to finally make it work. Prior versions were buggy and just would not work. Codex inspected the existing repository and production workflow, traced failures across GitHub Actions, Supabase, Vercel, YouTube, and FFmpeg, proposed incremental changes, implemented targeted fixes, added regression tests, and ran real shadow and production workflows. I retained control over product policy, medical-content safeguards, source selection, broadcast format, cost constraints, and which changes were approved for production. I used Codex with GPT-5.6 for repository-scale engineering rather than one-shot code generation.
Codex helped me:
• Inspect the existing architecture, README, database workflow, and GitHub history before proposing changes.
• Trace a narration mismatch in which a journal label could disagree with the article being discussed.
• Design and implement a PubMed-first journal-card pipeline covering more than 100 journals.
• Add quality gates that reject incomplete, title-only, insufficient-content, and failure-language cards.
• Preserve operator-rejected and quality-failed states correctly across repeated inventory runs.
• Diagnose and repair double-counted quality failures and synchronization rows left in a running state after cancellation.
• Surface publisher RSS failures as visible supplemental-source warnings without treating them as PubMed failures.
• Add deterministic medical-language and pronunciation guards, including the required pronunciation of cholangiocarcinoma.
• Test real GitHub Actions workflows in safe shadow mode before authorizing card creation.
• Run a production journal-card job and verify the created cards directly against their PubMed ledger records.
• Migrate the delivery architecture from unreliable live RTMP streaming to render-then-upload completed videos.
• Add and test focused 30-minute journal broadcasts.
• Diagnose FFmpeg timing, music placement, narration, and post-render persistence problems.
• Upgrade GitHub Actions from deprecated Node 20 actions to Node 24-compatible releases.
• Create rollback checkpoints, preserve unrelated local work, and keep tested GitHub main as the production source of truth.
The most valuable contribution was not merely producing code. Codex repeatedly connected evidence across code, logs, APIs, database records, and live workflow outcomes. I made the final decisions about workflow design, editorial safeguards, costs, broadcast behavior, and production deployment.
ConferenceHype existed before OpenAI Build Week. The submission is based on the substantial extension completed during the July 13–21, 2026 submission period.
New Build Week work includes:
• A complete 30-minute single-journal broadcast format with dedicated scheduling, admin controls, rendering behavior, and manual dispatch.
• Focused journal-broadcast creation and Run Now controls.
• A journal-broadcast archive and clearer scheduling interface.
• A migration from live RTMP broadcasting to rendering and uploading complete videos.
• Immediate public YouTube uploads using metadata derived from the final rendered cards.
• Protection against empty or music-only broadcasts.
• Delivery-state fixes ensuring the correct queued broadcast appears on the public website.
• Post-render retries and accurate database error reporting.
• Duplicate-dispatch protection and constant-bitrate rendering safeguards.
• Improved review-queue navigation, journal grouping, bulk approval, and access to the full weekly card pool.
• A PubMed-first journal ingestion and quality workflow covering more than 100 medical journals.
• Structured card validation, abstract completeness checks, citation enforcement, and operator-review states.
• Interruption cleanup, accurate counters, RSS warning summaries, and production workflow regression tests.
• Medical pronunciation safeguards.
• GitHub Actions modernization to the Node 24 runtime.
Evidence is available in the repository’s dated commit history from July 13 through July 20, 2026.
Challenges we ran into
The hardest challenge was maintaining scientific grounding while automating a multimedia workflow.
A feed can provide a title without an abstract. A publisher RSS endpoint can return HTTP 403 while the same journal is available in PubMed. An article can be indexed under a journal title variant. A card can look complete in the database but still contain poor broadcast copy. A render can complete while a database write silently fails. A video can upload correctly while the public site points to a different queued slot.
We addressed these problems by treating PubMed as the authoritative journal source, requiring complete viewer-facing content, preserving explicit quality states, separating warnings from failures, and verifying every major transition.
The real-time RTMP design was another major challenge. It was sensitive to timing, connection stalls, and long-running workflow behavior. We ultimately made the product more reliable by rendering the complete program first and uploading the verified artifact afterward.
A final challenge was improving a working system without destabilizing it. We used incremental changes, focused regression tests, shadow production runs, real database verification, and a Git rollback checkpoint.
Accomplishments that we're proud of
I am proud that ConferenceHype does more than generate summaries.
It operates as a complete editorial and broadcast system:
• More than 100 journals are monitored.
• PubMed is used as the authoritative record whenever available.
• Every generated article card passes explicit completeness and quality checks.
• Cards remain under operator control until approved.
• Empty or failed content is never narrated as medical information.
• A full presentation can be rendered into a deterministic video artifact.
• The same video is tracked across the database, YouTube, and the public site.
• The system supports both hour-long mixed programming and focused journal broadcasts.
• Real production workflows were tested rather than relying only on unit tests.
During the final production journal-card run, four newly eligible articles produced complete, cited, quality-passed pending-review cards with no journal-processing failures or stale synchronization states.
What we learned
We learned that trustworthy medical-content automation depends as much on exclusion and state management as it does on generation.
The system must know when not to create a card. Missing abstracts, insufficient results, errata, mismatched sources, duplicate articles, and failure messages all require different handling.
We also learned that PubMed and RSS should not be treated as equivalent sources. PubMed provides the authoritative indexed article record, while RSS is useful as a supplemental discovery signal but can be unreliable in cloud-hosted workflows.
On the engineering side, we learned that a successful media command does not prove successful delivery. Rendering, upload, database persistence, public-site alignment, and editorial-state transitions must each be verified.
Finally, working with Codex was most effective when it was given concrete product constraints, access to real evidence, and permission to test—but not permission to make unreviewed product decisions. The strongest results came from iterative collaboration between human judgment and agentic engineering.
What's next for ConferenceHype
Next, I want to improve ConferenceHype in four areas:
• Editorial analytics that show which journals, specialties, and article types consistently produce strong broadcast cards. Use social media to highlight trending journal articles.
• Automate this channel with Codex so it can run 24x7 in multiple languages. Obtain better operator previews for pronunciation, pacing, citation display, and final narration before rendering.
• Personalized specialty channels that let clinicians follow focused cardiology, oncology, neurology, surgery, pediatrics, radiology, and other journal briefings.
• Expand this to include medical conferences where there are late breaking abstracts.
. Expand this to include medical conferences where there are late breaking abstracts. . The long-term vision is a dependable medical education channel where clinicians can listen and be aware of new literature in an accessible broadcast format while retaining clear links to the original evidence.
Built With
- actions
- api
- codex
- data
- ffmpeg
- github
- gpt-5.6
- kokoro
- next.js
- node.js
- postgresql
- pubmed
- react
- supabase
- tailwind
- tts
- typescript
- vercel
- youtube
Log in or sign up for Devpost to join the conversation.