Database
 sql >> Base de Dados >  >> RDS >> Database

Um modelo de dados para acompanhar sua posse mais preciosa


Ser saudável e em forma é um estilo de vida, não uma moda passageira. As pessoas que percebem o valor da saúde fazem dela uma prioridade, mantendo registros de todos os fatos relacionados ao condicionamento físico. Neste artigo, examinaremos o design do banco de dados por trás de um aplicativo de saúde e condicionamento físico.

Existem muitos aplicativos que permitem que os usuários registrem suas informações de saúde e condicionamento físico. Alguns grandes players como Apple, Google e Microsoft lançaram suas próprias APIs de desenvolvimento especificamente para esse mercado. Por exemplo, o Google tem 'Fit' e a Microsoft tem 'HealthVault'.

Neste artigo, explicarei o modelo de dados por trás de um aplicativo de registros de saúde. Primeiro, vamos discutir exatamente o que esperamos que esse aplicativo faça.

Requisitos do projeto para um aplicativo de informações sobre saúde


Abaixo estão alguns recursos que um aplicativo de informações de saúde deve oferecer:
  • Os usuários podem criar uma conta e armazenar informações de saúde para vários perfis, ou seja, um indivíduo pode armazenar informações de saúde de todos os membros da família.
  • Os usuários podem registrar todo o histórico de saúde, incluindo vacinações, resultados laboratoriais anteriores, alergias e histórico médico da família .
  • Os usuários podem armazenar várias medidas de saúde e condicionamento físico, como níveis de glicose no sangue (açúcar no sangue), pressão arterial, composição corporal e dimensões, incluindo índice de massa corporal (IMC), colesterol, altura, peso, saúde reprodutiva etc.
  • l>
  • As informações podem ser registradas usando vários métodos e unidades de medida . Como exemplo, a glicose no sangue pode ser medida em mg/dL ou mmol/L.
  • Não há limites para a quantidade de informações que os usuários podem armazenar.
  • O sistema também manterá padrões de saúde aceitos, como números de pressão arterial ou IMC, e alertará os usuários se os números estiverem fora dos intervalos "seguros" ou "normais".
  • Os usuários também podem escolher informações (como glicemia, altura, peso etc.) para exibir em seu painel pessoal. Dessa forma, eles podem monitorar o que precisarem.

Em vez de simplesmente explicar o que cada seção e tabela faz no modelo de dados, vamos responder algumas perguntas sobre isso. A função das várias tabelas ficará clara à medida que avançamos.

Primeiro, você pode examinar o modelo de dados completo, se desejar.

O modelo de dados




Responder a perguntas sobre o modelo de dados de informações de saúde

Como os usuários podem armazenar informações de saúde de todos os membros de sua família individualmente?


Primeiro, vamos falar sobre o Gerenciamento de contas e perfis . Isso pode ser feito com duas tabelas diferentes; um (user_account ) para registrar os detalhes das pessoas que se registram no aplicativo e um (user_profile ) para registrar detalhes de todos os diferentes perfis que um usuário registrado cria. As pessoas podem criar vários perfis – por exemplo, um para cada um de seus familiares.



Vejamos as várias tabelas que tornam isso possível.

A user_account tabela contém detalhes básicos sobre a pessoa que se registra no aplicativo. Suas colunas são:

  • id –Uma coluna de chave substituta para esta tabela que identifica cada usuário exclusivamente.
  • login_name – O nome ou outro ID que o usuário escolhe como nome de login. Uma restrição exclusiva deve ser imposta a esta coluna para garantir que cada nome de login seja diferente.
  • enc_password – A senha da conta selecionada pelo usuário, em formato criptografado.
  • colunas de endereço – Armazena endereço e detalhes de contato dos usuários no momento do registro. Essas colunas incluem street_address , city , state , country e zip . Como esses campos são opcionais no processo de registro, mantive essas colunas como anuláveis.
  • contact_number e email – Armazena o número de contato do usuário (ou seja, número de telefone) e seu endereço de e-mail. Esses campos também fazem parte do processo de registro, mas não são anuláveis.
  • is_active – Contém um 'Y' ou um 'N' para indicar se uma conta está ativa no momento.
  • account_image – Os usuários podem fazer upload de suas próprias imagens. Como um usuário pode fazer upload de zero ou (no máximo) uma imagem por conta, esta é uma coluna do tipo BLOB anulável.

