Modelado de bases de datos

Escribí una canción sobre el hilo dental, pero ¿a alguien le quedaron más limpios los dientes?

Frank Zappa

Cuando pensamos en el consultorio dental, nuestras primeras asociaciones son el taladro, el dolor y el miedo. Está bien, eso suena mal. Además de cuidar los dientes, un dentista tiene muchas otras obligaciones que son profesionales, legales o ambas. Todos ellos requieren una adecuada gestión de datos.

Para cumplir con este requisito de documentación, muchos consultorios dentales y médicos utilizan registros en papel. Sin embargo, de manera lenta pero segura, hay una tendencia hacia los registros digitales y la gestión del siglo XXI.

Dentro de la Oficina de Medicina Dental

Ir al dentista no es algo que solemos recordar con alegría. Si tuvimos suerte, esquivamos el dolor, pero nuestra billetera probablemente sufrió mucho. Después de ingresar al consultorio de un dentista, el procedimiento suele ser el siguiente:

• Ambos entablan una breve charla. (A menudo desagradable porque le prometiste a tu dentista que lo visitarías la próxima semana y han pasado 2 años. Luego dices que lo olvidaste, él acepta y todo vuelve a estar bien).
• Te sientas en la silla mientras él mira tus registros de tratamientos anteriores. Pregunta si sucedió algo desde la última visita y si hay alguna actualización en su expediente médico.
• Él echa un vistazo dentro de tu boca para determinar qué salió mal y te dice qué lo solucionará.
• Puedes estar de acuerdo con su plan de tratamiento o elegir alguna otra opción.
• Unos meses después, una sonrisa de Hollywood vuelve a aparecer en tu rostro. Habría sido antes, pero no pudo sonreír hasta que finalmente pagó la factura total de su trabajo dental.

En este punto, incluso el profesional de bases de datos más dedicado probablemente no esté pensando:‘¡Guau, me gustaría que hubiera un modelo de datos para esta experiencia!’ . Pero lo hay, y vale la pena examinarlo. Así que lo hemos impreso a continuación.

Presentamos nuestro modelo de base de datos de consultorios dentales

La idea detrás de este modelo es cubrir todos los procedimientos desde el momento en que ingresamos por primera vez al consultorio del dentista hasta que se soluciona el problema. Parte de este modelo (las tablas etiquetadas como user_account , status , user_has_status , role , user_has_role ) fue presentado y descrito en artículos anteriores. Tal vez los roles y los estados parezcan innecesarios aquí, pero recuerde que la práctica también podría incluir una enfermera para manejar la anamnesis (registro), una recepcionista, un estudiante de odontología, varios asistentes dentales capacitados o incluso un especialista visitante o un higienista. Sin embargo, los detalles de pago no se considerarán en este artículo.

Tablas en la Base de Datos Dental

El patient table es una de las dos tablas más importantes en la base de datos. Almacena los datos de los pacientes y está conectado a los documentos y visitas de los pacientes. Con la excepción de mail , todos los atributos de la tabla son obligatorios:

• name – el nombre del paciente
• surname – el apellido del paciente
• identification_number – este campo se usa para almacenar la identificación única de un cliente que se usa en el mundo real
• address – la dirección del paciente
• phone – el número de teléfono del paciente
• mail – la dirección de correo del paciente

La segunda tabla más importante en la base de datos es visit . Cuando se combina con la mesa patient , almacena información sobre el evento que desencadenó todas las acciones posteriores. Los atributos en la tabla son:

• visit_date – contiene la fecha y la hora reales en que se produjo la visita
• patient_id – es la identificación del paciente relacionada con su visita
• dentist_id – es una referencia a user_has_role mesa, asumiendo que el papel es dentista

El siguiente paso es la anamnesis mesa. En medicina, la anamnesis es un procedimiento donde recopilamos y almacenamos el historial de datos médicos, como la condición actual del paciente. La anamnesis tabla almacena estos datos. Dado que esto sucede poco después de nuestra llegada a la oficina, tendremos como máximo una anamnesis por evento. Los atributos en la tabla son:

