The Referral Tracker

Framing the Problem

What is the problem you are trying to solve? Who does it affect?

The Problem We're Fixing: For patients (and their families/guardians) referred for ADHD assessment or support, the current process is often a "black hole." This leads to:

• Anxiety and Uncertainty: Patients don't know whether their referral has been received, is under review, or when to expect an appointment. This prolonged uncertainty is particularly detrimental for individuals with ADHD, who often struggle with executive function challenges like time management and task initiation, amplifying their distress.

• Lack of Transparency: Information is siloed between GPs, schools, and specialist services, leaving patients feeling powerless and uninformed.

• Missed Appointments/Information: Due to poor communication or difficulty tracking details, patients may miss crucial appointments or forget important preparation instructions.

Idea Explanation

What is your idea? How does it fix the problem?

Our Idea: The "Referral Tracker" Patient Dashboard

How Our MVP Fixes the Problem (Focusing on the Patient Dashboard):

Our MVP directly addresses this by providing a user-friendly Patient Dashboard that offers unprecedented transparency and guidance:

1. Real-time Status Visibility:

   • What it is: A clear, visual "progress bar" or timeline showing exactly where the referral is in the process (Submitted, Under Review, Appointment Scheduled, Complete, etc.).

   • How it helps: Reduces anxiety and uncertainty by providing concrete information. Patients can see tangible movement in their referral journey. This is critical for those with ADHD who benefit from clear indicators of progress.

2. Actionable "What's Next?" Guidance:

   • What it is: A prominent section detailing the immediate next step for the patient or what to expect from the service.

   • How it helps: Empowers patients and guides them through the process. It breaks down the journey into manageable steps. For ADHD users, this clarity helps overcome executive function challenges such as task initiation and planning. It tells them exactly what they need to do (or if they just need to wait).

Implementation

How do all the pieces fit together? Does your frontend make requests to your backend? Where does your database fit in?

1. The Patient Dashboard (Frontend):

   • Role: This is the user-facing application (built with React, Tailwind CSS, Typescript, Vite).

   • Function: It displays the referral status, appointment details and notification preferences.

   • How it works: The frontend makes HTTP requests to an API to retrieve the data it needs to display. These requests are like asking for information.
     
     The project consists of a simple web-based dashboard connected to a backend service.

2. For the MVP, the backend is implemented using Spring Boot controllers that serve predefined JSON mock data. This strategy enables rapid development and parallel work on the frontend, providing stable API endpoints with predictable responses without requiring full database integration or complex business logic at this stage.Key Components & Logic:

   1. Spring Boot Controllers:

      • Created REST controller classes (e.g., ReferralController.java).

      • These controllers expose API endpoints (e.g., /api/referrals/...).

      • They handle incoming HTTP requests (GET, POST) from the frontend.

      • For the MVP, these controllers do not perform database queries.

3. No Persistent Storage (For MVP):

   • In this mock MVP setup, there is no active connection to a persistent database, such as PostgreSQL or H2, for data storage at runtime. Data does not persist between application restarts. The focus is on simulating the API behaviour and response structures.

In essence, the backend logic for the MVP focuses on defining API endpoints and intelligent mock data serving, rather than on complex data processing or persistence. This allows us to quickly showcase a functional patient dashboard interacting with "real" APIs.

Project Technology Stack

The project codebase was composed with the following list of technologies:

Challenges

What did you struggle with? How did you overcome it?

Struggle 1: Balancing Mock API Realism with MVP Scope

• The Challenge: How do we make our mock data and API responses feel real enough to be useful for frontend development, without over-engineering the mock logic? For example, if the consent API is called, how does that affect a subsequent GET request for referral status? If we don't simulate this link, the frontend might build logic that breaks later.

• How We Overcame It:

  • Prioritised Key State Transitions: We focused on mocking the critical transitions. For instance, the consent API must affect the status seen by the referral GET API. If the API returns progress stages, we ensure the mock data for later stages reflects that consent has been given.

  • Simple State Management in Mock Logic: Within our mock Spring Boot controllers or mock API tool, we implemented a very basic "state" for a given referral ID. When consent is posted, we could add a flag to that referral's mock data that the GET endpoint uses. This is a lightweight way to simulate persistence.

Struggle 2: What to Build vs. What Can Be Built

• The Challenge: When faced with a broad problem (like the NHS referral black hole) and limited time (a hackathon), it's incredibly easy to get overwhelmed by the sheer number of potential features and ideal end-states. The temptation is to try and solve everything, which inevitably leads to building very little. For our project, we could have envisioned full EMR integration, AI-driven triage, patient education modules, SMS reminders for every stage, etc.

• How We Overcame It:

  • Strong MVP Focus: The primary strategy was ruthlessly defining the MVP. We asked: "What is the absolute minimum set of features that demonstrates a core benefit and addresses the main pain point?" For us, that became the Patient Dashboard with its key components: visual status, "What's Next," and appointment details.

  • Persona-Driven Prioritisation: What feature would help the user to understand their referral status or prepare for an appointment? It was deprioritised for the MVP.

  • Mock API as Scope Constraint: The decision to use mock APIs for the MVP was a strategic scope limiter. It meant we didn't need to build out complex database schemas, authentication, or real-time services for the hackathon's core showcase. This freed up mental bandwidth to focus on the frontend/API contract definition.

  • Defined "Out of Scope": Explicitly stating what we weren't building (e.g., full EMR integration, complex AI triage) helped maintain focus by providing clear boundaries.

Accomplishments

What did you learn? What did you accomplish?

In essence, our MVP provides a crucial piece of the puzzle: transparency and actionable guidance for patients navigating the often-opaque ADHD referral process, specifically designed to mitigate challenges faced by individuals with ADHD.

We've used Spring Boot controllers serving mock JSON data to power these features. This allows us to:

• Showcase a functional frontend dashboard immediately.

• Demonstrate the essential API contracts that a real backend would use.

• Prioritise the patient experience over complex backend infrastructure for the hackathon.

Next Steps

What are the next steps for your project? How can you improve it?

Future Vision (Beyond MVP): While the MVP is focused on the dashboard, the underlying structure (Spring Boot) and our defined APIs lay the groundwork for:

• Real-time Data Integration: Connecting to actual NHS systems for automated status updates.

• Advanced Notifications: More sophisticated reminder systems tailored to ADHD (e.g., multi-channel, customizable timing).

• Broader Stakeholder Access: Dashboards for GPs and administrators.

• Personalised Content: Linking to ADHD-specific educational resources based on referral stage.
  
  The next step would be integrating the tracker with real referral management systems used by clinics and healthcare providers. This would automatically reflect referral status updates in the dashboard.