Home Page
Specialist Patient Portal
Doctor Patient Referral Portal
Specialist Dashboard

Inspiration

We started with a question: where could better access to care make the biggest difference? We kept coming back to patients in health deserts, where seeing the right specialist can mean a long drive, time off work, and expenses that make treatment harder to pursue.

The research helped put that problem into perspective:

The National Rural Health Association cites 30 specialists per 100,000 people in rural communities, compared with 263 in urban areas—nearly nine times the specialist density in cities. Source
A 2023 report from the National Association of Community Health Centers found that more than 100 million Americans faced barriers to accessing primary care. Source

We focused on one part of that problem: helping patients reach specialist expertise beyond their local area.

Impiricus already reports a network of more than one million opted-in healthcare professionals. That gave us a starting point for Nexus: a proposed extension of that network that coordinates virtual specialist group care for underserved patients. Source

What it does

Nexus gives referring doctors and specialists separate workspaces built around their responsibilities.

A doctor makes the referral. They enter the patient’s condition, stage of care, availability, language, and access needs.
Nexus handles group placement. The system checks for a compatible group with available capacity. Patients who cannot be placed remain waiting or are flagged for review.
The specialist receives the update. Their dashboard shows new participants, group rosters, upcoming meetings, and preparation tasks.
The referring doctor follows up. The prototype includes example meeting summaries, review checklists, and a conversation interface to show how follow-up would fit into the workflow.

Our proposed care model combines shared education with a private one-on-one consultation. A specialist could explain common information once, then discuss each patient’s circumstances individually.

We also developed a proposed business model in which regional health systems purchase the coordination service through Impiricus and fund specialist participation, with patient costs explained before enrollment.

How we built it

We built the frontend with React and TypeScript, using Vite, Tailwind CSS, custom CSS, and Lucide icons. The interface uses separate doctor and specialist dashboards, with clear next actions and a responsive layout.

A Node.js backend handles referrals through our own HTTP API. The matching engine uses explicit rules for condition, stage of care, language, availability, consent, and group capacity. Referrals enter a short processing state before the system assigns a group or identifies what needs attention.

We used Server-Sent Events to send updates to connected browsers. A referral submitted on one laptop can appear in the specialist’s dashboard on another without refreshing. Shared referral data persists in a JSON file, while review checklists and conversation notes are stored locally in the browser.

The site runs on a Linux server, with systemd managing the application and Tailscale Funnel providing public HTTPS access. We added automated tests for matching, capacity limits, persistence, retries, and reset behavior.

For the hackathon, we used sample patients, scheduled meetings, and meeting summaries. Live video, AI transcription, clinical orders, and appointment booking remain planned integrations.

We also created a minimal pitch deck and an animated pitch film built in JavaScript on an HTML canvas.

Challenges we ran into

Our biggest challenge came before the code. We needed to understand how Impiricus works, who its customers are, and where a new service could fit. We spent much of the first day researching those questions.

By the time we started coding, we were roughly 24 hours into the hackathon. That left a compressed build window and made scope decisions especially important.

Technically, the biggest challenge was keeping both workspaces consistent across devices. We had to account for repeated submissions, disconnected browsers, full groups, and patients who needed more information before placement.

The product questions were just as important. We had to think through what belongs in a group conversation, what needs to stay private, who pays for the service, and how a busy doctor can make a referral without taking on another scheduling job.

What we learned

Understanding the business changes what you build. Research helped us identify a specific role for Nexus within the Impiricus model.
The handoff matters. A referral is only useful if someone can see what happens next and take responsibility for it.
Matching needs more than a diagnosis. Stage of care, language, availability, and individual needs all affect whether a group makes sense.
Reliable behavior makes the idea easier to explain. Seeing a referral arrive on a second screen communicates the workflow immediately.
Consent and privacy shape the product. They affect what information is collected, who can see it, and how group care should work.

What’s next for Nexus

We want to validate the workflow with one specialty and a small group of referring doctors before expanding.

Before a clinical pilot, we would add authentication, clinician permissions, appropriate privacy controls, and integrations for video visits and clinical records. We would also explore transcription and summaries that clinicians review before sharing, alongside ordering and scheduling workflows.

The pilot would measure time to the first specialist visit, patient satisfaction, specialist workload, and follow-through on next steps. Those results would guide whether and how Nexus expands to more specialties and regions.