Моделиране на база данни

Написах песен за конците за зъби, но нечии зъби почистиха ли се?

Франк Запа

Когато мислим за стоматологичния кабинет, първите ни асоциации са бормашината, болката и страхът. Добре, това звучи лошо. Освен да се грижи за зъбите, зъболекарят има много други задължения, които са професионални, законни или и двете. Всички те изискват правилно управление на данните.

За да изпълнят това изискване за документация, много стоматологични и медицински кабинети използват хартиени записи. Бавно, но сигурно обаче има тенденция към дигиталните записи и управление на 21-ви век.

Вътре в кабинета по дентална медицина

Ходенето на зъболекар не е нещо, за което обикновено си спомняме с радост. Ако имахме късмет, избягвахме болката, но портфейлът ни вероятно пострада тежко. След като влезем в зъболекарския кабинет, процедурата обикновено е както следва:

• И двамата участвате в кратък разговор. (Често неприятно, защото сте обещали на зъболекаря си, че ще го посетите следващата седмица и са минали 2 години. След това казвате, че сте забравили, той се съгласява и всичко отново е наред.)
• Седате на стола, докато той разглежда предишните ви записи на лечение. Той пита дали нещо се е случило след последното посещение и има ли актуализация в медицинския ви картон.
• Той поглежда в устата ви, за да определи какво се е объркало, и ви казва какво ще го поправи.
• Можете да се съгласите с неговия план за лечение или да изберете друга опция.
• Няколко месеца по-късно холивудската усмивка отново е на лицето ви. Щеше да е по-рано, но не можеше да се усмихнеш, докато накрая не платиш изцяло сметката за зъболекарската си работа.

В този момент дори и най-отдаденият професионалист в базата данни вероятно не си мисли, „Уау, иска ми се да има модел на данни за това преживяване!“ . Но има и си струва да се проучи. Така че ние го отпечатахме по-долу.

Представяме ви модела на нашата база данни за стоматологичен кабинет

Идеята зад този модел е да обхване всяка процедура от момента, в който за първи път влезем в зъболекарския кабинет до разрешаването на проблема. Част от този модел (таблиците с етикет user_account , status , user_has_status , role , user_has_role ) беше представен и описан в предишни статии. Може би ролите и статусите изглеждат ненужни тук, но не забравяйте, че практиката може да включва и медицинска сестра, която да се справи с анамнезата (записване), рецепционист, студент по дентална медицина, няколко обучени стоматологични асистенти или дори гостуващ специалист или хигиенист. Данните за плащане обаче няма да бъдат взети предвид в тази статия.

Таблици в денталната база данни

patient таблицата е една от двете най-важни таблици в базата данни. Той съхранява данните на пациентите и е свързан с документите и посещенията на пациентите. С изключение на mail , всички атрибути в таблицата са задължителни:

• name – името на пациента
• surname – фамилията на пациента
• identification_number – това поле се използва за съхраняване на уникалния идентификатор на клиента, който се използва в реалния свят
• address – адрес на пациента
• phone – телефонен номер на пациента
• mail – пощенски адрес на пациента

Втората най-важна таблица в базата данни е visit . Когато се комбинира с таблицата patient , той съхранява информация за събитието, което е задействало всички последващи действия. Атрибутите в таблицата са:

• visit_date – съдържа действителната дата и час, когато е настъпило посещение
• patient_id – лична карта на пациента свързана ли е с посещението му
• dentist_id – е препратка към user_has_role таблица, като се приеме, че ролята е зъболекар

Следва anamnesis маса. В медицината анамнезата е процедура, при която събираме и съхраняваме история на медицинските данни, като например текущото състояние на пациента. anamnesis таблицата съхранява тези данни. Тъй като това се случва скоро след пристигането ни в офиса, ще имаме най-много една анамнеза за събитие. Атрибутите в таблицата са:

• anamnesis_id – е първичният ключ на anamnesis таблица, която също препраща към visit таблица
• user_anamnesis_id – това се отнася до user_has_role маса. Забележете, че не е задължително зъболекарят да е този, който е направил анамнеза.
• notes – съдържа текстови бележки за конкретна анамнеза. Това не е задължително поле.

anamnesis_type таблицата е прост речник, използван за съхраняване на всички възможни стойности, които са посочени в anamnesis_catalog . Единственият атрибут е type_name , и може да съдържа стойности като „болест“, „алергия“, „използвано лекарство“. Разбира се, този единствен атрибут е задължителен.

anamnesis_catalog таблицата е речник, който дава по-конкретна информация от стойностите, съхранявани в anamnesis_type маса. Ще го използваме, за да съхраняваме данни за конкретни заболявания, алергии и лекарства. Всички атрибути са задължителни и включват:

• catalog_name – е името на специфичен anamnesis_type подкатегория
• anamnesis_type_id – е препратка към anamnesis_type таблица

visit_anamnesis таблицата се използва за свързване на данните за посещения със стойности от каталога на анамнезата. Всеки атрибут в таблицата е задължителен:

• anamnesis_anamnesis_id – е препратка към anamnesis таблица
• anamnesis_catalog_id – е препратка към anamnesis_catalog таблица

Имайте предвид, че visit_anamnesis таблицата е релация много към много, свързваща таблиците с етикет anamnesis и anamnesis_catalog . Няма смисъл да съхранявате тази двойка (anamnesis_anamnesis_id &anamnesis_catalog_id ) два пъти. Ще използваме тази двойка като първичен ключ.

document таблицата е прост каталог, съдържащ места, където сме запазили документите на пациентите. Примери за такива документи могат да бъдат сканирани диаграми на пациенти, рентгенови снимки и фактури. Разбира се, няма да запазим тези документи директно в базата данни. Това е грубо опростяване на системата за управление на документи. Атрибутите в document таблицата са (всички са задължителни):

