NovaClin Core
L'IA au Service de l'Excellence Clinique. 

Scene 1

NovaClin Core
L'IA au Service de l'Excellence Clinique

Plateforme CTMS, eCRF, ePRO, eConsent, Qualité, Documentation, Ressources, Budget & finance et “IA Clinique”.

Bienvenue dans l’univers NovaClin ou vos essais prennent vie.

VUE D’ENSEMBLE. Une plateforme clinique intégrée, déjà fortement modulaire. 

Scene 2

Une plateforme clinique intégrée, déjà fortement modulaire

fichiers TypeScript / TSX analysés dans src

NovaClin Core n’est pas un simple tableau de bord : le dépôt montre une suite clinique couvrant les opérations, les données patient, la conformité, la ressource, la finance et l’IA.

Frontend
React 18, Vite, TypeScript, TanStack Query, Shadcn/Radix.

Backend
Supabase, PostgreSQL, Auth, Storage, fonctions Edge et RLS.

Modules
CTMS, eCRF, eTMF, LMS, RPP, budget, pharmacie, IA.

Architecture
Des hubs métier évitent une navigation monolithique.

Analyse statique réalisée sans modification de l’application.

ARCHITECTURE FONCTIONNELLE. Le modèle central est l’étude clinique. 

Scene 3

Le modèle central est l’étude clinique

L’étude courante devient le périmètre d’exécution de l’application : elle porte le contexte clinique, opérationnel et documentaire.

Les modules interrogent les données dans le contexte de l’étude active, ce qui simplifie la cohérence entre CTMS, eCRF, documents et finance.

Le choix d’étude est conservé localement, ce qui améliore la continuité de travail entre les sessions utilisateur.

Cette structure multi-études permet de monter naturellement vers des vues portefeuille et ressources globales.

Source analysée : src/contexts/StudyContext.tsx.

EXPÉRIENCE MÉTIER. La navigation reflète les métiers de la recherche clinique. 

Scene 4

La navigation reflète les métiers de la recherche clinique

Le layout principal ne classe pas les écrans par technologie : il segmente l’application en univers opérationnels lisibles, puis ajuste les menus selon le rôle et le périmètre utilisateur.

Centres, personnel, inclusions, monitoring, SAE,

Temps, budget, contrats, facturation, dépenses et

Vision portefeuille des allocations, absences et

Patients, visites, données, queries, consentement

Documents partagés sponsor-site avec filtrage

Accès complet, y compris administration système et gouvernance globale.

Vue opérationnelle étendue sur les études, les ressources et le pilotage.

Accès orienté monitoring, sans exposition inutile aux marges et budgets sensibles.

Navigation resserrée autour de l’eCRF, du training et des éléments partagés.

Sources analysées : HubLayout, AuthContext et guide technique du projet.

CŒUR OPÉRATIONNEL. Le CTMS pilote les opérations. 

Scene 5

Le module CTMS agrège les objets essentiels de conduite d’étude pour donner aux équipes sponsor/CRO une vision actionnable des centres, patients, documents, événements et visites.

Hooks applicatifs centralisant les accès Supabase et reliant les tables opérationnelles autour de l’étude.

Étude d’abord
Données scoppées par study_id.

Rôle ensuite
Visibilité adaptée aux profils sponsor, CRA/ARC et site.

Référentiel des centres investigateurs, des équipes internes et du personnel site.

Suivi patient opérationnel, synchronisé avec les dossiers eCRF lorsque nécessaire.

Gestion documentaire sponsor/site avec partage eISF contrôlé.

SAE, déviations, CAPA, rapports de monitoring et alertes associées.

Transformation des données dispersées en une chaîne de pilotage cohérente (ouverture de centre, monitoring, conformité documentaire).

Traçabilité
Les événements critiques restent liés au contexte étude et centre.

Exploitation
Les dashboards peuvent synthétiser l’avancement et les risques.

Sources analysées : HubLayout, Dashboard, useStudyData, guide technique.

