Modélisation de base de données

J'ai écrit une chanson sur le fil dentaire, mais les dents de quelqu'un sont-elles devenues plus propres ?

Frank Zappa

Lorsque nous pensons au cabinet dentaire, nos premières associations sont la perceuse, la douleur et la peur. OK, ça sonne mal. En plus de prendre soin de ses dents, un dentiste a de nombreuses autres obligations professionnelles, légales ou les deux. Tous nécessitent une gestion appropriée des données.

Pour répondre à cette exigence de documentation, de nombreux cabinets dentaires et médicaux utilisent des dossiers papier. Lentement mais sûrement, cependant, il y a une tendance vers les documents numériques et la gestion du 21e siècle.

À l'intérieur du Bureau de médecine dentaire

Aller chez le dentiste n'est pas quelque chose dont nous nous souvenons habituellement avec joie. Si nous avons eu de la chance, nous avons esquivé la douleur, mais notre portefeuille a probablement beaucoup souffert. Une fois que nous sommes entrés dans le cabinet d'un dentiste, la procédure est généralement la suivante :

Vous vous engagez tous les deux dans une courte conversation. (Souvent désagréable parce que vous avez promis à votre dentiste de lui rendre visite la semaine prochaine et que 2 ans se sont écoulés. Ensuite, vous dites que vous avez oublié, il accepte et tout va bien à nouveau.)
Vous vous asseyez sur la chaise pendant qu'il regarde vos dossiers de traitement précédents. Il demande si quelque chose s'est passé depuis la dernière visite et s'il y a une mise à jour de votre dossier médical.
Il regarde à l'intérieur de votre bouche pour déterminer ce qui ne va pas et vous dit ce qui va le réparer.
Vous pouvez accepter son plan de traitement ou choisir une autre option.
Quelques mois plus tard, un sourire hollywoodien est de nouveau sur votre visage. Cela aurait été plus tôt, mais vous ne pouviez pas sourire tant que vous n'aviez pas finalement payé l'intégralité de la facture de vos soins dentaires.

À ce stade, même le professionnel des bases de données le plus dévoué ne pense probablement pas :"Wow, j'aimerais qu'il y ait un modèle de données pour cette expérience !" . Mais il y en a, et cela vaut la peine d'être examiné. Nous l'avons donc imprimé ci-dessous.

Présentation de notre modèle de base de données de cabinet dentaire

L'idée derrière ce modèle est de couvrir chaque procédure à partir du moment où nous entrons pour la première fois dans le cabinet du dentiste jusqu'à ce que le problème soit résolu. Une partie de ce modèle (les tables étiquetées user_account , status , user_has_status , role , user_has_role ) a été présenté et décrit dans des articles précédents. Peut-être que les rôles et les statuts semblent inutiles ici, mais rappelez-vous que la pratique pourrait également contenir une infirmière pour gérer l'anamnèse (prise de dossier), une réceptionniste, un étudiant en médecine dentaire, plusieurs assistantes dentaires formées, ou même un spécialiste visiteur ou un hygiéniste. Cependant, les détails de paiement ne seront pas pris en compte dans cet article.

Tableaux de la base de données dentaire

Le patient table est l'une des deux tables les plus importantes de la base de données. Il stocke les données des patients et est connecté aux documents et aux visites des patients. A l'exception de mail , tous les attributs du tableau sont obligatoires :

name – le nom du patient
surname – le nom de famille du patient
identification_number – ce champ est utilisé pour stocker l'identifiant unique d'un client qui est utilisé dans le monde réel
address – l'adresse du patient
phone – le numéro de téléphone du patient
mail – l'adresse mail du patient

La deuxième table la plus importante dans la base de données est visit . Lorsqu'il est combiné avec le tableau patient , il stocke des informations sur l'événement qui a déclenché toutes les actions suivantes. Les attributs du tableau sont :

visit_date – contient la date et l'heure réelles de la visite
patient_id – est l'identifiant du patient lié à sa visite
dentist_id – est une référence à user_has_role table, en supposant que le rôle est dentiste

