Modellazione di database

Ho scritto una canzone sul filo interdentale ma i denti di qualcuno sono diventati più puliti?

Frank Zappa

Quando pensiamo allo studio dentistico, le nostre prime associazioni sono il trapano, il dolore e la paura. OK, suona male. Oltre a prendersi cura dei denti, un dentista ha molti altri obblighi che sono professionali, legali o entrambi. Tutti richiedono una corretta gestione dei dati.

Per soddisfare questo requisito di documentazione, molti studi dentistici e medici utilizzano documenti cartacei. Lentamente ma inesorabilmente, però, c'è una tendenza verso i record e la gestione digitali del 21° secolo.

Dentro lo Studio di Odontoiatria

Andare dal dentista non è qualcosa che di solito ricordiamo con gioia. Se siamo stati fortunati, abbiamo schivato il dolore ma il nostro portafoglio probabilmente ha sofferto molto. Dopo essere entrati in uno studio dentistico, la procedura è solitamente la seguente:

• Entrambi vi impegnate in una breve chiacchierata. (Spesso spiacevole perché hai promesso al tuo dentista che lo visiterai la prossima settimana e sono passati 2 anni. Poi dici che te ne sei dimenticato, lui è d'accordo e tutto è tornato a posto.)
• Ti siedi sulla sedia mentre lui guarda i record dei tuoi trattamenti precedenti. Chiede se è successo qualcosa dall'ultima visita e c'è qualche aggiornamento nella tua cartella clinica.
• Ti dà un'occhiata dentro la bocca per determinare cosa è andato storto e ti dice cosa lo risolverà.
• Puoi concordare con il suo piano di trattamento o scegliere qualche altra opzione.
• Pochi mesi dopo, un sorriso hollywoodiano è tornato sul tuo viso. Sarebbe stato prima, ma non avresti potuto sorridere finché non avessi finalmente pagato per intero il conto per il tuo intervento dentistico.

A questo punto, anche il professionista di database più dedicato probabilmente non starà pensando, "Wow, vorrei che ci fosse un modello di dati per questa esperienza!" . Ma c'è, e vale la pena esaminarlo. Quindi l'abbiamo stampato di seguito.

Presentazione del nostro modello di database dello studio dentistico

L'idea alla base di questo modello è di coprire ogni procedura dal momento in cui entriamo per la prima volta nello studio del dentista fino alla risoluzione del problema. Parte di questo modello (le tabelle etichettate user_account , status , user_has_status , role , user_has_role ) è stato presentato e descritto nei precedenti articoli. Forse ruoli e status qui sembrano superflui, ma ricorda che lo studio potrebbe anche contenere un'infermiera per gestire l'anamnesi (registrazione), un receptionist, uno studente di odontoiatria, diversi assistenti dentali qualificati o persino uno specialista in visita o un igienista. Tuttavia, i dettagli di pagamento non verranno presi in considerazione in questo articolo.

Tabelle nel database dentale

Il patient table è una delle due tabelle più importanti nel database. Memorizza i dati dei pazienti ed è collegato ai documenti e alle visite dei pazienti. Ad eccezione di mail , tutti gli attributi nella tabella sono obbligatori:

• name – il nome del paziente
• surname – il cognome del paziente
• identification_number – questo campo viene utilizzato per memorizzare l'ID univoco di un cliente utilizzato nel mondo reale
• address – l'indirizzo del paziente
• phone – il numero di telefono del paziente
• mail – l'indirizzo e-mail del paziente

La seconda tabella più importante nel database è visit . In combinazione con la tabella patient , memorizza le informazioni sull'evento che ha attivato tutte le azioni successive. Gli attributi nella tabella sono:

• visit_date – contiene la data e l'ora effettive in cui si è verificata la visita
• patient_id – è l'ID del paziente relativo alla sua visita
• dentist_id – è un riferimento a user_has_role tavolo, assumendo che il ruolo sia dentista

La prossima è l'anamnesis tavolo. In medicina, l'anamnesi è una procedura in cui raccogliamo e memorizziamo la cronologia dei dati medici, come le condizioni attuali del paziente. L'anamnesis la tabella memorizza questi dati. Poiché ciò accade subito dopo il nostro arrivo in ufficio, avremo al massimo un'anamnesi per evento. Gli attributi nella tabella sono:

• anamnesis_id – è la chiave primaria dell'anamnesis tabella, che fa riferimento anche alla visit tabella
• user_anamnesis_id – questo si riferisce al user_has_role tavolo. Nota che il dentista non deve essere quello che ha fatto l'anamnesi.
• notes – contiene note di testo su un'anamnesi specifica. Non è un campo obbligatorio.

Il anamnesis_type table è un semplice dizionario utilizzato per memorizzare tutti i possibili valori a cui si fa riferimento in anamnesis_catalog . L'unico attributo è type_name , e può contenere valori come “malattia”, “allergia”, “medicina utilizzata”. Naturalmente, quell'unico attributo è obbligatorio.

Il anamnesis_catalog table è un dizionario che fornisce informazioni più specifiche rispetto ai valori memorizzati in anamnesis_type tavolo. Lo useremo per conservare i dati su malattie, allergie e farmaci specifici. Gli attributi sono tutti obbligatori e includono:

• catalog_name – è il nome di anamnesis_type sottocategoria
• anamnesis_type_id – è un riferimento al anamnesis_type tabella

Il visit_anamnesis la tabella viene utilizzata per collegare i dati della visita con i valori del catalogo dell'anamnesi. Ogni attributo nella tabella è obbligatorio:

• anamnesis_anamnesis_id – è un riferimento all'anamnesis tabella
• anamnesis_catalog_id – è un riferimento al anamnesis_catalog tabella

Nota che il visit_anamnesis table è una relazione molti-a-molti che collega le tabelle etichettate anamnesis e anamnesis_catalog . Non ha senso memorizzare questa coppia (anamnesis_anamnesis_id &anamnesis_catalog_id ) due volte. Useremo quella coppia come chiave primaria.

Il document table è un semplice catalogo contenente le posizioni in cui abbiamo salvato i documenti dei pazienti. Esempi di tali documenti possono essere scansioni di cartelle cliniche, radiografie e fatture dei pazienti. Ovviamente non salveremo questi documenti direttamente nel database. Questa è una grossolana semplificazione del sistema di gestione dei documenti. Gli attributi all'interno del document le tabelle sono (tutte obbligatorie):

• description – è una breve descrizione del documento
• location – contiene la posizione esatta del documento
• patient_id – è un riferimento al patient tabella

Il tooth table è un semplice dizionario che viene utilizzato in seguito quando il dentista specifica quale dente era il problema. Tutti gli attributi in questa tabella sono obbligatori. Sono:

• is_baby_tooth – è un valore booleano che indica semplicemente se un dente è un dente da latte o meno. Naturalmente, avremo valori duplicati per i denti che possono essere entrambi. Questo è importante perché una procedura può differire in base al tipo di dente.
• tooth – è una descrizione utilizzata per il lavoro svolto dal dente – in genere, quel valore verrà mostrato sullo schermo.

Il problem_catalog table è un altro semplice dizionario. Contiene un elenco di tutti i possibili problemi che normalmente si trovano sui denti o in bocca. Esempi di valori possibili per questo catalogo sono:“carie”, “erosione dei denti”, “gengiviti”, “piaghe della bocca” o “sorriso poco attraente”. Solo il problem_name l'attributo è obbligatorio.

Il problem_detected la tabella collega i dati del catalogo di visite, denti e problemi con il treatment tavolo. Contiene riferimenti al tooth , problem_catalog e visit tavoli. Tutti gli attributi sono obbligatori tranne tooth_id . Il motivo di questa eccezione è che alcuni problemi non si riferiscono a un solo dente (ad es. la gengivite si riferisce alle gengive). Questi tre attributi insieme formano una chiave alternativa (UNICA). Gli altri due attributi sono:

• suggested_treatment_id è un riferimento al treatment lettino (il trattamento suggerito dal dentista). Può essere un valore NULL quando tutto è a posto e non abbiamo bisogno di alcun trattamento.
• selected_treatment_id è un altro riferimento al treatment tavolo. Contiene dati sul trattamento che il dentista e il paziente hanno accettato di utilizzare. Questo può essere NULLO, forse perché il paziente ha bisogno di tempo per pensare al trattamento suggerito e ad altre possibilità.

Nota che gli attributi suggested_treatment_id e selected_treatment_id sono entrambi riferiti al treatment tavolo. Possiamo farlo perché abbiamo solo bisogno di memorizzare, al massimo, due valori. Naturalmente, se non sappiamo in anticipo quanti valori vogliamo memorizzare, dovremmo usare qui una relazione molti-a-molti.

Il step table è un semplice dizionario che contiene tutti i possibili passaggi di tutti i trattamenti. Gli attributi (tutti obbligatori) nella tabella sono:

• step_name – è un nome di un breve passaggio utilizzato sullo schermo
• description – è una descrizione delle azioni intraprese durante questo passaggio

Il treatment table è infatti un dizionario di tutti i trattamenti che lo studio dentistico mette a disposizione. Poiché la maggior parte dei trattamenti di solito consiste in diversi passaggi, dobbiamo sapere quale passaggio è definitivo. Gli attributi nella tabella sono tutti obbligatori:

• treatment_name – è il nome del trattamento all'interno del sistema
• description – è una breve descrizione del trattamento
• final_step_id – è un riferimento al step tavolo. Possiamo utilizzare queste informazioni per rilevare se il trattamento è terminato e avviare un'azione automatica, oppure possiamo semplicemente mostrare tali informazioni all'utente e lasciargli scegliere l'azione successiva.

I treatment_steps table è una relazione molti-a-molti che collega i passaggi con i trattamenti. Gli attributi obbligatori nella tabella sono:

• treatment_id – è un riferimento al treatment tabella
• step_id – è un riferimento al step tabella
• step_order – è un numero che definisce l'ordine delle fasi del trattamento

In questa tabella sono definite due chiavi alternative (UNIQUE):

• coppia (treatment_id &step_id ) – questo passaggio può essere assegnato al trattamento una sola volta
• coppia (treatment_id &step_order ) – il trattamento non può avere due fasi con lo stesso numero d'ordine

I visit_steps tabella è un elenco di tutti i passaggi effettivamente eseguiti dopo quella visita. Ci sono due ragioni per cui vogliamo archiviarli in tabelle separate:

1. Potremmo aver scelto un trattamento, ma non abbiamo bisogno di tutti i passaggi definiti per esso e
2. In questo modo, memorizzeremo l'ora effettiva in cui è stato eseguito il passaggio.

Gli attributi nella tabella (tutti sono obbligatori tranne problem_detected_id e notes ) sono i seguenti:

• visit_id – è un riferimento alla visit tabella
• treatment_steps_id – è un riferimento ai treatment_steps tabella
• problem_detected_id – è un riferimento al problem_detected tavolo. Questa relazione ci fornisce informazioni su quale problema ha avviato quell'azione. Può essere NULL quando il dentista decide di intraprendere un'azione che non è correlata ad alcun problema rilevato.
• step_time – è la data e/o l'ora in cui il passaggio è stato effettivamente eseguito
• notes – sono note per quel passaggio, se necessario

Il visit_status table è un semplice dizionario utilizzato per memorizzare tutti i possibili stati che una visita potrebbe avere. Potremmo utilizzare stati come "prima visita in studio in assoluto", "prima visita", "trattamento in corso", "trattamento terminato con successo". Contiene un solo attributo, status_name , che è obbligatorio.

Il visit_status_history la tabella viene utilizzata per memorizzare i dati sugli stati che ha attraversato la visita. Il pensiero è che aggiungiamo lo stato manualmente dopo che alcune azioni sono state completate (ad esempio dopo l'anamnesi, dopo aver terminato alcuni passaggi di un trattamento). Gli attributi, tutti obbligatori, seguono:

• status_time – è la data/ora in cui è stato inserito lo stato
• visit_status_id – è un riferimento al visit_status tabella
• visit_id – è un riferimento alla visit tabella

Possibili miglioramenti al modello di database dentale

Il nostro modello è partito bene, ma potrebbe essere migliorato. Ad esempio, non copre i seguenti elementi:

• modalità di pagamento e fatture
• pianificazione delle riunioni (sebbene ciò possa essere fatto inserendo i dati in visit_steps tabella per eventi futuri)
• Gestione documenti

Tuttavia, ti fa pensare in modo diverso al tuo studio dentistico e alle sue procedure, vero?