Un modelo de datos para realizar un seguimiento de su posesión más preciada

Estar saludable y en forma es un estilo de vida, no una moda pasajera. Las personas que se dan cuenta del valor de la salud la convierten en una prioridad y mantienen registros de todos sus datos relacionados con el estado físico. En este artículo, examinaremos el diseño de la base de datos detrás de una aplicación de salud y fitness.

Existen muchas aplicaciones que permiten a los usuarios registrar su información de salud y estado físico. Un par de grandes jugadores como Apple, Google y Microsoft han lanzado sus propias API de desarrollo específicamente para este mercado. Por ejemplo, Google tiene 'Fit' y Microsoft tiene 'HealthVault'.

En este artículo, explicaré el modelo de datos detrás de una aplicación de registros de salud. Primero, analicemos exactamente lo que esperaríamos que hiciera una aplicación de este tipo.

Requisitos del proyecto para una aplicación de información de salud

A continuación se presentan algunas funciones que una aplicación de información de salud debería admitir:

• Los usuarios pueden crear una cuenta y almacenar información de salud para múltiples perfiles, es decir, un individuo puede almacenar información de salud para todos los miembros de su familia.
• Los usuarios pueden registrar todo su historial de salud, incluidas vacunas, resultados de laboratorio anteriores, alergias e historial médico familiar .
• Los usuarios pueden almacenar varias medidas de salud y estado físico, como niveles de glucosa en sangre (azúcar en sangre), presión arterial, composición corporal y dimensiones, incluido el índice de masa corporal (IMC), colesterol, altura, peso, salud reproductiva, etc.
• La información se puede registrar usando varios métodos y unidades de medida . Por ejemplo, la glucosa en sangre se puede medir en mg/dl o mmol/l.
• No hay límites sobre la cantidad de información que los usuarios pueden almacenar.
• El sistema también mantendrá los estándares de salud aceptados, como la presión arterial o los números de IMC, y alertará a los usuarios si sus números están fuera de los rangos "seguros" o "normales".
• Los usuarios también pueden elegir información (como glucosa en sangre, altura, peso, etc.) para mostrar en su tablero personal. De esta manera, pueden monitorear lo que necesiten.

En lugar de simplemente explicar qué hace cada sección y tabla en el modelo de datos, respondamos algunas preguntas al respecto. La función de las distintas tablas se aclarará a medida que avancemos.

Primero, puede ver el modelo de datos completo si lo desea.

El modelo de datos

Respondiendo preguntas sobre el modelo de datos de información de salud

¿Cómo pueden los usuarios almacenar la información de salud de todos los miembros de su familia individualmente?

Primero, hablemos de Gestión de cuentas y perfiles . Esto se puede lograr teniendo dos mesas diferentes; uno (user_account ) para registrar los detalles de las personas que se registran en la aplicación, y uno (user_profile ) para registrar detalles de todos los diferentes perfiles que crea un usuario registrado. Las personas pueden crear una serie de perfiles, p. uno para cada uno de los miembros de su familia.

Veamos las diversas tablas que hacen esto posible.

La user_account La tabla contiene detalles básicos sobre la persona que se registra en la aplicación. Sus columnas son:

• id –Una columna de clave sustituta para esta tabla que identifica a cada usuario de forma única.
• login_name – El nombre u otra identificación que el usuario elija como su nombre de inicio de sesión. Se debe imponer una restricción única en esta columna para garantizar que cada nombre de inicio de sesión sea diferente.
• enc_password – La contraseña de la cuenta seleccionada por el usuario, en forma cifrada.
• columnas de dirección – Almacena la dirección y los datos de contacto de los usuarios en el momento del registro. Estas columnas incluyen street_address , city , state , country y zip . Dado que estos campos son opcionales en el proceso de registro, mantuve estas columnas como anulables.
• contact_number y email – Almacena el número de contacto del usuario (es decir, el número de teléfono) y su dirección de correo electrónico. Estos campos también forman parte del proceso de registro, pero no se pueden anular.
• is_active – Contiene una 'Y' o una 'N' para indicar si una cuenta está actualmente activa.
• account_image – Los usuarios pueden cargar sus propias imágenes. Dado que un usuario puede cargar cero o (como máximo) una imagen por cuenta, esta es una columna de tipo BLOB que acepta valores NULL.

El user_profile tabla almacena detalles de todos los perfiles creados por usuarios registrados. Las columnas de esta tabla son:

