Come abbiamo costruito MedicHub, il gestionale per dentisti

5 min. lettura

Il caso di studio tecnico di MedicHub, il gestionale per studi dentistici sviluppato da AraLith: un'installazione multi-tenant con database separato per ogni studio, dati clinici cifrati a riposo, integrazione con il Sistema Tessera Sanitaria e un server MCP con 29 strumenti al posto di un assistente AI integrato.

Un gestionale sanitario si progetta partendo dai dati: dove stanno, chi li vede e che cosa può uscire.

Abbiamo costruito MedicHub, il gestionale per studi dentistici, come un'unica applicazione cloud con un database separato per ogni studio, i dati clinici cifrati, l'integrazione diretta con il Sistema Tessera Sanitaria e un server MCP per collegare assistenti esterni. Ecco le scelte, una per una.

Il caso di studio

Come abbiamo costruito MedicHub?

MedicHub è il gestionale per studi dentistici che abbiamo progettato e sviluppato noi di AraLith, software house in provincia di Roma, attiva dal 2007. L'abbiamo costruito come un'unica installazione cloud multi-tenant, cioè un solo software che serve molti studi tenendo separati i dati di ciascuno, con dati clinici cifrati a riposo, l'integrazione diretta con il Sistema Tessera Sanitaria e un server MCP che permette di collegare un assistente esterno senza che il gestionale contenga modelli di intelligenza artificiale.

Il progetto attuale, in Laravel 12 e React 19, è il rifacimento di un gestionale odontoiatrico precedente scritto in PHP e jQuery. I risultati ottenuti nella ricerca dal sito medichub.it sono raccontati nel percorso SEO documentato di medichub.it.

Banner MedicHub: gestionale per studi medici con dashboard, agenda appuntamenti e preventivo su schema dentale

In sintesi

  • MedicHub è un'installazione unica multi-tenant: ogni studio ha il proprio database e il proprio spazio file, riconosciuti dal dominio da cui si accede.
  • Anagrafiche, diario clinico, cartelle e anamnesi sono cifrati a riposo campo per campo, e ogni accesso ai dati viene registrato in un log.
  • L'integrazione con il Sistema Tessera Sanitaria usa direttamente il web service del MEF: invio, variazione, cancellazione e rimborso delle spese.
  • MedicHub non contiene né chiama modelli di intelligenza artificiale: espone un server MCP con 29 strumenti, tutti spenti finché lo studio non li accende uno per uno.
  • Appuntamenti e note proposti da un assistente esterno restano in attesa finché lo studio non li conferma nel gestionale.

Quale problema doveva risolvere un gestionale per dentisti?

Un gestionale per dentisti deve tenere insieme, nello stesso flusso, l'agenda di più medici, la cartella clinica, i preventivi, le fatture al paziente e gli adempimenti verso il Sistema Tessera Sanitaria. I gestionali generalisti non coprono questo dominio e molti prodotti verticali sono installazioni desktop chiuse: per questo MedicHub è nato come applicazione cloud che segue lo studio dal primo appuntamento alla trasmissione della spesa sanitaria.

  • Agenda per medico

    Vista settimanale per ogni medico con spazi da 15 minuti e fasce orarie, con promemoria ai pazienti via email e SMS.

  • Preventivo sull'odontogramma

    Voci prese dal listino e legate al dente sull'odontogramma, con stato per singola voce e piano di rate.

  • Diario clinico e cartella

    Diario, odontogramma, immagini protette da link firmati, anamnesi a questionario e prescrizioni di laboratorio nella scheda del paziente.

  • Fatture al paziente

    Fatture dalle voci o dalle rate del preventivo, numerate per anno, tipo e medico, con bollo calcolato e note di credito.

  • Sistema Tessera Sanitaria

    Trasmissione delle spese singola, massiva o mensile, con protocollo, errori, variazioni, cancellazioni e rimborsi.

  • Moduli e consensi

    Consensi e referti come moduli dello studio, consensi privacy del paziente e opposizione all'invio al Sistema Tessera Sanitaria.

Architettura

