Modelagem de banco de dados

Eu escrevi uma música sobre fio dental, mas os dentes de alguém ficaram mais limpos?

Frank Zappa

Quando pensamos no consultório odontológico, nossas primeiras associações são a broca, a dor e o medo. OK, isso soa mal. Além de cuidar dos dentes, o dentista tem muitas outras obrigações profissionais, legais ou ambas. Todos eles exigem um gerenciamento de dados adequado.

Para atender a essa exigência de documentação, muitos consultórios odontológicos e médicos usam registros em papel. Lenta mas seguramente, porém, há uma tendência para os registros digitais e gerenciamento do século 21.

Dentro do Escritório de Medicina Dentária

Ir ao dentista não é algo que costumamos lembrar com alegria. Se tivéssemos sorte, evitamos a dor, mas nossa carteira provavelmente sofreu muito. Depois que entramos no consultório de um dentista, o procedimento geralmente é o seguinte:

Vocês dois se envolvem em um pequeno bate-papo. (Muitas vezes desagradável porque você prometeu ao seu dentista que iria visitá-lo na próxima semana e 2 anos se passaram. Então você diz que esqueceu, ele concorda e tudo fica bem novamente.)
Você se senta na cadeira enquanto ele olha seus registros de tratamento anteriores. Ele pergunta se algo aconteceu desde a última visita e há alguma atualização no seu prontuário médico.
Ele dá uma olhada na sua boca para determinar o que deu errado e diz o que vai consertar.
Você pode concordar com o plano de tratamento dele ou escolher outra opção.
Alguns meses depois, um sorriso de Hollywood está em seu rosto novamente. Teria sido mais cedo, mas você não conseguia sorrir até que finalmente pagasse a conta integralmente pelo seu trabalho odontológico.

Neste ponto, mesmo o profissional de banco de dados mais dedicado provavelmente não está pensando, 'Uau, eu gostaria que houvesse um modelo de dados para esta experiência!' . Mas existe, e vale a pena examinar. Por isso, imprimimos abaixo.

Apresentando nosso modelo de banco de dados de consultório odontológico

A ideia por trás desse modelo é abranger todos os procedimentos desde o momento em que entramos no consultório do dentista até que o problema seja resolvido. Parte deste modelo (as tabelas rotuladas user_account , status , user_has_status , role , user_has_role ) foi apresentado e descrito em artigos anteriores. Talvez papéis e status pareçam desnecessários aqui, mas lembre-se de que a prática também pode conter uma enfermeira para lidar com a anamnese (registro), uma recepcionista, um estudante de odontologia, vários auxiliares de dentista treinados ou até mesmo um especialista em visita ou um higienista. No entanto, os detalhes de pagamento não serão considerados neste artigo.

Tabelas no banco de dados odontológico

O patient table é uma das duas tabelas mais importantes no banco de dados. Ele armazena os dados dos pacientes e está conectado aos documentos e visitas dos pacientes. Com exceção de mail , todos os atributos da tabela são obrigatórios:

name – o nome do paciente
surname – o sobrenome do paciente
identification_number – este campo é usado para armazenar o id exclusivo de um cliente que é usado no mundo real
address – o endereço do paciente
phone – o número de telefone do paciente
mail – o endereço de e-mail do paciente

A segunda tabela mais importante no banco de dados é visit . Quando combinado com a tabela patient , ele armazena informações sobre o evento que acionou todas as ações subsequentes. Os atributos na tabela são:

visit_date – contém a data e hora reais em que a visita ocorreu
patient_id – é o id do paciente relacionado à sua visita
dentist_id – é uma referência a user_has_role mesa, assumindo que o papel é dentista

O próximo passo é a anamnesis tabela. Na medicina, a anamnese é um procedimento onde coletamos e armazenamos o histórico de dados médicos, como o estado atual do paciente. A anamnesis tabela armazena esses dados. Como isso acontece logo após nossa chegada ao consultório, teremos no máximo uma anamnese por evento. Os atributos na tabela são:

