Retour à l'accueil

Notes de version

Suivi mensuel détaillé des modifications, de l'infrastructure et de l'état d'avancement du projet Prémedica.

Statuts utilisateurs (pending/validated/suspended), logging superadmin détaillé, support PostgreSQL staging/prod, fix authentification 302, module HL7 et Healthcare GCP, sandbox IA et clés API déplacés vers superadmin, relance questionnaires et transfert RDV, QR staging. Nettoyage projet, documentation centralisée, CI/CD staging opérationnel.

Fonctionnel – Utilisateurs et authentification

  • Statuts utilisateurs : pending, validated, suspended. Workflow : nouvel utilisateur → pending ; validation admin → validated ; suspension possible → suspended. Migration tenant add_status_to_users_table (enum status).
  • Pages dédiées : /dashboard/verify (en attente), /dashboard/suspended (suspendu). Redirections dans auth.global.ts selon statut. Vérification statut avant accès dashboard.
  • Emails : account-pending (création), account-validated (validation), account-suspended (suspension). Templates api/resources/views/emails/. Commande FixUserStatuses pour migrer les utilisateurs existants vers validated.
  • Google OAuth, forgot/reset password, remember me. CallbackController, routes /auth/redirect/google, /auth/callback. Headers API : Accept et Content-Type application/json, X-Requested-With. Gestion 302 dans http-client.
  • Soft delete utilisateurs avec email ; restauration (UserController::restore). Profil : photo (profile_photo_url), changement MDP. Admin : génération MDP, copie presse-papiers (InputGroupInput).
  • Fix connexion 302 : requêtes vers port Nuxt au lieu de l'API. nuxt.config runtimeConfig.public.apiUrl ; useRuntimeConfig() dans http-client et useAuth. SANCTUM_STATEFUL_DOMAINS (workflows, docker-compose). Dockerfile.dev dédié (web). User is_superadmin dans fillable ; migration user_id nullable (Laravel 11+).

Fonctionnel – Superadmin, logs, RGPD

  • Logging superadmin : changements de statut (activation/désactivation), modifications prénom/nom/email/tél avec avant→après, changements de rôles, reset MDP. LogResource : colonne Utilisateur « SuperAdmin » + email ; badges par type (created, updated, deleted, soft_delete, restore).
  • Migration make_user_id_nullable_in_logs_table (tenant) : user_id nullable pour actions superadmin. Loggable : pas de double log sur User ; recordSuperAdminLog (UserController) crée le log avec user_id null et information.modified_by_superadmin.
  • RGPD : route POST /api/tenant/patients/demand (PatientDemandController). Page /patient/data-removal. Traitement admin /admin/patients/demand. PatientDemandService, emails. Table patient_demands (migration create_patient_demands_table).

Fonctionnel – Questionnaires, rendez-vous, IA

  • Fichiers : route files.download (signed), prévisualisation. QuestionnaireInstanceService : getInformationFiles (URL::temporarySignedRoute). Emails patient : plusieurs fichiers d'info, synchro infos RDV.
  • Questionnaires : libellés, navigation, options (focus, UX), duplication (POST templates/duplicate). Agenda : onglet calendrier, filtre médecin. Réponses : fusion response / patient response sur une page.
  • Sandbox IA/SNOMED : validation manuelle expressions, mode lecture seule depuis historique. Historique : extractions validées uniquement ; termes refusés en rouge, raison rejet. Délai suppression non validées 24h→7j. MedicalReport draft : mise à jour existant, chargement expressions batches non validés.
  • Sandbox SNOMED/IA et clés API IA déplacés admin → superadmin. SuperAdminAiApiKey (base centrale), getActiveKeyForContext(). SnomedBatchController, AiController : init tenant pour superadmin. Modale SNOMED : tableau expressions ; extraction + validation clés.
  • Relance questionnaire : modal message personnalisé, sendAppointmentInvite (QuestionnaireInstanceController). Transfert RDV : POST appointments/transfer (AppointmentController). Filtres admin RDV (statut, source). Resend verification email (UserController).
  • QR code : QuestionnaireInstanceService.generateAppointmentLink utilise config app.frontend_url. FRONTEND_URL=https://staging.premedica.care dans deploy-staging (set-env-vars API Cloud Run). Liens QR et emails pointent vers staging.

