benzarti-ahmed-yassine/medierp

1. System shape

- MediERP Professional is a desktop ERP for medical practice built in Python with PySide6/PyQt-style UI.

- The runtime is centered around main.py, which boots the app and connects the UI layer to the core/application services.

2. Primary layering

- The repository is organized into four main layers: src/core for application infrastructure, src/views for screens/widgets, src/services for business/AI/automation services, and src/models for domain entities.

- src/utils contains cross-cutting helpers, including Qt compatibility support.

3. Core platform layer

- src/core holds the non-UI backbone: application lifecycle (app.py), database access (database.py), event coordination (events.py), RBAC enforcement (rbac.py), security primitives (security.py), and theming (theme_manager.py, theme_definitions.py).

- This layer is the main boundary between the desktop UI and persistence/security concerns.

4. Role-based UI architecture

- src/views is split by role: admin, doctor, assistant, secretary, and patient.

- Each role has dedicated dashboards and task views, which reflects the product’s RBAC model and keeps the user flows separated by persona.

5. End-to-end clinical workflow

- The README describes a connected workflow: arrival → vitals capture by assistant → doctor consultation with AI support → billing by secretary.

- The views mirror this: assistant screens for patients, inventory, and vital signs; doctor screens for agenda, messages, prescriptions, and patient selection; secretary screens for agenda, billing, and finance.

6. Data model and persistence

- src/models provides shared domain objects such as Patient and User, with base.py as the common model foundation.

- Persistence is backed by SQLite using the database/ folder for schema and migrations, and db/ for local database/document artifacts.

7. Schema evolution and migration strategy

- The database/migrations directory contains multiple SQL migrations, including RBAC, security, messaging, notifications, system config, and feature updates.

- This indicates the database schema is versioned and evolved through scripted SQL rather than an ORM-heavy migration framework.

8. Service layer responsibilities

- src/services contains the operational logic that sits behind the UI: ml_service.py for predictive risk scoring, biometric_service.py and face_service.py for biometric auth, pdf_service.py for document generation, and email_service.py / reminder_service.py / report_service.py for communication and automation.

- These services are the main integration boundary for non-UI capabilities.

9. AI and biometrics as first-class subsystems

- The ML assets in assets/models/ include a trained heart-risk model and scaler, showing the predictive component is embedded locally rather than called from an external API.

- Biometric authentication is also local and integrated into the desktop app, reinforcing the app’s offline-capable, privacy-sensitive architecture.

10. Document and reporting outputs

- Generated artifacts appear under docs/exports/ and db/documents/, including PDF prescriptions/ordonnances.

- This suggests the application produces clinical documents locally and stores them alongside the database files rather than in a remote document service.

11. Configuration and presentation layer

- config/settings.json, .env.example, and QSS/theme files define runtime configuration and visual styling.

- The repo uses a “Full Light” desktop theme, so UI presentation is controlled centrally rather than per-view.

12. Administration and governance

- The admin area covers user management, audit, and system settings, which aligns with the RBAC-heavy design.

- src/core/rbac.py and the admin views form the governance boundary for permissions, account lifecycle, and operational oversight.

13. Testing and operational scripts

- tests/ includes coverage for basic behavior, biometrics, and ML, which reflects the project’s risk areas.

- src/scripts/, scratch/, and standalone helpers like launch_test.py are operational utilities for database initialization, password resets, migrations, and environment checks; they are support tooling, not core runtime subsystems.

14. How to diagram it

- A clean architecture diagram should place the desktop UI/views at the top, fed by core app/security/RBAC/database in the middle, with services branching to ML, biometrics, PDF, email, and reminders, and SQLite + local assets/documents at the bottom as persistence/artifact stores.

- The key business boundary is role-based access: each persona view talks to the same core and service layers but exposes different workflows and datasets.