anamnesis_id – é a chave primária da anamnesis tabela, que também faz referência à visit tabela
user_anamnesis_id – isso está relacionado ao user_has_role tabela. Observe que o dentista não precisa ser aquele que fez a anamnese.
notes – contém notas de texto sobre anamnese específica. Não é um campo obrigatório.

O anamnesis_type table é um dicionário simples usado para armazenar todos os valores possíveis referenciados em anamnesis_catalog . O único atributo é type_name , e pode conter valores como “doença”, “alergia”, “medicamento usado”. Claro, esse único atributo é obrigatório.

O anamnesis_catalog tabela é um dicionário que fornece informações mais específicas do que os valores armazenados no anamnesis_type tabela. Vamos usá-lo para manter dados sobre doenças, alergias e medicamentos específicos. Os atributos são todos obrigatórios e incluem:

catalog_name – é o nome de um anamnesis_type subcategoria
anamnesis_type_id – é uma referência ao anamnesis_type tabela

A visit_anamnesis A tabela é usada para conectar os dados da visita com os valores do catálogo de anamnese. Cada atributo na tabela é obrigatório:

anamnesis_anamnesis_id – é uma referência à anamnesis tabela
anamnesis_catalog_id – é uma referência ao anamnesis_catalog tabela

Observe que o visit_anamnesis tabela é uma relação muitos-para-muitos conectando as tabelas rotuladas anamnesis e anamnesis_catalog . Não faz sentido armazenar este par (anamnesis_anamnesis_id &anamnesis_catalog_id ) duas vezes. Usaremos esse par como a chave primária.

O document table é um catálogo simples contendo locais onde salvamos os documentos dos pacientes. Exemplos de tais documentos podem ser digitalizações de prontuários de pacientes, raios-X e faturas. Claro que não vamos salvar esses documentos diretamente no banco de dados. Esta é uma simplificação grosseira do sistema de gerenciamento de documentos. Os atributos dentro do document tabela são (todos são obrigatórios):

description – é uma breve descrição do documento
location – contém a localização exata do documento
patient_id – é uma referência ao patient tabela

O tooth table é um dicionário simples que é usado posteriormente quando o dentista especifica qual dente era o problema. Todos os atributos nesta tabela são obrigatórios. Eles estão:

is_baby_tooth – é um valor booleano que simplesmente marca se um dente é de leite ou não. Claro, teremos valores duplicados para dentes que podem ser ambos. Isso é importante porque um procedimento pode diferir de acordo com o tipo de dente.
tooth – é uma descrição usada para o dente fazer o trabalho – geralmente, esse valor será mostrado na tela.

O problem_catalog table é outro dicionário simples. Ele contém uma lista de todos os possíveis problemas normalmente encontrados nos dentes ou na boca. Exemplos de valores possíveis para este catálogo são:“cárie dentária”, “erosão dentária”, “gengivite”, “feridas na boca” ou “sorriso pouco atraente”. Apenas o problem_name atributo é obrigatório.

O problem_detected A tabela conecta os dados do catálogo de visitas, dentes e problemas com o treatment tabela. Ele contém referências ao tooth , problem_catalog e visit mesas. Todos os atributos são obrigatórios, exceto tooth_id . A razão para esta exceção é que alguns problemas não se referem a apenas um dente (por exemplo, gengivite refere-se às gengivas). Esses três atributos juntos formam uma chave alternativa (ÚNICA). Os outros dois atributos são:

suggested_treatment_id é uma referência ao treatment mesa (o tratamento sugerido pelo dentista). Pode ser um valor NULL quando tudo está OK e não precisamos de nenhum tratamento.
selected_treatment_id é outra referência ao treatment tabela. Ele contém dados sobre o tratamento que o dentista e o paciente concordaram em usar. Isso pode ser NULO, talvez porque o paciente precise de tempo para pensar sobre o tratamento sugerido e outras possibilidades.