O user_profile A tabela armazena detalhes de todos os perfis criados por usuários registrados. As colunas desta tabela são:
  • id – Um número exclusivo atribuído a cada novo perfil.
  • user_account_id – Indica qual usuário criou o perfil.
  • user_profile_name – Armazena o nome da pessoa no perfil. (Chamaremos essa pessoa de "pessoa do perfil" e o usuário que cria os perfis de "titular da conta".)
  • relationship_id – Indica a relação entre o titular da conta e a pessoa do perfil. Esta coluna se refere ao relationship table, que contém todos os tipos possíveis de relacionamentos (como self , mãe , pai , irmã , irmão , filho , filha , animal de estimação , etc).
  • email – Esta coluna contém o endereço de e-mail da pessoa do perfil. Relatórios ou outras informações seriam compartilhados com eles por meio deste e-mail; informações também seriam enviadas ao titular da conta. Por exemplo, se Melissa criasse um perfil para sua filha Eva, as informações de Eva seriam enviadas para o e-mail de Melissa e possivelmente para o e-mail de Eva – veja abaixo.
  • is_report_sharing_enabled – Os relatórios são sempre compartilhados com o titular da conta, mas é opcional compartilhar esses dados com a pessoa do perfil. Esta coluna mostra se as informações serão compartilhadas com a pessoa do perfil.
  • is_active – Identifica se um perfil está ativo no momento. Esta é uma função de exclusão reversível caso os perfis sejam excluídos acidentalmente.
  • profile_image – Armazena uma imagem da pessoa do perfil. Este atributo é opcional e, portanto, anulável.

Os characteristic_data A tabela contém detalhes de perfis individuais (como grupo sanguíneo) que nunca mudam ao longo do tempo. Todas as colunas nesta tabela são autoexplicativas, exceto fitzpatrick_skin_type , que classifica a natureza da pele a partir de I (sempre queima, nunca bronzeia) a VI (nunca queima, nenhuma mudança na aparência quando bronzeada).

Eu adicionei duas colunas para gênero; biological_gender significa o sexo da pessoa no momento do nascimento e current_gender significa o sexo atual da pessoa do perfil. Esta segunda coluna é aplicável apenas a pessoas transgênero e, portanto, mantive-a anulável.

Quais informações vitais podem ser armazenadas neste sistema? Como é armazenado?


Agora estamos passando para o Gerenciamento de dados de saúde . A composição corporal, os níveis de glicose no sangue e as dimensões corporais são armazenados em tabelas separadas. No entanto, as pessoas podem inserir mais de um tipo de informação por vez, então usamos o body_vitals_log tabela para acompanhar quais informações são registradas em um perfil e quando são inseridas.



Todas as estatísticas vitais são mantidas nas seguintes tabelas:

  • body_composition – Armazena detalhes sobre várias porcentagens de composição corporal, como gordura, massa magra, osso ou água. Ele também contém valores de IMC (índice de massa corporal) para indivíduos.
  • blood_cholesterol – Contém detalhes de colesterol como LDL, HDL, triglicerídeos e total.
  • body_dimension – Registra as dimensões de várias áreas do corpo, como as medidas da cintura ou do peito.
  • body_weight – Armazena valores de peso corporal.
  • body_height – Contém valores para a altura de uma pessoa.
  • blood_pressure – Mantém os números de pressão arterial (sistólica e diastólica).
  • blood_glucose – Registra os níveis de glicose no sangue.

A maioria das colunas nas tabelas acima são autoexplicativas, com algumas exceções. Você notará algumas colunas adicionais como measurement_method_id , compare_to_normal_id , measurement_unit_id e measurement_context em quase todas essas tabelas. Vou explicar essas colunas mais tarde.

O body_vitals_log mantém o controle de quais informações são registradas em um determinado momento para um perfil. As colunas desta tabela são:
  • user_profile_id – Mostra qual perfil está registrando as informações.
  • dt_created – Armazena a data e hora em que as informações são inseridas.
  • data_source_id – Indica a origem dos dados, como um manual, um dispositivo eletrônico, etc.
  • IDs de várias estatísticas vitais – Mantive todas essas colunas anuláveis, pois os usuários podem registrar um ou mais itens por vez. Nem todos os usuários vão querer acompanhar as mesmas estatísticas de saúde.

Como podemos fazer o sistema funcionar em diferentes regiões?


Algumas informações são medidas em diferentes unidades em várias áreas. Por exemplo, o peso corporal é medido em quilogramas na Ásia, mas é medido em libras na América do Norte. Então, para tornar isso viável em nosso banco de dados, precisamos de uma maneira de rastrear unidades de medida.


  • id – Serve como chave primária desta tabela e é aquela a que as outras tabelas se referem.
  • measurement_parameter – Significa o tipo de informação vital (como peso, altura, pressão arterial, etc.) que uma unidade mede.
  • unit_name – Armazena o nome da unidade. Pense em quilograma e libra para peso, mg/dL e mmol/L para glicose no sangue.

Como as pessoas saberão se seus números são bons?


Nosso sistema não ajuda muito, a menos que alerte as pessoas sobre riscos ou vulnerabilidades à saúde. Habilitamos esta função adicionando o comparison_to_normal_id coluna em todas as tabelas de dados de informações vitais.