• description – е кратко описание на документа
• location – съдържа точно местоположение на документа
• patient_id – е препратка към patient таблица

tooth table е прост речник, който се използва по-късно, когато зъболекарят посочи кой зъб е бил проблемът. Всички атрибути в тази таблица са задължителни. Те са:

• is_baby_tooth – е булева стойност, която просто маркира дали даден зъб е млечен или не. Разбира се, ще имаме дублиращи се стойности за зъбите, които могат да бъдат и двете. Това е важно, тъй като процедурата може да се различава в зависимост от типа зъб.
• tooth – е описание, използвано за извършване на работа на зъба – обикновено тази стойност ще се показва на екрана.

problem_catalog table е друг прост речник. Той съдържа списък на всички възможни проблеми, които обикновено се срещат по зъбите или в устата. Примери за възможни стойности за този каталог са:„разпад на зъбите“, „ерозия на зъбите“, „гингивит“, „рани в устата“ или „непривлекателна усмивка“. Само problem_name атрибутът е задължителен.

problem_detected таблицата свързва данните от каталога за посещения, зъби и проблеми с treatment маса. Той съдържа препратки към tooth , problem_catalog и visit маси. Всички атрибути са задължителни с изключение на tooth_id . Причината за това изключение е, че някои проблеми не се отнасят само за един зъб (например гингивитът се отнася до венците). Тези три атрибута заедно образуват алтернативен ключ (УНИКАЛЕН). Другите два атрибута са:

• suggested_treatment_id е препратка към treatment таблица (предложеното от зъболекаря лечение). Може да бъде стойност NULL, когато всичко е наред и не се нуждаем от никакво лечение.
• selected_treatment_id е друга препратка към treatment маса. Той съдържа данни за лекуващия зъболекар и пациента, които са се съгласили да използват. Това може да бъде NULL, може би защото пациентът има нужда от време, за да обмисли предложеното лечение и други възможности.

Имайте предвид, че атрибутите suggested_treatment_id и selected_treatment_id и двете са посочени за treatment маса. Можем да направим това, защото трябва да съхраняваме най-много две стойности. Разбира се, ако не знаем предварително колко стойности искаме да съхраним, тогава трябва да използваме релация много към много тук.

step таблицата е прост речник, съдържащ всички възможни стъпки във всички лечения. Атрибутите (всички са задължителни) в таблицата са:

• step_name – е кратко име на стъпка, използвано на екрана
• description – е описание на действията, предприети по време на тази стъпка

treatment таблицата всъщност е речник на всички лечения, които стоматологичният кабинет предлага. Тъй като повечето лечения обикновено се състоят от няколко стъпки, трябва да знаем коя стъпка е окончателна. Всички атрибути в таблицата са задължителни:

• treatment_name – е името на лечението в системата
• description – е кратко описание на лечението
• final_step_id – е препратка към step маса. Можем да използваме тази информация, за да установим дали лечението е приключило и да започнем автоматично действие, или можем просто да покажем тази информация на потребителя и да го оставим да избере следващото действие.

The treatment_steps таблицата е релация много към много, която свързва стъпките с леченията. Задължителните атрибути в таблицата са:

• treatment_id – е препратка към treatment таблица
• step_id – е препратка към step таблица
• step_order – е число, което определя реда на стъпките в лечението

В тази таблица са дефинирани два алтернативни ключа (УНИКАЛНИ):

• двойка (treatment_id &step_id ) – тази стъпка може да бъде причислена към лечението само веднъж
• двойка (treatment_id &step_order ) – лечението не може да има две стъпки с един и същ номер на поръчка

visit_steps таблицата е списък на всички стъпки, които действително са били извършени след това посещение. Има две причини, поради които искаме да ги съхраняваме в отделни таблици:

1. Може да сме избрали лечение, но не са ни необходими всички стъпки, дефинирани за него, и
2. По този начин ще съхраняваме действителното време, когато е била изпълнена стъпката.

Атрибутите в таблицата (всички са задължителни с изключение на problem_detected_id и notes ) са както следва:

• visit_id – е препратка към visit таблица
• treatment_steps_id – е препратка към treatment_steps таблица
• problem_detected_id – е препратка към problem_detected маса. Тази връзка ни дава информация за това какъв проблем е инициирало това действие. Може да бъде NULL, когато зъболекарят реши да предприеме някакво действие, което не е свързано с никакъв открит проблем.
• step_time – е датата и/или часа, когато стъпката е била действително изпълнена
• notes – са бележки за тази стъпка, ако е необходимо

visit_status table е прост речник, използван за съхраняване на всички възможни състояния, които едно посещение може да има. Можем да използваме статуси като „първо посещение в офиса“, „първо посещение“, „лечението в ход“, „лечението приключи успешно“. Той съдържа само един атрибут, status_name , което е задължително.

visit_status_history таблицата се използва за съхраняване на данни за статусите, през които е преминало посещението. Идеята е, че добавяме статус ръчно, след като определени действия са завършени (например след анамнеза, след приключване на няколко стъпки от някакво лечение). Атрибутите, всички от които са задължителни, следват:

• status_time – е датата/часът, когато е вмъкнат статус
• visit_status_id – е препратка към visit_status таблица
• visit_id – е препратка към visit таблица

Възможни подобрения на модела на денталната база данни

Моделът ни стартира добре, но може да бъде подобрен. Например, той не обхваща следните елементи:

• начини на плащане и фактури
• насрочване на срещи (въпреки че това може да стане чрез вмъкване на данни в visit_steps таблица за бъдещи събития)
• работа с документи

Все пак ви кара да мислите по различен начин за вашия стоматологичен кабинет и неговите процедури, нали?