La prochaine étape est l'anamnesis table. En médecine, l'anamnèse est une procédure où nous collectons et stockons l'historique des données médicales, telles que l'état actuel du patient. L'anamnesis table stocke ces données. Comme cela se produit peu de temps après notre arrivée au bureau, nous aurons au maximum une anamnèse par événement. Les attributs du tableau sont :

anamnesis_id – est la clé primaire de l'anamnesis table, qui fait également référence à la visit tableau
user_anamnesis_id – cela concerne le user_has_role table. Notez que le dentiste n'a pas à être celui qui a fait l'anamnèse.
notes – contient des notes de texte sur l'anamnèse spécifique. Ce n'est pas un champ obligatoire.

Le anamnesis_type table est un simple dictionnaire utilisé pour stocker toutes les valeurs possibles qui sont référencées dans anamnesis_catalog . Le seul attribut est type_name , et il peut contenir des valeurs telles que "maladie", "allergie", "médicament utilisé". Bien sûr, ce seul attribut est obligatoire.

Le anamnesis_catalog table est un dictionnaire qui donne des informations plus spécifiques que les valeurs stockées dans le anamnesis_type table. Nous l'utiliserons pour conserver des données sur des maladies, des allergies et des médicaments spécifiques. Les attributs sont tous obligatoires et incluent :

catalog_name – est le nom de anamnesis_type sous-catégorie
anamnesis_type_id – est une référence au anamnesis_type tableau

Le visit_anamnesis table est utilisée pour relier les données de visite aux valeurs du catalogue d'anamnèse. Chaque attribut du tableau est obligatoire :

anamnesis_anamnesis_id – est une référence à l'anamnesis tableau
anamnesis_catalog_id – est une référence au anamnesis_catalog tableau

Notez que le visit_anamnesis table est une relation plusieurs-à-plusieurs reliant les tables étiquetées anamnesis et anamnesis_catalog . Il est inutile de stocker ce couple (anamnesis_anamnesis_id &anamnesis_catalog_id ) à deux reprises. Nous utiliserons cette paire comme clé primaire.

Le document table est un simple catalogue contenant les emplacements où nous avons enregistré les documents des patients. Des exemples de tels documents peuvent être des scans des dossiers des patients, des radiographies et des factures. Bien sûr, nous n'enregistrerons pas ces documents directement dans la base de données. Il s'agit d'une simplification grossière du système de gestion de documents. Les attributs du document table sont (tous sont obligatoires) :

description – est une brève description du document
location – contient l'emplacement exact du document
patient_id – est une référence au patient tableau

La tooth Le tableau est un dictionnaire simple qui est utilisé plus tard lorsque le dentiste précise quelle dent était le problème. Tous les attributs de ce tableau sont obligatoires. Ce sont :

is_baby_tooth – est une valeur booléenne qui indique simplement si une dent est une dent de lait ou non. Bien sûr, nous aurons des valeurs en double pour les dents qui peuvent être les deux. Ceci est important car une procédure peut différer selon le type de dent.
tooth – est une description utilisée pour la dent qui fait le travail – généralement, cette valeur sera affichée à l'écran.

Le problem_catalog table est un autre dictionnaire simple. Il contient une liste de tous les problèmes possibles que l'on trouve normalement sur les dents ou dans la bouche. Des exemples de valeurs possibles pour ce catalogue sont :« carie dentaire », « érosion dentaire », « gingivite », « plaies buccales » ou « sourire peu attrayant ». Seul le problem_name l'attribut est obligatoire.

Le problem_detected le tableau relie les données du catalogue de visites, de dents et de problèmes avec le treatment table. Il contient des références à la tooth , problem_catalog et visit les tables. Tous les attributs sont obligatoires sauf tooth_id . La raison de cette exception est que certains problèmes ne se réfèrent pas à une seule dent (par exemple, la gingivite se réfère aux gencives). Ces trois attributs forment ensemble une clé alternative (UNIQUE). Les deux autres attributs sont :

suggested_treatment_id est une référence au treatment table (le traitement proposé par le dentiste). Il peut s'agir d'une valeur NULL lorsque tout va bien et que nous n'avons besoin d'aucun traitement.
selected_treatment_id est une autre référence au treatment table. Il contient des données sur le traitement que le dentiste et le patient ont accepté d'utiliser. Cela peut être NULL, peut-être parce que le patient a besoin de temps pour réfléchir au traitement suggéré et à d'autres possibilités.