ECRF / EDC. L’eCRF apporte une vraie couche EDC. Le moteur eCRF relie patients, visites, queries, audit, consentement et randomisation en un flux exploitable par le CTMS.. 

Scene 6

Le moteur eCRF relie patients, visites, queries, audit, consentement et randomisation en un flux exploitable par le CTMS.

Une chaîne clinique structurée, avec contrôle de changement et synchronisation opérationnelle.

Dossiers patients et visites forment le socle de saisie clinique par étude/centre.

Upsert avec cache optimiste pour fluidifier la saisie sans rompre la traçabilité.

Ouverture, réponse et clôture des écarts dans un cycle cohérent.

Modifications sensibles nécessitent une raison et alimentent l’audit trail.

Consentement et signatures intégrés au parcours avec exigence documentaire.

Mise à jour du dossier eCRF et propagation vers le CTMS d’inclusion.

Lecture fonctionnelle : NovaClin Core combine CTMS et EDC, réduisant les ruptures entre inclusion et suivi clinique.

Source analysée : hooks eCRF, formulaires dynamiques, audit trail et randomisation.

SÉCURITÉ · AUDIT · INTÉGRITÉ. La conformité GxP structure l’architecture. 

Scene 7

La conformité GxP structure l’architecture

L’application ne traite pas la conformité comme une couche décorative : elle l’inscrit dans l’accès, l’isolation des données, la traçabilité et l’intégrité documentaire.

Supabase Auth et le contexte applicatif filtrent les parcours selon les profils Admin, CPM, CRA/ARC et personnel de site.

Les politiques Row Level Security limitent la visibilité aux lignes liées à l’étude, au rattachement équipe ou au centre investigateur.

Les changements sensibles capturent utilisateur, horodatage, ancienne valeur, nouvelle valeur et reason for change.

Les signatures, consentements et documents peuvent être associés à une empreinte SHA-256 pour détecter l’altération.

Le partage sponsor-site repose sur des documents marqués is_eisf et rattachés au centre concerné : les sites voient ce qui leur est explicitement partagé, tandis que le sponsor conserve la supervision documentaire.

Sources analysées : guide technique, AuthContext, configuration Supabase, modules eCRF et documentation.

GOUVERNANCE DOCUMENTAIRE. Qualité, LMS et eTMF gouvernent les documents. 

Scene 8

Qualité, LMS et eTMF gouvernent les documents

Le module qualité relie les documents, les revues, les signatures et la formation dans une logique de conformité continue, plutôt que dans un simple espace de stockage.

Les documents passent par des statuts structurés, de la création à la validation, avec revue qualité et administration lorsque le processus l’exige.

Statuts identifiés : brouillon, revue, qualité, administration, validation.

Les modules de formation, questionnaires, journaux et tableaux de conformité relient les exigences documentaires aux audiences sponsor et site.

Les logs de formation soutiennent la preuve de qualification des utilisateurs.

Les documents réglementaires et site peuvent être exposés selon leur périmètre, en cohérence avec les rôles et les politiques d’accès Supabase.

La visibilité documentaire est gouvernée par étude, centre et rôle utilisateur.

La valeur principale du module est sa capacité à transformer les documents en objets gouvernés : versionnés, signés, associés à la formation, indexables par l’IA et exploitables lors d’un audit.

Sources analysées : useQualityLms.ts, TECHNICAL_GUIDE.md et architecture documentaire NovaClin Core.

RESOURCE & MARGIN. Resource & Margin relie activité et finance. 

Scene 9

Resource & Margin relie activité et finance

Le module RPP transforme les temps saisis, les allocations et les objets budgétaires en indicateurs de marge, de consommation et de charge globale.

Les feuilles de temps capturent l’activité réelle par étude, profil et période, puis alimentent les vues analytiques.

La planification des ressources articule absences, semaines, activités et contributeurs affectés aux études.

Les contrats sponsor, versions et lignes budgétaires structurent la base économique de l’étude.

Les factures, items et dépenses modélisent le réalisé financier au-delà du simple reporting.

Les RPC calculent marge par profil, marge in fine, consommation budgétaire et charge globale.

