La situazione
Un gruppo medico con quindici cliniche funzionava su otto cose che non sapevano l'una dell'altra: un sito, un widget separato per le prenotazioni, un foglio di calcolo per le scorte, un secondo foglio per il laboratorio, un programma di contabilità, un'app per la rilevazione delle presenze, una dashboard pubblicitaria e una casella di posta condivisa. Ogni cifra che contava esisteva in almeno due posti, e dove non coincidevano nessuno sapeva dire quale fosse quella giusta.
Questo non è un problema di tecnologia. È un problema di business che si presenta come un problema di tecnologia, ed è esattamente la forma di lavoro in cui sono più brava.
Che cosa ho costruito
Una sola piattaforma Django, che serve tutte e quindici le sedi: il sito pubblico, le prenotazioni, le cartelle dei pazienti, il CRM, la logistica di laboratorio, le scorte su più magazzini, la contabilità fiscale, l'HR e la rendicontazione della spesa pubblicitaria. Tutto dietro un unico admin, con isolamento a livello di clinica e di regione per nove ruoli di personale, così che una receptionist di una città non possa vedere i pazienti di un'altra città e non debba nemmeno chiedersi perché.
Le funzionalità sono la parte banale. Tre dei sistemi sottostanti meritano di essere descritti, perché sono loro a fare la differenza tra software che funziona il giorno del lancio e software di cui ti fidi ancora due anni dopo.
Un flusso di consenso che reggerebbe in tribunale
Il consenso medico sotto il GDPR non è una checkbox con un timestamp. Quello che devi poter produrre, in seguito, è esattamente il documento che una determinata persona ha accettato in un determinato momento - non la tua versione di adesso.
Così il flusso genera il documento, lo mostra sullo schermo, conferma l'identità con un codice inviato via SMS e conserva il PDF renderizzato insieme al testo, alla lingua in cui è stato mostrato, all'indirizzo da cui è stato firmato e a una catena di hash che lo lega alla cartella. Se modifichi il modello dopo, cambia quello che vede il paziente successivo e niente di quello che hanno accettato i precedenti.
La regola sottostante: il consenso si dà a una frase, non a un
booleano. Se il tuo sistema conserva true, ha conservato la cosa
sbagliata.
Le scorte come registro, non come numero
La maggior parte dei sistemi di magazzino tiene una colonna
quantity in cui scrive il codice. Quella colonna prima o poi
diventa sbagliata - una race condition, un retry, un clic sbagliato, un trasferimento
applicato a metà - e una volta che è sbagliata non hai più modo di scoprire
perché, perché la prova è stata sovrascritta dalla risposta.
Qui la quantità non si conserva. Ogni ricezione, trasferimento, consumo e correzione è una voce immutabile con segno, e il saldo di qualsiasi magazzino è la somma delle voci che lo toccano. Le correzioni aggiungono l'inverso invece di modificare lo storico. Questo fa della riconciliazione una proprietà del design, non un compito mensile, e significa che la risposta alla domanda "perché ne abbiamo undici?" è sempre disponibile e sempre completa.
Più giù nella pagina trovi una versione funzionante dell'idea.
Un calendario che non può sovrapporre due appuntamenti
Gli appuntamenti di quindici cliniche si sovrappongono di continuo, e la reception deve vedere un'intera giornata a colpo d'occhio, senza che due prenotazioni occupino mai lo stesso posto. Questo è il problema dell'interval scheduling: ordini per ora di inizio, poi metti ogni appuntamento nella prima corsia il cui appuntamento precedente è già finito.
Quello che lo rende degno di essere implementato per bene e non per approssimazione è che la variante greedy è dimostrabilmente ottima - il numero di corsie che produce è esattamente il numero più grande di appuntamenti che si sovrappongono in un singolo istante, cioè un limite inferiore invalicabile che nessun algoritmo può battere. Puoi vederlo reggere nella demo qui sotto.
La realtà rumena
La fatturazione, il giornale di cassa e i driver per le stampanti fiscali richieste dalla legge. Lavori protesici tracciati tramite corriere tra clinica e laboratorio. Rilevazione delle presenze con un piccolo client desktop che manda un heartbeat. Niente di tutto questo è ingegneria interessante e tutto insieme fa la differenza tra un sistema che le cliniche usano e uno che aggirano.
La decisione che difenderei con più forza
Ogni dipendenza esterna della piattaforma fa fail open. Se il provider SMS è giù, se l'API pubblicitaria limita le richieste o se il servizio di fatturazione va in timeout, la prenotazione si completa comunque, e il lavoro rimasto va in coda e viene segnalato a una persona.
L'alternativa - rifiutare una prenotazione perché un terzo non è disponibile - significa esternalizzare i tuoi ricavi all'uptime di qualcun altro. Le protezioni interne vanno al contrario: i rate limit, la validazione e l'honeypot fanno fail closed, perché lì non hai nessuno a cui dare la colpa.
Che cosa farei diversamente
Costruirei prima il livello di reporting. Ho progettato il registro e la programmazione correttamente fin dall'inizio e ho lasciato che il reporting si accumulasse da sé, il che ha significato che i primi tre mesi di domande del management hanno avuto risposta con query scritte a mano da me. Corretto, ma lento, e avrei dovuto prevederlo.