inkithai/ygc

Purpose and entry points

This is a clinical-report analysis platform: users upload medical documents, receive evidence-backed extraction/review, and ask report-scoped questions. It comprises a React dashboard, a Node.js application API, and a Python RAG/clinical-processing service.

• medreport_dashboard/src/main.jsx

• Backend/index.js

• rag_model/rag_api.py

Web client and user workflow

The Vite/React dashboard owns browser routing, authentication state, API setup, report upload/review, report history, and chat presentation. It is a consumer of backend/service APIs rather than the clinical decision engine. Protected routes and auth context form the frontend access boundary.

• medreport_dashboard/src/Routes.jsx

• medreport_dashboard/src/contexts/AuthContext.jsx

• medreport_dashboard/src/pages/upload-report/index.jsx

Application API and identity boundary

The Node.js backend is the primary application-facing HTTP layer. Route modules separate user, chat, report, and demo capabilities; controllers implement request orchestration. Authentication and security middleware protect API access before controller execution. User/chat/report persistence is modeled separately in MongoDB-oriented models.

• Backend/routes/userRoutes.js

• Backend/routes/chatRoutes.js

• Backend/middleware/auth.js

• Backend/models/reportModel.js

Document ingestion and extraction

The Python service turns source documents into structured clinical data. The extraction subsystem includes preprocessing, OCR, quality assessment, parsing, text fallback, vision fallback, original-file handling, and queued jobs. This is the critical boundary between untrusted PDFs/images and downstream clinical reasoning; extracted evidence and provenance must remain linked to source pages/files.

• rag_model/extraction/parser.py

• rag_model/extraction/ocr.py

• rag_model/extraction/ocr_quality.py

• rag_model/clinical_extraction.py

Clinical reasoning and safety pipeline

Structured facts flow through a clinical pipeline that resolves patient context, builds a patient graph, applies clinical rules/derivations, performs risk classification, and produces citation-aware, policy-constrained answers. Static medical datasets support drug interactions, dose limits, LOINC mapping, trends, and specialist modules. Safety, input-safety, confidence, validation, and self-consistency modules constrain behavior and support abstention/fallbacks rather than unsupported answers.

• rag_model/core/pipeline.py

• rag_model/core/patient_graph.py

• rag_model/core/clinical_review.py

• rag_model/response_validator.py

• rag_model/data/drug_interactions.json

Conversational and report outputs

Chat logic detects intent, builds report/patient context, maintains follow-up state, and selects response builders. Evidence presentation in the UI renders PDF pages and overlays source locations, providing the user-facing provenance boundary. The service can also generate PDF outputs.

• rag_model/chat/context_builder.py

• rag_model/chat/intent_detector.py

• rag_model/chat/response_builders.py

• medreport_dashboard/src/components/evidence/SourcePageViewer.jsx

• rag_model/pdf_generator.py

Storage, services, and deployment

MongoDB is the material persistence layer across the Node backend and Python clinical/history stores. The Python side also integrates an LLM client and MedlinePlus knowledge client; these are external-service boundaries requiring degradation-safe behavior. Docker Compose supports the multi-service deployment, while Oracle deployment uses Compose plus Caddy; the frontend has container and Vercel deployment definitions.

• Backend/db/index.js

• rag_model/clinical_store_mongo.py

• rag_model/core/groq_client.py

• rag_model/medlineplus_client.py

• docker-compose.yml

• deploy/oracle/docker-compose.oracle.yml