Healthcare API et HL7

  • Module HL7 : page /dashboard/superadmin/hl7-test. Index (list paginée), show, upload (fichier .hl7), download (fichier), destroy. SuperAdminHl7TestController. Routes GET/POST/DELETE /api/superadmin/hl7-test. UI : bouton exemple HL7, modale visu HL7/JSON, téléchargement fichier ; patient_id null ou "NULL" géré.
  • HealthcareService : uploadMessage (normalisation \r\n/\n → \r ; labels map string→string), download. Hl7Message : gcp_message_id, gcp_store_id, message_type, patient_id, related_type/related_id nullables. Migrations create_hl7_messages_table, make_related_fields_nullable. Config api/config/services.php healthcare (project_id, location europe-west3, dataset/store staging-prod).
  • Auth GCP : Cloud Run metadata API ou Fallback Secret Manager (GCP_HEALTHCARE_CREDENTIALS_SECRET). Dev : GOOGLE_APPLICATION_CREDENTIALS, fichier gcp/*.json monté. Scripts grant-healthcare-permissions, add-healthcare-secret, create-hl7-stores (hl7-store-staging, hl7-store-prod), cleanup-hl7-test-resources (test-*), run-tenant-migrations-staging.
  • Tests : SuperAdminHl7TestControllerTest (mock HealthcareService, app()->make), patient_id null/"NULL". Workflow : GCP_HEALTHCARE_CREDENTIALS_SECRET ; corrections noms instance SQL, image Artifact Registry, URL API sans double /api.

Base de données et multi-tenant

  • Multi-SGBD : MySQL (dev), PostgreSQL (staging/prod). config/database.php : default env DB_CONNECTION ; connexions tenant, pgsql_tenant (database dynamique par org). Remplacement 'mysql' → config('database.default') (PersonalAccessToken, SuperAdminSeeder, Loggable, middlewares, services).
  • Cloud SQL : connexion via socket Unix /cloudsql/PROJECT:REGION:INSTANCE. User::getConnectionName() selon driver (tenant vs pgsql_tenant). TenantService, DatabaseService. EnsureDatabaseConnection middleware.
  • Staging : vérification COUNT(organizations) et existence de logs avant seed ; pas de re-seeding si données présentes. Jobs migrate-central-staging, migrate-tenants-staging (--set-cloudsql-instances, tags SHA). QUEUE_CONNECTION redis, CACHE_STORE redis en staging.

Infrastructure – Docker, GCP, CI/CD

  • Docker dev : docker-compose.dev.yml. Services : api (Laravel Sail, PHP 8.4), web (Nuxt Dockerfile.dev, NITRO_PORT 8080), mysql 8.0, redis 7, mailhog, queue-worker (snomed, default). Ports : API 8095, Web 3002, phpMyAdmin 7490, MySQL 3307, Redis 6381, MailHog SMTP 10250, UI 8026. Volumes gcp/ pour credentials Healthcare.
  • GCP staging : projet premedica-prod-2025, région europe-west9. Cloud Run premedica-api-staging, premedica-web-staging. Artifact Registry europe-west9-docker.pkg.dev. Cloud SQL premedica-db-staging (PostgreSQL), Redis. Workflow .github/workflows/deploy-staging.yml : build API (Dockerfile.prod) et Web, push images (tags SHA + latest), déploiement Cloud Run (--no-traffic puis update-traffic), jobs migrate-central-staging, migrate-tenants-staging, seed conditionnel.
  • Domaines : staging.premedica.care (web), api.staging.premedica.care (API). Domain mappings Cloud Run. WIF (Workload Identity Federation), service account github-deployer. Secret Manager : DB_PASSWORD_STAGING, APP_KEY_STAGING, healthcare-service-account-credentials. VPC connector premedica-connector, vpc-access-egress all-traffic. Cloud Run : --set-cloudsql-instances, --min-instances 1, --cpu-boost.
  • Nettoyage projet : doublons supprimés (changelog, security, OAuth, nginx, scripts). Déplacements SETUP_DOMAINS, SETUP_WIF → documentation/deployment ; start-dev, manage-gcp → scripts/. Structure documentation/ centralisée, scripts/ par catégorie.

Migrations (base centrale et tenant)

  • Centrale : add_is_superadmin_to_users_table ; create_organization_user_role_table ; add_status_to_users_table ; add_photo_url_to_users_table ; add_organization_id_to_personal_access_tokens_table ; create_superadmin_ai_api_keys_table.
  • Tenant : add_status_to_users_table ; make_user_id_nullable_in_logs_table ; create_patient_demands_table ; add_has_accepted_terms_to_patients_table ; create_settings_table ; add_questionnaire_instance_id_to_medical_reports_table ; update_logs_table_for_anonymous_actions ; create_hl7_messages_table ; make_related_fields_nullable_in_hl7_messages_table ; add_transfer_log_to_appointments_table. Fix ai_model_configuration (2025_12_16_120001).

Routes API et endpoints clés

  • Superadmin : /api/superadmin/dashboard/stats, organizations, users (index, show, update, destroy, password-reset), logs/technical, logs/data, hl7-test (index, show, upload, download, destroy), ai-api-keys, sandbox/ai (generate, history), sandbox/snomed (validate-expressions, batch).
  • Tenant : questionnaires (templates, instances, rdv/send-invite, reports), appointments (rdv, transfer, agenda, response), users (validate, resend-verification, send-password-reset), patients/demand (POST). Fichiers : route files.download (signed). Public : appointment/reasons, config, redirect.

Fichiers et composants clés

  • Backend : UserController (recordSuperAdminLog, sendPasswordResetGlobal), TenantService, QuestionnaireInstanceService (generateAppointmentLink, sendAppointmentInvite), PatientDemandService, HealthcareService, SuperAdminHl7TestController, Loggable, EnsureSuperAdmin. Modèles : User, Log, Hl7Message, SuperAdminAiApiKey.
  • Frontend : auth.global.ts, pages dashboard/verify, suspended, superadmin (hl7-test, logs/data, sandbox ai/snomed), patient/data-removal. Composables useAuth, useHttp. Layouts auth, superadmin.

Configuration et variables d'environnement

  • API : DB_CONNECTION (mysql/pgsql), FRONTEND_URL, SANCTUM_STATEFUL_DOMAINS, GOOGLE_APPLICATION_CREDENTIALS (dev), GCP_HEALTHCARE_CREDENTIALS_SECRET (staging). config('database.default'), config('app.frontend_url').
  • Staging (Cloud Run) : APP_ENV, DB_* (Cloud SQL), REDIS_*, QUEUE_CONNECTION, CACHE_STORE, FRONTEND_URL=https://staging.premedica.care, GCP_HEALTHCARE_CREDENTIALS_SECRET. Secrets : DB_PASSWORD, APP_KEY.

Scripts et commandes

  • Setup : scripts/setup/start-dev.sh, grant-healthcare-permissions, add-healthcare-secret. Deployment : scripts/deployment/manage-gcp.sh, deploy-staging.sh, run-tenant-migrations-staging.sh, seed-staging-data.sh.
  • Checks : check-staging-config, check-healthcare-config, verify-auth-config, test-staging. HL7 : create-hl7-stores, cleanup-hl7-test-resources, test-hl7-gcp-ingestion, extract-hl7-gcp-messages. Artisan : FixUserStatuses, tenants:migrate.

Documentation

  • Architecture : documentation/architecture/DATABASE_AND_TENANCY.md, GCP_HEALTHCARE_INTEGRATION.md, SCHEMA_DATABASE.md. API : GOOGLE_OAUTH_SETUP.md, AUTH_CALLBACK.md. Déploiement : deployment/domains/SETUP_DOMAINS.md, gcp/SETUP_WIF.md, SETUP_GCP_SECRETS.md, STAGING_CHECKLIST.md.
  • Fixes : FIX_AUTHENTICATION_302_REDIRECT.md. Intégrations : HEALTHCARE_API.md, CLEANUP_HEALTHCARE_STORES.md. Changelog : RECAP_MODIFICATIONS_01_2026.md, RESUME_MODIFICATIONS_07_01_2026.md, CHANGELOG_SUPERADMIN.md. Setup : LANCEMENT_LOCAL.md. Index : documentation/INDEX.md, scripts/README.md.

Statistiques (estimations janv. 2026)

  • ~380 commits sur la période. ~200+ fichiers modifiés, ~2500 lignes ajoutées, ~800 supprimées. Migrations (central + tenant), commandes Artisan, templates emails, pages frontend (verify, suspended, hl7-test, etc.), contrôleurs et services, scripts, workflows.

État d'avancement du projet (fin de mois)

  • Staging GCP opérationnel : Cloud Run (API + Web), Cloud SQL PostgreSQL, Redis, domaines staging.premedica.care / api.staging.premedica.care. CI/CD sur push branche staging.
  • Multi-tenant : MySQL (dev), PostgreSQL (staging/prod). Base centrale + bases par organisation. Migrations central + tenant via jobs Cloud Run.
  • Superadmin : dashboard, orgs, users globaux, logs données/techniques, HL7 test, sandbox IA/SNOMED, clés API IA. Statuts utilisateurs (pending/validated/suspended), RGPD.
  • Fonctionnel : questionnaires, rendez-vous, agenda, réponses, QR codes, relance, transfert RDV. Docker dev : Sail, MySQL, Redis, MailHog, workers.

Politique de confidentialité et CGU, correctifs QR et API (URLs absolues, ImageMagick), déploiement staging, migrations IA/SNOMED et booking.

Fonctionnel

  • Politique de confidentialité et CGU mises à jour ; uniformisation du nom Prémedica. Refonte partielle page réponse patient et design QR code docteur.
  • Correction chargement des données de rendez-vous et des URLs API. Formulaire questionnaire : helper texts, progression. Token logic et seeders ajustés.

Infrastructure et technique

  • ImageMagick et extension imagick pour la génération de QR codes (QrCodeService, simple-qrcode). Correction des URLs QR code et des URLs API (chemins absolus).
  • Workflow deploy-staging désactivé temporairement ; corrections de syntaxe. Sidebar docteur : chemin Remplir un formulaire mis à jour.
  • Corrections design QR code docteur, redesign answer. Refactoring envoi questionnaire.

Migrations et base de données (déc. 2025)

  • Tenant : soft_deletes informations ; user_notifications ; snomed_extraction_batches, metrics ; ai_model_configurations, ai_available_models, ai_api_keys, ai_prompts ; medical_reports, snomed_extractions ; appointment_reasons, appointment_booking_configs ; protocols. Central : organization_id sur personal_access_tokens. Fix ai_model_configuration. patient_id nullable sur appointments.

État d'avancement du projet (fin de mois)

  • Application déployable (Docker, workflows GCP). Politique de confidentialité et CGU à jour. QR codes, questionnaires, prise de RDV opérationnels. Préparation IA/SNOMED (tables, config).

Calendrier et prise de rendez-vous en ligne, création de questionnaires, page de réponse (answer create), middleware answer.

Fonctionnel

  • Calendrier et système de prise de rendez-vous en ligne (agenda). Formulaire rendez-vous et questionnaire associé. Page answer create pour répondre aux questionnaires.
  • Création de questionnaires ; mise à jour partielle des réponses (partial update). Middleware pour la page de réponse au questionnaire. Favicon mis à jour. Ajustements tenant pour les requêtes.

Migrations et base de données (nov. 2025)

  • Tenant : parameters, reports, notifications ; encryption columns patients et answers ; type sur logs. Central : stripe_id, slug organisations. Tables questionnaire_instances, answers (questionnaire_instance_id), etc.

État d'avancement du projet (fin de mois)

  • Prise de RDV en ligne et réponses aux questionnaires en place. Base métier (patients, RDV, questionnaires, réponses) opérationnelle. Préparation rapports et notifications.

Logs et historique des réponses, QR codes (simplesoftwareio), rôles technicien/infirmier, pièces jointes (infos RDV), queue workers Docker.

Fonctionnel

  • Logs et historique des réponses pour tous les tenants. Rôles technicien et infirmier. Soft deletes sur users.
  • QR codes : génération (simplesoftwareio/simple-qrcode), envoi du lien questionnaire par email, retour du QR à la création de RDV. TokenPatient, QuestionnaireInstanceService. Informations et pièces jointes associées aux rendez-vous ; limite 25 fichiers, 2 Mo max. Tables appointment_information, information, files.
  • Vérification email utilisateur (fix send email verification). Réponse questionnaire : gestion des informations. Questionnaire instances et templates (parent_id).

Infrastructure et migrations

  • Queue workers ajoutés au Docker dev (queue:work snomed, default). Renommage de conteneurs. Configuration Docker pour logs et historique.
  • Migrations tenant : logs, token_patients, questionnaire_instance_templates, questionnaire_instances ; appointments, appointment_information, information, files ; qr_codes ; modifiers patients (nullable) ; answers (questionnaire_instance_id), etc.

État d'avancement du projet (fin de mois)

  • Logs et historique multi-tenant. QR codes et envoi de liens questionnaire par email. Rôles technicien et infirmier. Stack Docker (API, workers, Redis, MailHog) en place. Modèle de données questionnaires-RDV-infos consolidé.

Fondations : API multi-tenant, CRUD patients et médecins, questionnaires, rendez-vous, connexion par organisation (tenant).

Fonctionnel

  • CRUD rendez-vous (AppointmentController), médecins et patients. Structure API tenant : routes modulaires (tenant.php, modules/tenant/), contrôleurs par ressource. Connexion par organisation (tenant) à la connexion (switching tenant in login).
  • Templates de questionnaires (QuestionnaireTemplate), gestion des questions et options. Seeders : Organisation et Patient pour les tests.

Base de données et structure

  • Architecture multi-tenant : base centrale (organisations, users superadmin) et bases par organisation (premedica_{slug}). Modèles User, Patient, Doctor, Appointment, QuestionnaireTemplate ; roles, user_role ; personal_access_tokens (tenant).
  • Migrations tenant : users, roles, user_role, patients, doctors, questionnaire_templates, answers ; migrations central organisations. Schema fondateur.

Environnement de développement

  • Docker Compose : Laravel Sail (api), MySQL, services associés. Structure api/ (Laravel), web/ (Nuxt/Vue) en place. Point d'entrée projet pour dev local.

État d'avancement du projet (fin de mois)

  • Fondations multi-tenant, API REST (patients, médecins, rendez-vous), templates de questionnaires. Environnement de dev Docker opérationnel. Base pour évolutions octobre (logs, QR, workers).

Les notes mensuelles sont consolidées le 1er de chaque mois.