CuraLink

One Platform, From Care to Class

Comment

Inspiration

When a student gets sick, the illness is rarely the hardest part, the logistics are. You're trying to find a clinic appointment near campus that doesn't collide with a lecture, figure out which classes you'll miss, track down the right professor to email, and get a legitimate absence note from a doctor, all while feeling terrible. That whole process is scattered across calendars, email threads, and clinic portals, and none of it talks to each other.

We also kept running into a specific failure mode in "health tech": tools that quietly overstep. They start acting like they can diagnose you, or they auto-generate "excuse notes" that no real clinician ever signed. We wanted to build the opposite: something that does the tedious coordination work while keeping every medical and authority decision firmly in human hands. A student describes what's going on, CuraLink handles the scheduling and paperwork prep, and a clinician decides what gets documented and signed.

What it does

CuraLink automates the campus healthcare system through two main features: accessible, real-time voice AI and computer vision that helps students communicate what they’re experiencing.

Voice AI powered by Cartesia Students can talk to CuraLink naturally instead of having to type everything out, making healthcare information more accessible when they are sick, stressed, or simply prefer speaking. Using Cartesia for speech processing, CuraLink supports spoken conversations with live audio feedback, transcripts, and interruption controls. Students can ask questions about campus healthcare resources and appointment procedures and get guidance without having to dig through confusing websites.

Multimodal Vision-Language Model for Visual Context Students can optionally upload photos to provide visual context about what they are experiencing. This gives students another way to communicate concerns beyond text alone. Images are handled as supporting context, not as a diagnosis, and students stay in control of what information they share with their clinician.

Scheduling Around Real Student Life Students can import their class schedules and find appointment options that work around classes and other commitments. CuraLink uses deterministic scheduling rules to account for conflicts and travel buffers, with clear explanations for why a time may or may not work.

A Connected Student and Clinician Experience Students can prepare a structured intake summary and choose what to share with their assigned clinician. Clinicians can review the information, make their own medical decisions, and create and sign documentation when appropriate. If an absence notice is needed, CuraLink helps communicate the minimum necessary information without exposing private medical details to professors.

Built Around Trust CuraLink keeps AI within clear boundaries. It does not diagnose conditions, make medical decisions, independently sign documents, or guarantee that an absence will be excused. Students control their shared information, and clinicians remain responsible for clinical decisions.

Built and Hosted with Vercel and Convex CuraLink brings these experiences together in a connected application, with Convex supporting the app's backend infrastructure and data flow and Vercel supporting the frontend.

How we built it

Ideation and planning with Notability Before writing code, we used Notability to explore different ideas and decide which problem we wanted to solve. We used Pro features such as split-screen workspaces, sticky notes, shapes, voice memos, and the infinite canvas to brainstorm ideas and map out how each product might work.

We gave each idea its own page, worked through the pros and cons, and compared its potential impact, feasibility, and safety considerations. CuraLink stood out because it addressed a problem students could genuinely experience while giving us an opportunity to build something useful without overstepping into medical decision-making.

Notability then became our planning hub. We mapped the student and clinician workflows, defined permissions and safety boundaries, and organized our build into phases. We also kept a running testing journal documenting what we tested, what broke, and what we changed. This gave us a way to trace our design and engineering decisions back to the problems that inspired them.

From sketches to a working interface with Figma Make Once we had a clear plan, we sketched our initial wireframes in Notability and brought them into Figma. We used Figma Make to turn our descriptions and rough ideas into a polished starting point for the student and clinician interfaces.

One of our favorite parts of the process was seeing our ideas become interactive layouts so quickly. Instead of spending hours getting every spacing decision right from scratch, we could focus on the actual experience: how students move from asking for help to planning around classes, and how clinicians review information and approve documentation.

We iterated on the generated layouts and used the resulting design as the foundation for our frontend. The combination of Notability for early thinking and Figma Make for rapid prototyping helped us move from brainstorming to a working application while keeping the product experience consistent.

The stack Frontend: React 19, Vite 8, TypeScript, Tailwind CSS v4, React Router, and React Query. Backend: FastAPI, Python, Pydantic v2, SQLAlchemy, and SQLite in demo mode.