La finance n’est pas seulement visualisée : elle est portée par des objets métiers persistants, des versions contractuelles et des invalidations de cache ciblées après mutation.

Les ressources globales donnent une vision multi-études des capacités, permettant de relier effort réel, allocation prévisionnelle et performance économique.

Sources analysées : useBudget.ts, useTimesheets.ts, useResourcePlanner.ts et guide technique.

NOVACLIN CORE INTELLIGENCE. L’IA est contextualisée et gouvernée. 

Scene 10

L’assistant IA est conçu comme un orchestrateur clinique : il construit un contexte d’étude, tient compte du rôle utilisateur, propose des actions contrôlées et journalise ses échanges.

L’orchestrateur détecte l’intention, prépare un contexte métier limité, délègue vers des agents spécialisés et renvoie une réponse ou une action candidate à confirmer.

Les données sont récupérées autour de l’étude active : centres, inclusions, SAE, déviations, documents, budget ou pharmacie selon l’intention.

Les actions proposées par l’IA ne sont pas exécutées librement : elles passent par une validation de règles puis une confirmation utilisateur.

Les conversations, messages, décisions et logs internes sont persistés pour rendre l’assistance observable et auditable.

Sources analysées : useAIAssistant.ts, orchestrator.ts, TECHNICAL_GUIDE.md.

SYNTHÈSE D’ANALYSE. Forces et points de vigilance. 

Scene 11

Le socle applicatif est riche et cohérent, mais son niveau d’ambition impose une discipline d’industrialisation à la hauteur de la couverture fonctionnelle.

CTMS, eCRF, eTMF, LMS, budget, ressources, pharmacie et IA sont déjà pensés comme une suite clinique intégrée.

Les hubs métier, hooks spécialisés et contextes globaux donnent une base extensible et lisible.

Supabase Auth, rôles, Row Level Security et filtrage étude/centre soutiennent l’isolation des données.

Les liens CTMS ↔ eCRF ↔ documents ↔ ressources ↔ finance réduisent les ruptures opérationnelles.

Readme, Technical et User Manual mis en place et mettre a jour.

Matrice de Responsabilités (RAC) et de Gouvernance mise en place

Le volume SQL appelle une stratégie de release, rollback et validation environnementale rigoureuse.

NovaClin Core dispose d’une base fonctionnelle solide ; la prochaine étape consiste à transformer cette richesse en produit maintenable, documenté, testé et gouverné.

Synthèse issue de l’analyse statique du dépôt, sans modification de l’application.

FEUILLE DE ROUTE RECOMMANDÉE. Priorités recommandées et conclusion. 

Scene 12

NovaClin Core dispose d’une base fonctionnelle dense et cohérente. La prochaine étape consiste à sécuriser son industrialisation, sa lisibilité produit et sa gouvernance d’évolution.

Formaliser les parcours, les rôles, la matrice des modules et les règles de gouvernance pour rendre la richesse fonctionnelle lisible.

Renforcer les tests de non-régression sur authentification, RLS, eCRF, audit trail, documents, randomisation et facturation.

Maintenir la stratégie de migrations Supabase, les versions SQL et le contrôle de changement pour préserver la stabilité clinique.

Présenter NovaClin Core comme une suite intégrée reliant opérations cliniques, données patient, conformité, ressources et performance.

La force de l’application réside dans son modèle gouverné par l’étude, sécurisé par rôle et capable de relier les dimensions clinique, documentaire, opérationnelle, financière et intelligente d’un essai.

Conclusion issue de l’analyse statique en lecture seule du dépôt clinical-study-suite-main.

PptxGenJS Presentation

Scene 1 (0s)

Scene 2 (7s)

Scene 3 (25s)

Scene 4 (43s)

Scene 5 (1m 10s)

Scene 6 (1m 35s)

Scene 7 (1m 58s)

Scene 8 (2m 21s)

Scene 9 (2m 48s)

Scene 10 (3m 15s)

Scene 11 (3m 41s)

Scene 12 (4m 7s)