Notez que les attributs suggested_treatment_id et selected_treatment_id sont tous deux référencés au treatment table. Nous pouvons le faire car nous n'avons besoin de stocker que deux valeurs au maximum. Bien sûr, si nous ne savons pas à l'avance combien de valeurs nous voulons stocker, nous devrions utiliser ici une relation plusieurs à plusieurs.

L'step table est un simple dictionnaire contenant toutes les étapes possibles dans tous les traitements. Les attributs (tous obligatoires) du tableau sont :

step_name – est un nom de pas court utilisé à l'écran
description – est une description des actions entreprises au cours de cette étape

Le treatment table est en fait un dictionnaire de tous les traitements que le cabinet dentaire dispense. Étant donné que la plupart des traitements consistent généralement en plusieurs étapes, nous devons savoir quelle étape est finale. Les attributs du tableau sont tous obligatoires :

treatment_name – est le nom du traitement dans le système
description – est une courte description du traitement
final_step_id – est une référence à l'step table. Nous pouvons utiliser ces informations pour détecter si le traitement est terminé et lancer une action automatique, ou nous pouvons simplement montrer ces informations à l'utilisateur et le laisser choisir l'action suivante.

Les treatment_steps table est une relation plusieurs-à-plusieurs qui relie les étapes aux traitements. Les attributs obligatoires dans le tableau sont :

treatment_id – est une référence au treatment tableau
step_id – est une référence à l'step tableau
step_order – est un nombre qui définit l'ordre des étapes du traitement

Dans ce tableau deux clés alternatives (UNIQUE) sont définies :

paire (treatment_id &step_id ) – cette étape ne peut être attribuée au traitement qu'une seule fois
paire (treatment_id &step_order ) – le traitement ne peut pas avoir deux étapes avec le même numéro de commande

Les visit_steps Le tableau est une liste de toutes les étapes qui ont été effectivement réalisées après cette visite. Il y a deux raisons pour lesquelles nous voulons les stocker dans des tables séparées :

Nous avons peut-être choisi un traitement, mais nous n'avons pas besoin de toutes les étapes définies pour celui-ci, et
De cette façon, nous enregistrerons l'heure réelle à laquelle l'étape a été effectuée.

Les attributs du tableau (tous sont obligatoires sauf problem_detected_id et notes ) sont les suivants :

visit_id – est une référence à la visit tableau
treatment_steps_id – est une référence aux treatment_steps tableau
problem_detected_id – est une référence au problem_detected table. Cette relation nous donne des informations sur le problème qui a initié cette action. Il peut être NULL lorsque le dentiste décide de prendre des mesures qui ne sont liées à aucun problème détecté.
step_time – est la date et/ou l'heure à laquelle l'étape a été effectivement réalisée
notes – sont des notes pour cette étape, si nécessaire

Le visit_status table est un simple dictionnaire utilisé pour stocker tous les statuts possibles qu'une visite pourrait avoir. Nous pourrions utiliser des statuts tels que "première visite au cabinet", "première visite", "traitement en cours", "traitement terminé avec succès". Il ne contient qu'un seul attribut, status_name , qui est obligatoire.

Le visit_status_history La table est utilisée pour stocker des données sur les statuts par lesquels la visite est passée. L'idée est que nous ajoutons le statut manuellement une fois certaines actions terminées (par exemple, après l'anamnèse, après avoir terminé quelques étapes d'un traitement). Les attributs, qui sont tous obligatoires, suivent :

status_time – est la date/heure à laquelle le statut a été inséré
visit_status_id – est une référence au visit_status tableau
visit_id – est une référence à la visit tableau

Améliorations possibles du modèle de base de données dentaire

Notre modèle est bien parti, mais il pourrait être amélioré. Par exemple, il ne couvre pas les éléments suivants :

modes de paiement et factures
planifier des réunions (bien que cela puisse être fait en insérant des données dans le visit_steps tableau pour les événements futurs)
gestion des documents

Pourtant, cela vous fait penser différemment votre cabinet dentaire et ses procédures, n'est-ce pas ?