• anamnesis_id – es la clave principal de la anamnesis tabla, que también hace referencia a la visit mesa
• user_anamnesis_id – esto se relaciona con el user_has_role mesa. Tenga en cuenta que el dentista no tiene que ser el que hizo la anamnesis.
• notes – contiene notas de texto sobre anamnesis específicas. No es un campo obligatorio.

El anamnesis_type table es un diccionario simple que se utiliza para almacenar todos los valores posibles a los que se hace referencia en anamnesis_catalog . El único atributo es type_name , y puede contener valores como “enfermedad”, “alergia”, “medicamento utilizado”. Por supuesto, ese único atributo es obligatorio.

El anamnesis_catalog table es un diccionario que brinda información más específica que los valores almacenados en el anamnesis_type mesa. Lo usaremos para guardar datos sobre enfermedades, alergias y medicamentos específicos. Todos los atributos son obligatorios e incluyen:

• catalog_name – es el nombre de anamnesis_type subcategoría
• anamnesis_type_id – es una referencia al anamnesis_type mesa

La visit_anamnesis La tabla se utiliza para conectar los datos de visita con los valores del catálogo de anamnesis. Todos los atributos de la tabla son obligatorios:

• anamnesis_anamnesis_id – es una referencia a la anamnesis mesa
• anamnesis_catalog_id – es una referencia al anamnesis_catalog mesa

Tenga en cuenta que visit_anamnesis table es una relación de muchos a muchos que conecta las tablas etiquetadas como anamnesis y anamnesis_catalog . No tiene sentido almacenar este par (anamnesis_anamnesis_id &anamnesis_catalog_id ) dos veces. Usaremos ese par como clave principal.

El document table es un catálogo simple que contiene las ubicaciones donde hemos guardado los documentos de los pacientes. Ejemplos de dichos documentos pueden ser escaneos de las historias clínicas de los pacientes, radiografías y facturas. Por supuesto, no guardaremos estos documentos directamente en la base de datos. Esta es una ruda simplificación del sistema de gestión de documentos. Los atributos dentro del document tabla son (todos son obligatorios):

• description – es una breve descripción del documento
• location – contiene la ubicación exacta del documento
• patient_id – es una referencia al patient mesa

El tooth table es un diccionario simple que se usa más tarde cuando el dentista especifica qué diente era el problema. Todos los atributos de esta tabla son obligatorios. Ellos son:

• is_baby_tooth – es un valor booleano que simplemente marca si un diente es un diente de leche o no. Por supuesto, tendremos valores duplicados para dientes que pueden ser ambos. Esto es importante porque un procedimiento puede diferir según el tipo de diente.
• tooth – es una descripción utilizada para el trabajo del diente; por lo general, ese valor se mostrará en la pantalla.

El problem_catalog table es otro diccionario simple. Contiene una lista de todos los posibles problemas que normalmente se encuentran en los dientes o en la boca. Ejemplos de valores posibles para este catálogo son:“caries”, “erosión dental”, “gingivitis”, “llagas en la boca” o “sonrisa poco atractiva”. Solo el problem_name el atributo es obligatorio.

El problem_detected La tabla conecta los datos del catálogo de visitas, dientes y problemas con el treatment mesa. Contiene referencias al tooth , problem_catalog y visit mesas. Todos los atributos son obligatorios excepto tooth_id . El motivo de esta excepción es que algunos problemas no se refieren a un solo diente (por ejemplo, la gingivitis se refiere a las encías). Estos tres atributos juntos forman una clave alternativa (ÚNICA). Los otros dos atributos son:

• suggested_treatment_id es una referencia al treatment mesa (el tratamiento sugerido por el dentista). Puede ser un valor NULL cuando todo está bien y no necesitamos ningún tratamiento.
• selected_treatment_id es otra referencia al treatment mesa. Contiene datos sobre el tratamiento que el dentista y el paciente acordaron usar. Esto puede ser NULL, quizás porque el paciente necesita tiempo para pensar en el tratamiento sugerido y otras posibilidades.

