Orions

Inspiration

I’m a medical student in Mexico. Orions didn’t start as a “cool tech idea.” It started as a gap I lived through.

In traditional medical education, a lot of learning still means static diagrams, endless PDFs, and memorization for the exam. Complex physiological pathways and diagnostic algorithms show up on a slide—and vanish by the next day. I could name concepts. I couldn’t always connect them. And I struggled even more when I had to apply them the way real patients demand: under uncertainty, not as a multiple-choice vignette.

That frustration became the spark. I didn’t just need more content. I needed a place where clinical reasoning could be mapped, explored, and practiced—not only read passively.

I built Orions so students like me wouldn’t have to learn medicine with the same limitations I did: theory in the classroom, silence when it was time to think.

What it does

Orions is an interactive medical learning platform designed to turn passive study into active clinical reasoning.

It helps students:

• Explore medical concepts dynamically instead of only reading static material • Map relationships between pathways, decisions, symptoms, pathologies, and treatments • Manipulate clinical variables (for example in pharmacology and physiology) to see consequences in real time • Study in a way that bridges theory and application—closer to how medicine is actually reasoned through, not just recalled

One example of the computational layer: first-order drug elimination,

C(t) = C₀ e⁻ᵏᵗ

Students can change C₀ and k and watch how plasma concentration C(t) evolves over time—so a formula becomes intuition, not a line to memorize.

The goal is simple: help medical students reason, not only remember.

How we built it

We built Orions as a modern, multi-platform product focused on interactivity and reliability:

• Frontend: ReactFlow powers a node-based interface for building and exploring physiological and diagnostic pathways • Mobile: Flutter makes learning materials accessible on the go—between classes, on the commute, or during short study windows • Backend & architecture: Node.js on the server, with TypeScript end-to-end for strict typing and fewer runtime surprises when modeling dense medical relationships • Computational modules: integrated clinical pharmacology and physiology tools (including dynamic models like first-order elimination) so the UI isn’t just boxes and arrows—it’s cause and effect

Every technical choice had a learning purpose: keep complex maps usable, keep data consistent across platforms, and keep the science interactive.

Challenges we ran into

• Turning clinical decision trees into a fluid UI without overwhelming the student. Medical correctness means nothing if the graph feels like a maze. • Performance at scale: managing state for hundreds of interconnected ReactFlow nodes without freezing the browser required careful optimization and efficient data structures. • Web ↔ mobile consistency: syncing a highly interactive web experience with Flutter demanded a carefully designed unified API so the “same topic” didn’t behave differently by device. • Database modeling of medical knowledge: pathologies, symptoms, and treatments are nuanced and densely related. The schema went through multiple iterations to balance flexibility (the graph can grow) with query speed (the app still feels fast). • Building this as a medical student: limited time, real academic pressure, and the constant question of whether this would actually help someone else—not just look impressive.

Accomplishments that we're proud of

• Turning a personal educational pain point into a working product vision for medical students in Mexico and beyond • Building an interactive system where reasoning can be mapped visually, not only described in text • Integrating computational clinical modules (like first-order elimination) so learners can manipulate variables and see outcomes • Designing a multi-platform architecture (web + mobile + typed backend) that can hold complex medical relationships without collapsing into a demo toy • Staying focused on pedagogy: clarity and clinical usefulness over flashy UI for its own sake

Most of all: building something I wish I had during the hardest parts of my training.

What we learned

This project reinforced how critical robust state management and strict typing are when data structures get complex—and when mistakes confuse learners, not just developers.

Working across Node.js, ReactFlow, and Flutter taught us the real nuance of multi-platform development: it’s not “the same screen twice,” it’s a shared data contract both platforms can trust.

More importantly, we learned that modern software engineering—applied with humility to medical education—can transform passive content into an analytical, engaging experience.

And personally: scarcity in education doesn’t have to be the end of the story. It can be the reason you build.

What's next for Orions

• Deepen the clinical reasoning loop: mentor-style guidance (written and oral), spaced repetition, and deliberate practice—not only visual maps • Expand Mexico / LATAM context (how medicine is practiced here, not only universal textbook theory) • Strengthen simulation and decision-trail feedback so students train for uncertainty, not only recall • Improve performance and authoring tools so more pathways and cases can be created without breaking UX • Validate with real medical students: what improves understanding, retention, and confidence under pressure

Orions’ north star remains the same: not just more medical content—better clinical judgment.

Built With

• bun
• cytoscape.js
• eslint
• express.js
• framermotion
• google
• node.js
• postgresql
• radixui
• react
• react-router
• react19
• supabase
• typescript
• vite
• vitest
• webgl
• websockets
• zod