Quando qualquer nova informação vital é registrada no sistema, os registros serão comparados com seus valores de referência correspondentes e esta coluna será definida de acordo.

Os valores possíveis para esta tabela são:

Eu Texto
1 Não sei
2 Muito mais baixo
3 Baixo
4 Normal
5 Mais alto
6 Muito maior


Os usuários podem registrar quando as medições foram feitas?


Por exemplo, os usuários podem precisar informar quando sua glicose no sangue foi medida – ou seja, antes ou depois de uma refeição. Ou eles podem se pesar e registrar os resultados antes e depois do exercício. Para facilitar isso, adicionei uma coluna, measurement_context , nas tabelas de informações vitais que podem precisar de informações contextuais. Alguns valores possíveis para esta coluna são mostrados abaixo:

Antes do café da manhã
Depois do café da manhã
Antes do almoço
Depois do almoço
Antes do Jantar
Depois do Jantar
Antes do exercício
Após o Exercício
Jejum
Sem Jejum
Após a refeição
Antes da Refeição
Antes de dormir


E se uma pessoa for diabética e precisar monitorar seus níveis de glicose no sangue?


O sistema que estou propondo terá um painel que pode exibir estatísticas vitais em um formato gráfico. Os usuários podem escolher o que gostariam de ver em seu painel de perfil, e cada perfil tem seu próprio painel. Os titulares de contas têm permissão para ver todos os painéis de perfil que criaram.



Eu adicionei uma coluna CHAR(1) para cada parâmetro que pode ser mostrado em um painel. Por padrão, todas as colunas seriam preenchidas com 'N' (a tela está desativada) quando um novo perfil é criado. Os usuários podem modificar posteriormente a configuração do painel a partir de uma opção na interface do usuário do aplicativo.

Como este sistema ajuda as pessoas a ficarem em forma?


Em outras palavras, estamos falando de Armazenamento de dados de fitness . Além de informações de saúde, o sistema também permite que seus usuários registrem informações sobre suas rotinas de condicionamento físico e exercícios.

O activity_log table é a tabela principal nesta área de assunto. Ele captura detalhes sobre todo tipo de perfil de atividade que as pessoas realizam.



Cada atividade pode ser medida por um ou mais dos três parâmetros a seguir:

  • Horário de início e término – Atividades como praticar esportes ou jogos, ficar na fila etc. são medidas em termos de horário de início e término. Isso é feito através do start_time e end_time colunas em activity_log .
  • Distância percorrida – Atividades como corrida ou ciclismo são medidas em termos de distância percorrida. Isso é armazenado em distance_covered coluna.
  • Contagem de passos – Atividades como caminhar são medidas em termos de contagem de passos e os valores são armazenados no steps_count coluna.

Você deve estar se perguntando por que o calories_burnt coluna está no activity_log tabela. Como o próprio nome sugere, esta coluna contém o valor das calorias queimadas pela pessoa do perfil durante uma determinada atividade. Explicarei como podemos calcular esses valores em uma seção posterior.

Criei uma tabela chamada activity para manter uma lista de todas as atividades possíveis. As colunas desta tabela são:
  • id – Atribui um número de identificação exclusivo a cada atividade.
  • activity_name – Armazena nomes de atividades.
  • activity_multiplier – Esta coluna desempenha um papel fundamental no cálculo do número de calorias queimadas por pessoas que realizam atividades.

Como você calcula as calorias queimadas para cada atividade?


Para entender como calcular a queima de calorias, primeiro precisamos entender a TMB de uma pessoa, ou taxa metabólica basal. Isso nos diz quantas calorias um corpo queima em repouso. A TMB de cada pessoa depende de seu sexo, idade, peso e altura. De uma perspectiva de modelagem de dados, uma BMR é uma dimensão que muda lentamente e, como tal, continua mudando com o tempo. Armazenaremos os valores de BMR individuais mais recentes no user_bmr tabela.

Existem vários métodos usados ​​para calcular os valores de BMR:

Método nº 1:Método Harris-Benedict

BMR Homens:66 + (6,23 X peso em libras) + (12,7 X altura em polegadas) – (6,8 X idade)

BMR Mulheres:655 + (4,35 X peso em libras) + (4,7 X altura em polegadas) – (4,7 X idade)

Método nº 2:Método Katch-McArdle

BMR (homens + mulheres):370 + (21,6 * massa magra em quilogramas)

Massa Magra =peso em quilograma – (peso em quilograma * gordura corporal %)

Podemos usar a TMB de uma pessoa e o multiplicador de atividade mencionado acima para descobrir quantas calorias uma pessoa queima ao fazer uma determinada atividade. A fórmula é:

Calorias queimadas =multiplicador de atividade * BMR