• id – Un número único asignado a cada nuevo perfil.
• user_account_id – Indica qué usuario creó el perfil.
• user_profile_name – Almacena el nombre de la persona en el perfil. (Llamamos a esta persona la "persona del perfil" y al usuario que crea los perfiles el "titular de la cuenta".)
• relationship_id – Indica la relación entre el titular de la cuenta y la persona del perfil. Esta columna hace referencia a la relationship tabla, que contiene todos los tipos posibles de relaciones (como self , madre , padre , hermana , hermano , hijo , hija , mascota , etc.).
• email – Esta columna contiene la dirección de correo electrónico de la persona del perfil. Los informes u otra información se compartirán con ellos a través de este correo electrónico; la información también sería enviada al titular de la cuenta. Por ejemplo, si Melissa creó un perfil para su hija Eva, la información de Eva se enviaría al correo electrónico de Melissa y posiblemente al correo electrónico de Eva; consulte a continuación.
• is_report_sharing_enabled – Los informes siempre se comparten con el titular de la cuenta, pero es opcional compartir estos datos con la persona del perfil. Esta columna muestra si la información se compartirá con la persona del perfil.
• is_active – Identifica si un perfil está actualmente activo. Esta es una función de eliminación temporal en caso de que los perfiles se eliminen accidentalmente.
• profile_image – Almacena una imagen de la persona del perfil. Este atributo es opcional y, por lo tanto, anulable.

Los characteristic_data La tabla contiene detalles del perfil individual (como el grupo sanguíneo) que nunca cambian con el tiempo. Todas las columnas de esta tabla se explican por sí mismas excepto fitzpatrick_skin_type , que clasifica la naturaleza de la piel desde I (siempre se quema, nunca se broncea) hasta VI (nunca se quema, no cambia de apariencia cuando se broncea).

He agregado dos columnas para género; biological_gender significa el género de uno en el momento del nacimiento, y current_gender significa el sexo actual de la persona del perfil. Esta segunda columna solo se aplica a las personas transgénero y, por lo tanto, la he mantenido anulable.

¿Qué información vital se puede almacenar en este sistema? ¿Cómo se almacena?

Ahora pasamos a Gestión de datos de salud . La composición corporal, los niveles de glucosa en sangre y las dimensiones corporales se almacenan en tablas separadas. Sin embargo, las personas pueden ingresar más de un tipo de información a la vez, por lo que usamos el body_vitals_log tabla para realizar un seguimiento de qué información se registra en un perfil y cuándo se ingresa.

Todas las estadísticas vitales se mantienen en las siguientes tablas:

• body_composition – Almacena detalles sobre varios porcentajes de composición corporal como grasa, masa magra, hueso o agua. También contiene valores de IMC (índice de masa corporal) para individuos.
• blood_cholesterol – Contiene detalles de colesterol como LDL, HDL, triglicéridos y total.
• body_dimension – Registra las dimensiones de varias áreas del cuerpo, como las medidas de la cintura o el pecho.
• body_weight – Almacena valores para el peso corporal.
• body_height – Contiene valores para la altura de una persona.
• blood_pressure – Contiene números de presión arterial (sistólica y diastólica).
• blood_glucose – Registra los niveles de glucosa en sangre.

La mayoría de las columnas de las tablas anteriores se explican por sí mismas, con algunas excepciones. Notará algunas columnas adicionales como measurement_method_id , compare_to_normal_id , measurement_unit_id y measurement_context en casi cada una de estas mesas. Explicaré estas columnas más adelante.

El body_vitals_log realiza un seguimiento de qué información se registra en un momento dado para un perfil. Las columnas de esta tabla son:

• user_profile_id – Muestra qué perfil está registrando la información.
• dt_created – Almacena la fecha y la hora en que se ingresa la información.
• data_source_id – Significa la fuente de los datos, como un manual, un dispositivo electrónico, etc.
• IDs de varias estadísticas vitales – He mantenido todas estas columnas anulables, ya que los usuarios pueden registrar uno o más elementos a la vez. No todos los usuarios querrán seguir las mismas estadísticas de salud.

¿Cómo podemos hacer que el sistema funcione en diferentes regiones?

Cierta información se mide en diferentes unidades en varias áreas. Por ejemplo, el peso corporal se mide en kilogramos en Asia, pero se mide en libras en América del Norte. Entonces, para que esto funcione en nuestra base de datos, necesitamos una forma de rastrear las unidades de medida.

• id – Sirve como la clave principal de esta tabla, y es a la que se refieren otras tablas.
• measurement_parameter – Significa el tipo de información vital (como peso, altura, presión arterial, etc.) que mide una unidad.
• unit_name – Almacena el nombre de la unidad. Piense en kilogramo y libra para peso, mg/dL y mmol/L para glucosa en sangre.

¿Cómo sabrá la gente si sus números son buenos?