Observe que os atributos suggested_treatment_id e selected_treatment_id ambos são referenciados ao treatment tabela. Podemos fazer isso porque só precisamos armazenar, no máximo, dois valores. Claro, se não soubermos antecipadamente quantos valores queremos armazenar, devemos usar uma relação muitos-para-muitos aqui.

A step table é um dicionário simples contendo todos os passos possíveis em todos os tratamentos. Os atributos (todos são obrigatórios) na tabela são:

step_name – é um nome de etapa curto usado na tela
description – é uma descrição das ações realizadas durante esta etapa

O treatment table é na verdade um dicionário de todos os tratamentos que o consultório odontológico oferece. Como a maioria dos tratamentos geralmente consiste em várias etapas, devemos saber qual etapa é a final. Os atributos na tabela são todos obrigatórios:

treatment_name – é o nome do tratamento dentro do sistema
description – é uma breve descrição do tratamento
final_step_id – é uma referência à step tabela. Podemos usar essas informações para detectar se o tratamento terminou e iniciar a ação automática, ou podemos simplesmente mostrar essas informações ao usuário e deixá-lo escolher a próxima ação.

Os treatment_steps tabela é uma relação muitos-para-muitos que conecta etapas com tratamentos. Os atributos obrigatórios na tabela são:

treatment_id – é uma referência ao treatment tabela
step_id – é uma referência à step tabela
step_order – é um número que define a ordem das etapas do tratamento

Nesta tabela são definidas duas chaves alternativas (UNIQUE):

par (treatment_id &step_id ) – esta etapa pode ser atribuída ao tratamento apenas uma vez
par (treatment_id &step_order ) – o tratamento não pode ter duas etapas com o mesmo número de pedido

Os visit_steps A tabela é uma lista de todas as etapas que foram realmente realizadas após essa visita. Há duas razões pelas quais queremos armazená-los em tabelas separadas:

Podemos ter escolhido um tratamento, mas não precisamos de todas as etapas definidas para ele e
Dessa forma, armazenaremos a hora real em que a etapa foi realizada.

Os atributos na tabela (todos são obrigatórios exceto problem_detected_id e notes ) são como segue:

visit_id – é uma referência à visit tabela
treatment_steps_id – é uma referência aos treatment_steps tabela
problem_detected_id – é uma referência ao problem_detected tabela. Essa relação nos dá informações sobre qual problema iniciou essa ação. Pode ser NULL quando o dentista decide tomar alguma ação que não esteja relacionada a nenhum problema detectado.
step_time – é a data e/ou hora em que a etapa foi realmente executada
notes – são notas para essa etapa, se necessário

O visit_status table é um dicionário simples usado para armazenar todos os status possíveis que uma visita pode ter. Poderíamos usar status como “primeira visita ao consultório”, “primeira visita”, “tratamento em andamento”, “tratamento concluído com sucesso”. Ele contém apenas um atributo, status_name , que é obrigatório.

A visit_status_history A tabela é usada para armazenar dados sobre os status pelos quais a visita passou. O pensamento é que adicionamos o status manualmente após a conclusão de certas ações (por exemplo, após a anamnese, após terminar algumas etapas de algum tratamento). Os atributos, todos obrigatórios, seguem:

status_time – é a data/hora em que o status foi inserido
visit_status_id – é uma referência ao visit_status tabela
visit_id – é uma referência à visit tabela

Possíveis melhorias no modelo de banco de dados odontológico

Nosso modelo começou bem, mas pode ser melhorado. Por exemplo, não cobre os seguintes itens:

formas de pagamento e faturas
agendamento de reuniões (embora isso possa ser feito inserindo dados em visit_steps tabela para eventos futuros)
manuseio de documentos

Ainda assim, faz você pensar diferente sobre seu consultório odontológico e seus procedimentos, não é?