MediscanAI

Explainable AI triage that adapts to symptoms, shows its reasoning, and keeps doctors in the loop.

Comment

MediscanAI

Inspiration

When people experience unfamiliar symptoms, their first question is usually not “What is the diagnosis?” It is:

What should I do next?

Many symptom-checking tools rely on long, static forms or return a result without explaining how it was reached. In healthcare, an unexplained prediction can create anxiety and should not become the final decision.

I built MediscanAI to make the first step more structured and responsible. The system combines adaptive questioning, explainable machine learning, safety guidance, and physician review in one workflow.

The goal is not to replace doctors. The goal is to help patients organize their symptoms and help clinicians make the next human decision better informed.

What it does

MediscanAI is an explainable clinical decision-support and disease-detection prototype.

For patients

  • Creates a secure patient account
  • Asks adaptive follow-up questions based on previous responses
  • Returns up to three possible conditions with confidence scores
  • Shows the symptoms and factors that contributed to the result
  • Provides condition information and precaution guidance
  • Displays a patient health report and diagnosis history
  • Shows clear medical disclaimers and safety boundaries

For doctors

  • Provides a protected patient-submission queue
  • Shows reported symptoms and AI-generated reasoning
  • Allows a doctor to approve, correct, or override a result
  • Stores review notes and case status
  • Provides review and triage analytics

The important difference is that MediscanAI does not stop at a model prediction. It connects the prediction to a human review workflow and an audit trail.

How we built it

MediscanAI is built as a modular full-stack application:

Patient or doctor browser
          |
    Next.js frontend
          |
    Express REST API
       /          \
PostgreSQL     Flask AI engine
                    |
          Random Forest + explanation layer

Frontend

The patient and doctor interfaces are built with Next.js 16 and React 19. The frontend includes the landing page, registration and login, adaptive questionnaire, diagnosis report, health report, doctor dashboard, submissions queue, and analytics screens.

Backend

The Node.js and Express API controls authentication, role-based access, request validation, questionnaire sessions, diagnosis persistence, doctor feedback, analytics, and audit logging.

AI engine

The AI engine is a Python Flask microservice using scikit-learn. It uses a Random Forest classifier trained on:

  • 4,920 training records
  • 132 symptom features
  • 41 disease classes
  • 42 bundled test cases

The service returns ranked conditions, confidence scores, clinical descriptions, precautions, and human-readable reasoning.

The current explanation layer uses severity-weighted symptom feature contributions and a clinical knowledge base. It is intentionally described as feature contribution analysis rather than claiming validated SHAP attribution.

Data and security

PostgreSQL stores questionnaire sessions, diagnoses, feedback, user accounts, and audit events. The application includes:

  • bcrypt password hashing;
  • JWT sessions using HTTP-only cookies;
  • AES-256-GCM encryption for selected sensitive fields;
  • role-based access control;
  • Zod request validation;
  • Helmet security headers;
  • CORS restrictions;
  • API rate limiting; and
  • protected audit logs.

The project can run locally with Docker Compose and includes deployment configuration for Render and Vercel.

Challenges we ran into

Balancing usefulness and safety

Healthcare AI should not present a prediction as certainty. We had to design the interface so that the result is useful while still making the limitations and medical disclaimer visible.

Connecting different technologies

The project combines a Next.js frontend, an Express backend, a Python Flask service, and PostgreSQL. Keeping communication, environment variables, authentication, and error handling consistent across these services required careful separation of responsibilities.

Making model output understandable

A raw condition label is not enough for a patient or doctor. We added symptom-level contribution information, clinical descriptions, precautions, and a structured report so users can understand the context around the output.

Designing the physician workflow

The project needed to go beyond a patient-facing prediction screen. We built a doctor queue and feedback system so that clinicians can review, approve, correct, or override the AI result.

Protecting demo data

Because this is a healthcare project, the demo and QA process use synthetic accounts and data. Screenshots and recordings must not expose passwords, tokens, cookies, database snapshots, or real patient information.

Accomplishments that we're proud of

  • Built a complete patient-to-doctor workflow instead of only a machine-learning endpoint.
  • Implemented adaptive symptom questioning to reduce unnecessary form length.
  • Added top-three differential results instead of a single unexplained label.
  • Added human-readable symptom contribution analysis and clinical context.
  • Built a physician review queue with approve, correct, and override actions.
  • Added patient reports, doctor analytics, and case-history views.
  • Implemented authentication, role separation, encryption, validation, rate limiting, and audit logging.
  • Created a modular architecture that can run locally with Docker Compose.
  • Added responsive desktop and mobile interfaces.
  • Created a repeatable browser evidence pack for the main user journeys.
  • Verified the backend with 9 passing Jest tests.
  • Verified the AI engine with 3 passing Python tests.
  • Verified that the Next.js application builds successfully for production.

The accomplishment I value most is that the project treats explainability and human review as part of the product design, not as features added after the model.

What we learned

We learned that a strong AI product is more than its model accuracy. In a sensitive domain, the surrounding workflow is equally important.

During the project, we learned to:

  • communicate uncertainty instead of overpromising;
  • separate model inference from application workflow;
  • design role boundaries for patients and clinicians;
  • protect sensitive fields at the application layer;
  • build auditability into important actions;
  • test the actual user journey instead of only testing individual functions;
  • and document limitations honestly.

We also learned that explainability has to be designed for the person reading it. Technical model details are useful, but patients and clinicians need clear answers to practical questions such as:

  • What influenced this result?
  • What should I be cautious about?
  • What can a doctor review?
  • What happens if the model is wrong?

What's next for MediscanAI

The next version will focus on validating the system beyond the prototype:

  1. Externally validate and calibrate model probabilities.
  2. Measure clinician agreement, review time, and false-negative risk.
  3. Evaluate performance across different demographic and symptom groups.
  4. Add multilingual and accessibility-first experiences.
  5. Add secure referral and follow-up workflows.
  6. Introduce versioned, clinician-approved model retraining.
  7. Add stronger dataset governance and monitoring.
  8. Complete formal privacy, security, clinical, and regulatory reviews before any real-world use.

MediscanAI is built around one principle:

AI should be adaptive enough to reduce friction, explainable enough to be questioned, and connected to a human workflow before action is taken.

Medical disclaimer: MediscanAI is an academic prototype for triage assistance and demonstration. It is not a diagnosis, treatment service, emergency service, or replacement for a qualified healthcare professional.

Built With

Share this project:

Updates

Submission history