Come funziona l'architettura multi-tenant di MedicHub?

L'architettura multi-tenant di MedicHub funziona così: un'unica installazione riconosce lo studio dal dominio da cui arriva la richiesta, legge in un registro centrale la connessione al database e lo spazio file di quello studio e li applica prima di eseguire qualsiasi operazione. I dati clinici non condividono tabelle fra studi: ogni studio ha il proprio database.

Nel registro centrale restano solo le informazioni per instradare le richieste. Utenti, sessioni, log di accesso e file vivono nel database e nello spazio dello studio, e se il registro non riconosce lo studio la richiesta si ferma.

Illustrazione di un monitor con un gestionale: menu laterale, tabella con righe e stati colorati, ingranaggio arancione

Il percorso di una richiesta, dal dominio ai dati dello studio

01

Il dominio identifica lo studio

Un indirizzo per ogni studio

Ogni studio entra dal proprio indirizzo: l'host della richiesta viene confrontato con i domini attivi del registro di piattaforma.

02

Il registro fornisce database e spazio file

Credenziali cifrate

Per ogni studio il registro conserva la connessione al database, con la password cifrata, e la cartella dei file.

03

La richiesta lavora solo sui dati dello studio

Isolamento

Database, sessioni e dischi vengono reimpostati sullo studio prima di eseguire la richiesta; se manca un anello, la richiesta non prosegue.

04

Aggiornamenti e attività pianificate per studio

Un pianificatore per tutti

Gli aggiornamenti dello schema e le attività notturne girano studio per studio, da un'unica riga di pianificazione per l'intera installazione.

Come si proteggono i dati sanitari in un gestionale per dentisti?

In un gestionale per dentisti i dati sanitari si proteggono con misure scritte nel codice, non solo con procedure: in MedicHub i campi clinici sono cifrati a riposo, ogni accesso viene registrato, i tempi di conservazione sono fissati per categoria e l'accesso richiede la verifica in due passaggi. I dati relativi alla salute sono una categoria particolare per l'art. 9 del Regolamento (UE) 2016/679, e l'art. 32 chiede misure di sicurezza adeguate a quel rischio. Come affrontiamo questi requisiti nei progetti su misura è spiegato nella pagina sicurezza e conformità del software.

  • Campi clinici cifrati

    Codice fiscale, contatti, indirizzo, data di nascita, note, anamnesi, diario e cartelle sono cifrati nel database; il codice fiscale ha un'impronta separata per la ricerca esatta.

  • Registro degli accessi

    Ogni richiesta riuscita sui dati dello studio viene registrata con utente, tipo di dato, indirizzo IP e ora.

  • Conservazione per categoria

    20 anni per i dati clinici, 10 per quelli contabili, 5 per quelli operativi: la pulizia elimina solo i record già cancellati oltre la soglia.

  • Verifica in due passaggi

    Obbligatoria per entrare nel gestionale, con codice inviato via email e blocchi progressivi dopo i tentativi falliti.

  • Diritti del paziente

    Cancellazione dei dati identificativi dalla scheda ed esportazione in PDF di anagrafica, appuntamenti, preventivi, fatture e note del diario.

  • Intestazioni di sicurezza

    Content Security Policy e intestazioni HTTP restrittive applicate in produzione a tutte le pagine e alle API.

Con quali sistemi esterni si integra MedicHub?

MedicHub si integra con tre sistemi esterni: il Sistema Tessera Sanitaria del Ministero dell'Economia e delle Finanze, il Fascicolo Sanitario Elettronico 2.0 attraverso il gateway di Sogei e i canali SMS ed email per i messaggi ai pazienti. Sono interfacce di cui non controlliamo il contratto, quindi ogni integrazione mostra allo studio i propri esiti ed errori invece di nasconderli.

Sistema Tessera Sanitaria

Dialogo diretto con il web service del MEF: iscrizione, invio singolo, massivo o mensile delle spese, lettura di protocollo ed errori, variazioni, cancellazioni e rimborsi.

Fascicolo Sanitario Elettronico 2.0

