MediTriage — AI-Powered Pre-Consultation Triage System

Team

• E/22/044, D.M.N.N. Bandara, e22044@eng.pdn.ac.lk
• E/22/102, A.K. Gamage, e22102@eng.pdn.ac.lk
• E/22/010, A.A.D.I. Adikari, e22010@eng.pdn.ac.lk
• E/22/211, H.M. Liyanage, e22211@eng.pdn.ac.lk

Table of Contents

1. Introduction
2. Solution Architecture
3. Software Designs
4. Testing
5. Conclusion
6. Links

Introduction

Outpatient Departments (OPD) and Wards face significant bottlenecks because doctors spend the initial 5–10 minutes of every consultation gathering basic patient history. This reduces the time available for actual diagnosis and treatment, increases patient waiting times, and places unnecessary cognitive load on clinical staff.

MediTriage is an AI-powered, staff-assisted pre-consultation tool designed to streamline the clinical intake process in hospital settings. It empowers hospital staff (e.g., nurses) to conduct structured patient interviews efficiently using an AI-guided conversational interface. The system allows the nurse to capture and verify patient responses before the conversation is automatically converted into a draft SOAP Note (Subjective, Objective, Assessment, Plan) — a structured medical summary ready for the attending doctor.

Key Capabilities

• 🤖 Conversational AI Triage — A LangChain-powered interview engine guides the nurse through a clinically structured question flow, adapting dynamically to patient responses.
• 🔒 Privacy-First Architecture — Patient Identifiable Information (PII) is scrubbed locally using a lightweight Llama 3.2 model (via Ollama) before any data is sent to a cloud AI provider, ensuring patient data never leaves the facility unprotected.
• 📝 Automated SOAP Note Generation — Cloud AI synthesises the scrubbed conversation into a structured clinical note for doctor review.
• 💬 Real-Time MDT Conferences — Secure real-time collaboration rooms for Multi-Disciplinary Teams (MDT) of doctors to discuss clinical cases, share encrypted messages, and collaborate on attachments.
• 👥 Role-Based Access Control — Dedicated portals and permissions for Nurses, Doctors, and Administrators.

Solution Architecture

The system follows a layered architecture separating human interaction, frontend presentation, backend processing, and data/AI services.

Layer Overview

Data Flow

Triage Pipeline Data Flow

1. The Nurse admits a patient and begins an AI-guided interview in the Nurse App.
2. Text input is sent to the FastAPI Backend via the API Gateway.
3. The Triage Engine Orchestrator in the AI Pipeline passes the raw conversation text to the PII Scrubber to sanitize patient identifiable information using local Ollama (Llama 3.2 1B).
4. The sanitized query is forwarded to the Cloud LLM (DeepSeek or OpenAI) for clinical reasoning.
5. The AI response is returned to the nurse for verification and stored in PostgreSQL.
6. On completion, a draft SOAP Note is generated and surfaced in the Doctor Portal for review and annotation.

MDT Conferences Data Flow

1. A Doctor reviews case records in the Doctor Portal and initiates an MDT Consultation Room for collaborative discussion, specifying a title and selecting other attending doctors.
2. The room creation request is sent via REST API to the API Gateway, where the Consultation Service creates the room in the Data Layer (PostgreSQL).
3. Doctors join the conference, establishing real-time communication channels through the Websocket Manager (wss://.../ws).
4. Messages typed in the consultation room are encrypted dynamically using AES-256 (Fernet) via the Encryption Service before database insertion.
5. Collaborative attachments uploaded by doctors are encrypted by the Encryption Service and stored securely in the file storage data layer, with references stored in PostgreSQL.
6. The Websocket Manager broadcasts new messages and attachment notifications in real time to all connected members in the room.

Software Designs

Technology Stack

Backend (meditriage-be)

Frontend (meditriage-fe)

Backend Project Structure

meditriage-be/
├── app/
│   ├── api/v1/
│   │   ├── controllers/       # Route handlers (auth, patients, triage, users, consultations)
│   │   └── dependencies.py    # RBAC & JWT injection
│   ├── core/                  # Config, security, logging, connection_manager.py
│   ├── db/                    # SQLAlchemy session
│   ├── models/                # ORM models (Patient, User, Encounter, consultation, …)
│   ├── repositories/          # Data access layer (consultation_repo, etc.)
│   ├── schemas/               # Pydantic request/response schemas
│   ├── services/
│   │   ├── llm/               # LangChain chains, prompts, parser, and adapters
│   │   ├── triage_engine.py   # Core triage orchestration
│   │   ├── consultation_service.py # MDT room business logic
│   │   ├── encryption_service.py # AES-256 encryption helper
│   │   └── …                  # Auth, patient, encounter services
│   └── main.py
├── alembic/                   # Database migrations
├── tests/                     # Pytest test suite
└── requirements.txt

LLM Adapter Design (Adapter Pattern)

To prevent vendor lock-in and allow seamless switching between different cloud AI models, the backend implements the Adapter Pattern at the LLM integration layer.

Key Components:

• BaseReasoningProvider (base_provider.py): An abstract base class defining a unified interface (generate_response, generate_structured_output) for all reasoning providers.
• Provider Implementations:
  • DeepSeekProvider (deepseek_provider.py): Integrates DeepSeek’s model through LangChain’s OpenAI compatibility interface.
  • OpenAIProvider (openai_provider.py): Direct OpenAI integration through LangChain.
  • ClaudeProvider / GeminiProvider: Supported by design via the unified BaseReasoningProvider interface.
• Dynamic Factory Configuration (chain_factory.py): The _create_provider() factory function reads the ACTIVE_LLM setting from the .env configuration file to instantiate the selected provider dynamically.
• Loose Coupling: The TriagePipeline requests the active provider from the factory and invokes methods declared in the base interface, decoupling core orchestration logic from vendor-specific libraries.

API Endpoints Summary

Testing

The project uses Pytest for backend testing, with the test suite located in meditriage-be/tests/.

Test Layers

Conclusion

MediTriage demonstrates how AI-assisted clinical workflows can meaningfully reduce the administrative burden on healthcare professionals. By automating the initial patient history-gathering process through a conversational AI interface — while keeping patient privacy at the forefront through local PII scrubbing — the system frees doctors to focus on diagnosis and treatment rather than data collection.

Key outcomes of the project:

• A fully functional triage pipeline from patient admission to SOAP note delivery, validated end-to-end.
• A secure, real-time collaboration environment (MDT Conferences) allowing Multi-Disciplinary Teams of doctors to collaborate on cases, share encrypted messages, and upload sensitive medical files.
• A privacy-preserving AI architecture where sensitive data is sanitised before any cloud interaction, and end-to-end AES-256 encryption is applied to clinical consultation data.
• A role-aware web application that adapts its interface and permissions to the specific needs of Nurses, Doctors, and Administrators.
• A modular, maintainable codebase built on industry-standard frameworks (FastAPI, React, LangChain, PostgreSQL) that can be extended to support additional clinical workflows.

Future work could include integration with hospital information systems (HIS/EMR), support for multilingual patient interaction, and deployment within a containerised (Docker/Kubernetes) hospital infrastructure.

Links

• Project Repository
• Project Page
• Department of Computer Engineering
• University of Peradeniya