Prima
Più piattaforme, più passaggi manuali
Dati e attività erano distribuiti tra più strumenti. La segreteria doveva reimmettere informazioni, verificare stati e ricostruire manualmente una parte importante del lavoro quotidiano.
EMPV / Progetto02
Piattaforma operativa per un centro di psicologia
Gestione operativa per uno studio psicologico
Il problema non erano le prenotazioni. Era tutto ciò che succedeva tra una prenotazione e l'altra.
Pazienti, appuntamenti, professionisti, pagamenti e attività amministrative vivevano su più strumenti. La segreteria doveva riportare informazioni da una piattaforma all'altra, controllare manualmente gli stati e ricostruire continuamente cosa fosse successo.
Cosa abbiamo cambiatoAbbiamo portato quei passaggi dentro un unico flusso operativo.
Sistema
Un'unica identità operativa
Pazienti, professionisti, appuntamenti, pagamenti, pacchetti e regole di chiusura condividono lo stesso modello, con permessi server-side e viste diverse in base al ruolo.
01 / Perché era un problema
La segreteria faceva da ponte manuale tra strumenti che non condividevano lo stesso stato.
In un centro psicologico non basta mettere tutto nello stesso database. Segreteria, professionisti e direzione devono vedere e modificare cose diverse; le note professionali non possono diventare semplicemente 'dati del centro'.
02 / Come abbiamo ragionato
Centralizzare il flusso, non appiattire ruoli e responsabilità.
Il disegno usa identità canoniche per paziente e professionista, contesto di centro, autorizzazioni server-side e audit delle correzioni. L'esperienza quotidiana resta semplice, mentre regole e permessi rimangono nel backend.
03 / Cosa abbiamo cambiato
Paziente, appuntamento, seduta e stato amministrativo condividono lo stesso flusso.
Disponibilità, prenotazioni, spostamenti, chiusura delle sedute, stato pagamenti, pacchetti, regola delle 48 ore, promemoria, report e correzioni autorizzate vengono trattati come parti dello stesso sistema operativo.
04 / Come funziona adesso
L'operatività quotidiana è unificata; regole e permessi restano autorevoli nel backend.
La direzione tecnica parte da Frappe / ERPNext e Marley Healthcare, estendendoli con un layer dedicato quando regole, sicurezza o workflow non possono essere rappresentati correttamente in modo nativo.