Observação:Ambos os métodos de cálculo de BMR acima usam os mesmos valores de multiplicador para atividades. Para obter mais informações, consulte este artigo.

Podemos manter os valores históricos de BMR dos perfis?


Sim. Podemos arquivar valores de BMR no user_bmr_archive tabela.

Começamos adicionando uma coluna, id_version , para o user_bmr tabela. Continuamos aumentando esse valor em 1 toda vez que o valor de BMR de uma pessoa de perfil é atualizado.

O user_bmr_archive table é quase uma réplica do user_bmr tabela. A única diferença é que tem um dt_expired coluna em vez da dt_created e dt_modified colunas. O dt_expired A coluna armazena a data em que a versão se tornou inválida, ou seja, quando o valor da BMR é atualizado em user_bmr .


E se os usuários quiserem manter um registro de suas imunizações, histórico médico da família e alergias?


Este sistema aproveita as tabelas a seguir para dar aos usuários a capacidade de armazenar informações adicionais de saúde.



A immunization table armazena detalhes sobre imunizações recebidas pelas pessoas do perfil. Após o exemplo, você verá uma breve descrição das colunas que esta tabela contém:

Exemplo – John Soo recebeu a segunda de três doses de uma vacina contra a hepatite B. Foi administrado pelo Dr. David Moore em 28 de novembro de 2016. A vacinação foi dada por uma injeção na mão esquerda. É fabricado pela Cipla (uma empresa farmacêutica).

  • idA chave primária desta tabela
  • user_profile_idRefere-se ao user_profile_ID de John Soo
  • vaccination_name – “Hepatite B”
  • dt_received – “28 de novembro de 2016”
  • number_in_sequence – “02”
  • body_area_idO ID da mão esquerda, referente a body_area tabela
  • provider_name – “Dra. David Moore”
  • how_administered – “Injetado” (outros valores possíveis incluem spray nasal, comprimido, gotas, xarope )
  • manufacturer – “Cipla”

A allergy table armazena detalhes sobre quaisquer alergias experimentadas pelas pessoas do perfil. Abaixo está a lista de colunas, com os valores relevantes fornecidos para cada um conforme o exemplo:

Exemplo – Alison D’Souza sente tosse quando come iogurte. Ela teve essa reação pela primeira vez quando tinha 8 anos de idade. Ela consulta o Dr. Bill Smith, que prescreve alguns remédios e aconselha certos cuidados. Essa alergia ainda persiste, mas sua intensidade é menor agora.

  • id – A chave primária da tabela
  • user_profile_id – Rrefere-se ao user_profile_id de Alison D'Souza
  • allergy_type_idRefere-se ao ID do tipo de alergia 'Comida' no allergy_type tabela. (O allergy_type tabela define vários tipos de alergia como alimentos, medicamentos, ambientais, animais, plantas, etc.)
  • allergy_reaction_idRefere-se ao ID da reação alérgica 'Tosse' no allergy_reaction tabela.
  • first_observedA data em que essa reação foi observada pela primeira vez, ou seja, quando Alison tinha 8 anos.
  • consulting_doctor_name – “Dra. Bill Smith”
  • treatment_briefUma breve descrição dos medicamentos prescritos e precauções recomendadas.
  • does_treatment_cure_allergy – “Parcialmente curado. Intensidade de reação reduzida.”

A family_history table armazena detalhes sobre o histórico médico da família dos usuários. Novamente, listamos as colunas e o tipo de informação que seria armazenado nelas com base no exemplo a seguir.

Exemplo – A mãe de Diana, Lisa, tem doença de Parkinson (um distúrbio neurológico). Ela está em tratamento, mas não obteve nenhuma melhora tangível.

  • ida chave primária da tabela
  • user_profile_iduser_profile_ID de Diana do user_profile tabela
  • Relationship_idO ID 'mãe' do relationship tabela
  • Relative_name – “Lisa”
  • Date_of_birthData de nascimento de Lisa
  • Date_of_death – NULL (Lisa ainda está viva e lutando arduamente contra a doença.)
  • Condition_briefUma breve descrição de como, quando e onde a condição começou, consultas, qualquer alívio, etc.
  • Current_status – 'Atual' (Outros status possíveis são 'Intermitente' e 'Passado'.)
  • How_it_ended – NULO

O que você adicionaria a este modelo de dados?


O sistema permite que as pessoas saibam quantas calorias queimam enquanto realizam várias atividades, mas não rastreiam quantas calorias consomem ou quão nutritivas são suas escolhas alimentares. Além disso, o sistema permite que eles registrem seus dados de condicionamento físico diariamente, mas não permite que eles definam uma meta, formulem um plano e acompanhem seu progresso para que permaneçam motivados.

Devemos considerar a construção desses recursos nele? Que mudanças precisam ser feitas para adicionar esses recursos?

Deixe-nos saber suas ideias!