Nuestro sistema no es de mucha ayuda a menos que alerte a las personas sobre los riesgos o vulnerabilidades para la salud. Habilitamos esta función agregando comparison_to_normal_id columna en todas las tablas de datos de información vital.

Cuando se registre nueva información vital en el sistema, los registros se compararán con sus valores de referencia correspondientes y esta columna se establecerá en consecuencia.

Los valores posibles para esta tabla son:

¿Pueden los usuarios registrar cuándo se tomaron las medidas?

Por ejemplo, es posible que los usuarios deban indicar cuándo se midió la glucosa en sangre, es decir, antes o después de una comida. O pueden pesarse y registrar los resultados antes y después del ejercicio. Para facilitar esto, he agregado una columna, measurement_context , en las tablas de información vital que pueden necesitar información contextual. A continuación se muestran algunos valores posibles para esta columna:

¿Qué pasa si una persona es diabética y necesita controlar sus niveles de glucosa en sangre?

El sistema que propongo tendrá un tablero que puede mostrar estadísticas vitales en un formato gráfico. Los usuarios pueden elegir lo que les gustaría ver en el tablero de su perfil, y cada perfil tiene su propio tablero. Los titulares de cuentas pueden ver todos los paneles de perfil que han creado.

He agregado una columna CHAR(1) para cada parámetro que se puede mostrar en un tablero. De manera predeterminada, todas las columnas se completarán con 'N' (la pantalla está apagada) cuando se crea un nuevo perfil. Posteriormente, los usuarios pueden modificar la configuración de su tablero desde una opción en la interfaz de usuario de la aplicación.

¿Cómo ayuda este sistema a las personas a mantenerse en forma?

En otras palabras, estamos hablando de almacenamiento de datos de fitness . Además de la información de salud, el sistema también permite a sus usuarios registrar información sobre su condición física y rutinas de ejercicio.

El activity_log table es la tabla principal en esta área temática. Captura detalles sobre cada tipo de perfil de actividad que realizan las personas.

Cada actividad se puede medir por uno o más de los siguientes tres parámetros:

• Hora de inicio y finalización – Actividades como practicar deportes o juegos, hacer cola, etc. se miden en términos de hora de inicio y finalización. Esto se hace a través de start_time y end_time columnas en activity_log .
• Distancia recorrida – Actividades como correr o andar en bicicleta se miden en términos de distancia recorrida. Esto se almacena en el distance_covered columna.
• Recuento de pasos – Las actividades como caminar se miden en términos de conteo de pasos, y los valores se almacenan en el steps_count columna.

Debes estar preguntándote por qué las calories_burnt la columna está en el activity_log mesa. Como su nombre lo indica, esta columna contiene el valor de las calorías quemadas por la persona del perfil mientras realiza una actividad en particular. Explicaré cómo podemos calcular estos valores en una sección posterior.

Creé una tabla llamada activity mantener una lista de todas las actividades posibles. Las columnas de esta tabla son:

• id – Asigna un número de identificación único a cada actividad.
• activity_name – Almacena nombres de actividades.
• activity_multiplier – Esta columna juega un papel clave en el cálculo de la cantidad de calorías quemadas por las personas que realizan actividades.

¿Cómo se calculan las calorías quemadas en cada actividad?

Para comprender cómo calcular la quema de calorías, primero debemos comprender el BMR o la tasa metabólica basal de una persona. Esto nos dice cuántas calorías quema un cuerpo en reposo. El BMR de cada persona depende de su sexo, edad, peso y altura. Desde la perspectiva del modelado de datos, una BMR es una dimensión que cambia lentamente y, como tal, sigue cambiando con el tiempo. Almacenaremos los últimos valores de BMR individuales en el user_bmr mesa.

Hay varios métodos utilizados para calcular los valores de BMR:

Método n.° 1:Método Harris-Benedict

BMR Hombres:66 + (6,23 X peso en libras) + (12,7 X altura en pulgadas) – (6,8 X edad)

BMR Mujer:655 + (4,35 X peso en libras) + (4,7 X altura en pulgadas) – (4,7 X edad)

Método n.° 2:Método Katch-McArdle

BMR (hombres + mujeres):370 + (21,6 * masa magra en kilogramos)

Masa magra =peso en kilogramos – (peso en kilogramos * grasa corporal %)

Podemos usar el BMR de una persona y el multiplicador de actividad mencionado anteriormente para averiguar cuántas calorías quema una persona al realizar una actividad determinada. La fórmula es:

Calorías quemadas =multiplicador de actividad * BMR

Nota:Ambos métodos de cálculo de BMR anteriores utilizan los mismos valores multiplicadores para las actividades. Para obtener más información, consulte este artículo.

¿Podemos mantener los valores históricos de BMR de los perfiles?

Sí. Podemos archivar los valores de BMR en el user_bmr_archive mesa.