Tenga en cuenta que los atributos suggested_treatment_id y selected_treatment_id ambos se refieren al treatment mesa. Podemos hacer esto porque solo necesitamos almacenar, como máximo, dos valores. Por supuesto, si no sabemos de antemano cuántos valores queremos almacenar, entonces deberíamos usar una relación de muchos a muchos aquí.

El step table es un diccionario simple que contiene todos los pasos posibles en todos los tratamientos. Los atributos (todos son obligatorios) en la tabla son:

• step_name – es un nombre de paso corto que se usa en pantalla
• description – es una descripción de las acciones realizadas durante este paso

El treatment table es, de hecho, un diccionario de todos los tratamientos que ofrece el consultorio dental. Dado que la mayoría de los tratamientos suelen constar de varios pasos, debemos saber cuál es el paso final. Todos los atributos de la tabla son obligatorios:

• treatment_name – es el nombre del tratamiento dentro del sistema
• description – es una breve descripción del tratamiento
• final_step_id – es una referencia al step mesa. Podemos usar esta información para detectar si el tratamiento ha terminado e iniciar una acción automática, o simplemente podemos mostrar esa información al usuario y permitirle elegir la siguiente acción.

Los treatment_steps table es una relación de muchos a muchos que conecta pasos con tratamientos. Los atributos obligatorios en la tabla son:

• treatment_id – es una referencia al treatment mesa
• step_id – es una referencia al step mesa
• step_order – es un número que define el orden de los pasos en el tratamiento

En esta tabla se definen dos claves alternativas (ÚNICAS):

• par (treatment_id &step_id ) – este paso se puede asignar al tratamiento solo una vez
• par (treatment_id &step_order ) – el tratamiento no puede tener dos pasos con el mismo número de orden

Los visit_steps La tabla es una lista de todos los pasos que realmente se llevaron a cabo después de esa visita. Hay dos razones por las que queremos almacenarlos en tablas separadas:

1. Es posible que hayamos elegido un tratamiento, pero no necesitamos todos los pasos definidos para ello, y
2. De esta manera, almacenaremos la hora real en que se realizó el paso.

Los atributos en la tabla (todos son obligatorios excepto problem_detected_id y notes ) son los siguientes:

• visit_id – es una referencia a la visit mesa
• treatment_steps_id – es una referencia a los treatment_steps mesa
• problem_detected_id – es una referencia al problem_detected mesa. Esta relación nos da información sobre qué problema inició esa acción. Puede ser NULL cuando el odontólogo decide realizar alguna acción que no está relacionada con ningún problema detectado.
• step_time – es la fecha y/o la hora en que se realizó realmente el paso
• notes – son notas para ese paso, si es necesario

El visit_status table es un diccionario simple que se utiliza para almacenar todos los estados posibles que podría tener una visita. Podríamos usar estados como "primera visita al consultorio", "primera visita", "tratamiento en curso", "tratamiento finalizado con éxito". Contiene solo un atributo, status_name , que es obligatorio.

El visit_status_history La tabla se utiliza para almacenar datos sobre los estados por los que pasó la visita. La idea es que agreguemos el estado manualmente después de que se completen ciertas acciones (por ejemplo, después de la anamnesis, después de terminar algunos pasos de algún tratamiento). Los atributos, todos los cuales son obligatorios, siguen:

• status_time – es la fecha/hora en que se insertó el estado
• visit_status_id – es una referencia al visit_status mesa
• visit_id – es una referencia a la visit mesa

Posibles mejoras al modelo de base de datos dental

Nuestro modelo ha tenido un buen comienzo, pero podría mejorarse. Por ejemplo, no cubre los siguientes elementos:

• métodos de pago y facturas
• programar reuniones (aunque esto podría hacerse insertando datos en el visit_steps tabla para eventos futuros)
• manejo de documentos

Aún así, te hace pensar diferente sobre tu consultorio dental y sus procedimientos, ¿no es así?