AI assistant: Anthropic Claude with a restricted set of read-only tools. The assistant can inspect calendar information and appointment slots and propose intake fields, but it cannot book, send, sign, or approve anything. If an API key is unavailable, a rule-based assistant provides a fallback with the same safety boundaries.

Voice: Cartesia streaming speech-to-text and text-to-speech routed through the backend, keeping API credentials out of the browser. We implemented interruption support and stale-audio rejection, with browser speech and text fallbacks.

Scheduling: A deterministic appointment-ranking engine with hard constraints for class conflicts, travel buffers, and personal calendar blocks. Recommendations are explainable and never generated by the language model.

Documents: Immutable PDFs with SHA-256 versioning. Signatures are encrypted at rest and explicitly marked as simulated and invalid for real-world use in the demo.

Security and trust by design We wanted safety to be part of the architecture rather than something we added at the end. The client cannot choose its own role. Server routes resolve the user through an HttpOnly session cookie. State-changing requests require CSRF protection, and the voice WebSocket validates its origin. Sending a document requires student consent, the latest signed version, a matching document hash, unchanged approved recipients, and verified allowlisted email addresses. Audit events exclude symptoms, transcripts, and document contents. The AI assistant has no tools for signing documents, sending emails, or approving clinical decisions.

Testing and what changed We treated testing as part of building the product, not something to squeeze in at the end. We documented each phase in our Notability testing journal and used what we found to improve the implementation.

Challenges we ran into

Keeping AI within its limits. One of our biggest challenges was making sure the assistant could help with coordination without taking over decisions that belong to a clinician. We addressed this by restricting its server-side tools and enforcing permissions throughout the workflow.

Handling real-world calendars. Calendar exports are more complicated than they first appear. Recurring events, cancellations, moved classes, time zones, and missing instructor information all needed explicit handling.

Making voice conversations feel natural. Supporting interruptions meant more than adding a microphone button. We had to stop playback immediately, reject outdated audio, and keep conversation context consistent when switching between voice and text.

Connecting the frontend and backend. Building both sides in parallel introduced the usual cross-origin, schema mismatch, and asynchronous timing issues. We worked through those while keeping our test suite and phase journal up to date.

Accomplishments that we're proud of

  • An end-to-end coordination workflow connecting text and voice assistance, calendar import, appointment recommendations, consented information sharing, clinician-reviewed documentation, and controlled delivery.
  • A clinician workflow where the authority to document and sign an absence stays with the clinician at every step.
  • A scheduling engine that explains its recommendations instead of relying on AI-generated availability.
  • An accessible voice experience with interruption support and text fallbacks.
  • A polished interface developed from Notability sketches through Figma Make into a working application.
  • A documented, test-driven development process that helped us make deliberate changes as we discovered edge cases.

What we learned

Trust is part of the product. CuraLink needs to be honest about what it knows, what it can do, and what remains a human decision. Labeling demo integrations, preserving the student's original words, tracking the source of information, and avoiding unsupported medical claims made the system more useful and safer.

Health-related AI needs more than a good prompt. It needs carefully limited permissions, predictable workflows, and clear boundaries around what the model can and cannot do.

Accessibility has to be considered from the start. Voice interaction can reduce barriers for some students, but it should never be the only way to use the product. Transcripts, text controls, and alternative input methods are essential parts of the experience.

Our tools shaped how we built. Notability helped us think through the problem and keep track of our decisions. Figma Make helped us turn those decisions into an interface quickly. Together, they let us spend more of our time refining the actual workflow instead of getting stuck at the blank-page stage.

What's next for CuraLink

Our next steps include testing with real UniTime exports and read-only calendar subscriptions, exploring authorized clinic scheduling integrations, and integrating a compliant electronic signature service. We also want to add consent-controlled email delivery through Microsoft Graph, improve safety escalation with clinician-reviewed validation, and build academic catch-up planning from exported class notes. Before using real patient information, we would also need a thorough review of applicable HIPAA and FERPA requirements, key management, access controls, and data retention practices.

Built With

Share this project:

Updates

Submission history