kabiththananparan/meditimeline-ai

Purpose and current entry point

MediTimeline AI is intended to ingest medical-record documents and build structured patient timelines for prescription, allergy, lab-trend, and clinical-reasoning analysis. The implemented repository is currently backend-focused; no React frontend, SQLite, ChromaDB, Groq integration, or dashboard source is present in the tree.

The FastAPI application entry point is backend/app/main.py. Upload handling begins at backend/app/api/upload.py.

API boundary and upload contract

backend/app/api/upload.py defines the HTTP-facing upload route(s), separating client file submission from document-processing logic. Request/response models are centralized in backend/app/schemas/upload_schema.py, providing the contract boundary between API consumers and internal services.

Flow: client uploads a document → API validates/normalizes through schema and route logic → service layer receives the file for processing.

Upload orchestration

backend/app/services/upload_service.py is the application service coordinating uploaded-file handling. It forms the primary control-flow boundary between transport concerns in api/ and document extraction in services/pdf_parser.py.

This layer is the natural future integration point for persistence, patient/document identifiers, asynchronous jobs, and downstream timeline/analysis stages described in the README.

PDF extraction stage

backend/app/services/pdf_parser.py is the document-ingestion/extraction component. It converts uploaded PDF content into text or parsed material usable by later structured extraction.

The implemented pipeline therefore currently reaches: Upload → file handling → PDF parsing. The README’s later stages—AI structured extraction, timeline generation, interaction checking, lab analysis, and clinical reasoning—are product-intended stages but do not have corresponding source modules in this tree.

Application runtime and cross-cutting configuration

The backend uses Python/FastAPI, with runtime dependencies declared in backend/requirements.txt. Application bootstrap is located at backend/app/main.py.

Cross-cutting settings and logging are isolated from business services:

• backend/app/core/config.py

• backend/app/core/logging.py

These modules are the expected boundaries for environment-provided settings (such as future Groq credentials, storage locations, and database URLs) and operational observability.

Data and external-service posture

Sample/source medical-record organization exists under data/DataSet YGC26/, grouped by patient and year, for example:

• data/DataSet YGC26/Patient x/Year 1

• data/DataSet YGC26/Patient y/Year 3

The README names Groq, SQLite, and ChromaDB as planned platform dependencies, but the visible code tree contains no adapters, migrations, vector-store clients, or LLM client modules. Treat them as intended infrastructure rather than implemented runtime dependencies.

Key architectural gap

The repository has a clean initial layering—API → schema/service → parser—with configuration and logging outside the request pipeline. To realize the stated product architecture, add explicit bounded components after parsing: normalized medical-record extraction, durable patient/document storage, timeline assembly, medication/allergy/lab analysis, and a reasoning/query API. Keep these behind service interfaces rather than embedding clinical or AI logic in backend/app/api/upload.py.