Empezamos agregando una columna, id_version , al user_bmr mesa. Seguimos aumentando este valor en 1 cada vez que se actualiza el valor BMR de una persona de perfil.

El user_bmr_archive la tabla es casi una réplica del user_bmr mesa. La única diferencia es que tiene un dt_expired columna en lugar de dt_created y dt_modified columnas El dt_expired La columna almacena la fecha en que la versión dejó de ser válida, es decir, cuando el valor de BMR se actualiza en user_bmr .

¿Qué sucede si los usuarios desean mantener un registro de sus vacunas, historial médico familiar y alergias?

Este sistema aprovecha las siguientes tablas para brindar a los usuarios la capacidad de almacenar información de salud adicional.

La immunization la tabla almacena detalles sobre las vacunas recibidas por personas de perfil. Después del ejemplo, verá una breve descripción de las columnas que contiene esta tabla:

Ejemplo:John Soo recibió la segunda de tres dosis de una vacuna contra la hepatitis B. Fue administrado por el Dr. David Moore el 28 de noviembre de 2016. La vacuna se administró mediante una inyección en la mano izquierda. Es fabricado por Cipla (una compañía farmacéutica).

• id – La clave principal de esta tabla
• user_profile_id – Se refiere al user_profile_ID de John Soo
• vaccination_name – “Hepatitis B”
• dt_received – “28 de noviembre de 2016”
• number_in_sequence – “02”
• body_area_id – El ID de la mano izquierda, referido desde el body_area mesa
• provider_name - "Dr. David Moore”
• how_administered – “Inyectado” (otros valores posibles incluyen aerosol nasal, tableta, gotas, jarabe )
• manufacturer – “Ciplá”

La allergy la tabla almacena detalles sobre cualquier alergia experimentada por personas de perfil. A continuación se muestra la lista de columnas, con los valores relevantes proporcionados para cada una según el ejemplo:

Ejemplo:Alison D'Souza experimenta tos cuando come yogur. Tuvo esta reacción por primera vez cuando tenía 8 años. Ella consulta al Dr. Bill Smith, quien le receta algunos medicamentos y le aconseja ciertas precauciones. Esta alergia aún persiste, pero ahora su intensidad es menor.

• id – La clave primaria de la tabla
• user_profile_id – Rse refiere al user_profile_id de Alison D'Souza
• allergy_type_id – Se refiere a la ID para el tipo de alergia 'Alimentación' en el allergy_type mesa. (El allergy_type tabla define varios tipos de alergias como alimentos, medicamentos, ambientales, animales, plantas, etc.)
• allergy_reaction_id – Se refiere a la ID de la reacción alérgica 'Tos' en el allergy_reaction mesa.
• first_observed – La fecha en que se observó por primera vez esta reacción, es decir, cuando Alison tenía 8 años.
• consulting_doctor_name - "Dr. Bill Smith”
• treatment_brief – Una breve descripción de los medicamentos recetados y las precauciones recomendadas.
• does_treatment_cure_allergy – “Parcialmente curado. Reducción de la intensidad de la reacción.”

La family_history la tabla almacena detalles sobre el historial médico familiar de los usuarios. Nuevamente, enumeramos las columnas y el tipo de información que se almacenaría en ellas según el siguiente ejemplo.

Ejemplo:La madre de Diana, Lisa, tiene la enfermedad de Parkinson (un trastorno neurológico). Ha estado en tratamiento, pero no ha obtenido ninguna mejora tangible.

• id – la clave principal de la tabla
• user_profile_id – El user_profile_ID de Diana del user_profile mesa
• Relationship_id – El ID de la 'madre' de la relationship mesa
• Relative_name – “Lisa”
• Date_of_birth – Fecha de nacimiento de Lisa
• Date_of_death – NULL (Lisa todavía está viva y luchando duro contra la enfermedad.)
• Condition_brief – Una breve descripción de cómo, cuándo y dónde comenzó la condición, consultas, algún alivio, etc.
• Current_status – 'Actual' (Otros estados posibles son 'Intermitente' y 'Pasado'.)
• How_it_ended – NULO

¿Qué agregaría a este modelo de datos?

El sistema les permite a las personas saber cuántas calorías queman mientras realizan diversas actividades, pero no rastrea cuántas calorías consumen o cuán nutritivas son sus elecciones de alimentos. Además, el sistema les permite registrar sus datos de condición física diariamente, pero no les permite establecer una meta, formular un plan y realizar un seguimiento de su progreso para mantenerse motivados.

¿Deberíamos considerar incorporar estas características en él? ¿Qué cambios deben realizarse para agregar estas funciones?

¡Háganos saber sus ideas!