Referti in formato CDA2 con PDF firmato PAdES, inviati al gateway di Sogei. Il ciclo è stato collaudato in pre-produzione; la pubblicazione di documenti reali richiede l'accreditamento, che a settembre 2026 era ancora in attesa.

SMS ed email ai pazienti

Promemoria degli appuntamenti e richiami tramite un gateway SMS e la posta dello studio, con regole di invio configurabili e un registro dei messaggi partiti.

Strumenti per assistenti esterni

Perché MedicHub ha un server MCP invece di un assistente AI?

MedicHub ha un server MCP invece di un assistente AI perché così il gestionale resta un software deterministico: non contiene né chiama modelli di intelligenza artificiale ed espone 29 strumenti che l'assistente scelto dallo studio o dall'utente può usare, sempre con i permessi di chi si collega. Il Model Context Protocol (MCP) è lo standard aperto con cui un assistente esterno chiama funzioni messe a disposizione da un altro software.

Il contratto con il fornitore dell'assistente è dello studio o dell'utente, e MedicHub non formula diagnosi, non analizza immagini e non dà suggerimenti clinici: gli strumenti leggono e propongono dati gestionali, i calcoli li fa il gestionale.

Illustrazione di uno scudo con lucchetto arancione accanto a un documento con una spunta

Quali strumenti espone il server MCP di MedicHub?

Il server MCP di MedicHub espone 29 strumenti in quattro gruppi: 21 leggono dati e 8 scrivono. Nessuno strumento elimina, finalizza, fattura, trasmette o invia messaggi ai pazienti.

  • Configurazione

    Medici, listino, moduli e testi dei messaggi ai pazienti; i moduli nuovi nascono in bozza disattivata.

    9
  • Agenda

    Appuntamenti, analisi dell'agenda, spazi liberi, nuovi appuntamenti e proposte di spostamento, sempre in attesa.

    5
  • Amministrazione

    Ricerca pazienti, preventivi, fatture, statistiche solo come totali, proiezioni e preventivi nuovi in bozza.

    9
  • Dati clinici

    Diario, cartella, prescrizioni, anamnesi e odontogramma in lettura; le note nuove del diario restano in attesa.

    6

Come si collega un assistente esterno a MedicHub?

01

Lo studio accende gli strumenti

Spenti per impostazione predefinita

Alla prima installazione il server e tutti gli strumenti sono spenti. Il responsabile dello studio li accende uno per uno, dopo aver letto cosa fa ciascuno, quali dati fa uscire e quali rischi comporta; ogni accensione registra il consenso con data, ora e versione del testo.

02

L'utente autorizza il proprio assistente

OAuth 2.1 con PKCE

L'assistente si registra sul server dello studio e l'utente lo autorizza con OAuth 2.1 e PKCE, dopo l'accesso al gestionale con verifica in due passaggi. Il token d'accesso dura 60 minuti.

03

I pazienti escono come «paziente N»

Pseudonimizzazione di serie

Con le impostazioni predefinite nessun nome, codice fiscale, contatto o testo libero esce dal gestionale: il paziente è «paziente N» con un link alla scheda, che si apre solo dopo il login.

04

Le scritture restano in attesa

Conferma nel gestionale

Per impostazione predefinita appuntamenti e note del diario proposti dall'assistente compaiono «in attesa» e diventano reali solo quando un utente dello studio li conferma nel gestionale; preventivi e moduli nascono in bozza.

05

Ogni chiamata lascia traccia

Registro e revoca

Il registro delle chiamate conserva utente, strumento, identificativi toccati ed esito, mai i contenuti. Dalla pagina Connessioni l'utente revoca il collegamento e il responsabile può spegnere il server.

Quali errori abbiamo evitato progettando MedicHub?

Progettando MedicHub abbiamo evitato quattro errori tipici dei gestionali sanitari: separare gli studi con un semplice campo nel database, far uscire i nomi dei pazienti verso servizi esterni, lasciare che uno strumento esterno scriva direttamente nei dati e affidare i calcoli a chi non è il gestionale. Valgono per qualunque software su misura che tratti dati sensibili.

Distinguere gli studi con un identificativo in ogni tabella significa che una sola query senza filtro basta a mescolare i dati di due studi. In MedicHub ogni studio ha il proprio database e il proprio spazio file: l'isolamento non dipende dalla correttezza di ogni singola query.

Uno strumento che restituisce nome, cognome o codice fiscale a un servizio esterno trasferisce dati sanitari identificabili. Per questo il server MCP di MedicHub risponde con «paziente N» e un link alla scheda, e sostituisce note, diario e anamnesi con «[testo non esportato]» finché lo studio non decide diversamente.

Un appuntamento o una nota clinica creati senza controllo umano finiscono in agenda o in cartella anche quando sono sbagliati. In MedicHub le scritture degli assistenti restano in attesa o nascono in bozza, e chi conferma è un utente dello studio con i permessi per farlo.

In MedicHub totali, statistiche e proiezioni li calcola il gestionale, e gli strumenti MCP restituiscono il risultato già pronto invece dei dati grezzi da sommare. Le statistiche escono solo come totali, mai come righe per paziente: chi legge riceve un numero che può ritrovare identico dentro il gestionale.

Cosa fare adesso

  • Se stai valutando un gestionale che tratta dati sanitari o sensibili, chiedi al fornitore dove stanno i dati di ogni cliente e come sono separati da quelli degli altri.
  • Fatti elencare quali dati escono dal software verso servizi esterni, assistenti compresi, e in che forma: nomi in chiaro o pseudonimi.
  • Verifica che ogni scrittura proposta da uno strumento esterno resti in attesa finché una persona dello studio non la conferma.

Domande frequenti su MedicHub e sul suo sviluppo

MedicHub è il gestionale cloud per studi dentistici sviluppato da AraLith, software house in provincia di Roma attiva dal 2007. Comprende agenda per medico, scheda del paziente con diario clinico e odontogramma, preventivi, fatture, l'invio delle spese al Sistema Tessera Sanitaria e un server MCP per assistenti esterni. Su aralith.com MedicHub è raccontato come caso di studio di sviluppo software in un dominio regolamentato.

MedicHub non contiene né chiama modelli di intelligenza artificiale. Il gestionale espone un server MCP, cioè un insieme di strumenti deterministici che un assistente esterno scelto dallo studio o dall'utente può usare con i permessi di chi si collega. MedicHub non formula diagnosi, non analizza immagini e non dà suggerimenti clinici.

MedicHub è sviluppato con Laravel 12 su PHP 8.2 per il server e con React 19, TypeScript e Inertia per l'interfaccia. Le pagine si limitano a mostrare i dati: ogni informazione passa da API JSON documentate con OpenAPI, da cui viene generato il client TypeScript usato dall'interfaccia.

L'architettura multi-tenant di MedicHub è progettata per impedirlo: ogni studio ha un database e uno spazio file propri, scelti in base al dominio da cui arriva la richiesta, e nel registro centrale restano solo le informazioni per instradare. Se il registro non riconosce lo studio, la richiesta si ferma invece di proseguire su dati sbagliati.

Un assistente collegato a MedicHub vede solo ciò che restituiscono gli strumenti accesi dallo studio e consentiti all'utente che si è collegato. Con le impostazioni predefinite i pazienti compaiono come «paziente N», i testi liberi non vengono esportati e ogni chiamata restituisce al massimo 200 righe su un intervallo di 31 giorni.

Le scelte di MedicHub, cioè un database per cliente, dati sensibili cifrati, registro degli accessi e scritture esterne in attesa di conferma, si applicano a qualunque settore che tratti dati delicati. Le progettiamo caso per caso nello sviluppo di software su misura, partendo dall'analisi dei processi e dei dati del cliente.

Il tuo gestionale tratta dati delicati?

Progettiamo gestionali su misura con le stesse attenzioni di MedicHub: dati separati per cliente, accessi registrati, integrazioni con i sistemi pubblici. Un referente tecnico unico segue il progetto dall'analisi alla consegna, e il colloquio iniziale è gratuito.

Contenuto realizzato con il supporto dell'intelligenza artificiale.