Modelowanie baz danych

Napisałem piosenkę o nici dentystycznej, ale czy czyjeś zęby stały się czystsze?

Frank Zappa

Kiedy myślimy o gabinecie dentystycznym, pierwsze skojarzenia to wiertarka, ból i strach. OK, to brzmi źle. Oprócz dbania o zęby stomatolog ma wiele innych obowiązków zawodowych, prawnych lub obu. Wszystkie wymagają odpowiedniego zarządzania danymi.

Aby spełnić ten wymóg dokumentacji, wiele gabinetów stomatologicznych i medycznych korzysta z dokumentacji papierowej. Powoli, ale pewnie, pojawia się trend w kierunku cyfrowych zapisów i zarządzania XXI wieku.

Wewnątrz Gabinetu Medycyny Stomatologicznej

Wizyta u dentysty nie jest czymś, co zwykle wspominamy z radością. Jeśli mieliśmy szczęście, uniknęliśmy bólu, ale nasz portfel prawdopodobnie mocno ucierpiał. Po wejściu do gabinetu dentystycznego procedura wygląda zwykle następująco:

• Oboje bierzecie udział w krótkiej pogawędce. (Często nieprzyjemne, ponieważ obiecałeś swojemu dentyście, że odwiedzisz go w przyszłym tygodniu i minęły 2 lata. Potem mówisz, że zapomniałeś, on się zgadza i znowu wszystko jest w porządku.)
• Siedzisz na krześle, a on przegląda twoje wcześniejsze zapisy leczenia. Pyta, czy coś się wydarzyło od ostatniej wizyty i czy jest jakaś aktualizacja Twojej dokumentacji medycznej.
• Zagląda ci do ust, aby ustalić, co poszło nie tak, i mówi, co to naprawi.
• Możesz zgodzić się z jego planem leczenia lub wybrać inną opcję.
• Kilka miesięcy później na twojej twarzy znów pojawia się hollywoodzki uśmiech. Byłoby wcześniej, ale nie mogłeś się uśmiechać, dopóki w końcu nie zapłaciłeś w całości rachunku za swoją pracę dentystyczną.

W tym momencie nawet najbardziej oddany specjalista od baz danych prawdopodobnie nie myśli:„Wow, szkoda, że ​​istnieje model danych dla tego doświadczenia!” . Ale jest i warto to zbadać. Dlatego wydrukowaliśmy to poniżej.

Przedstawiamy nasz model bazy danych gabinetów stomatologicznych

Ideą tego modelu jest objęcie każdego zabiegu od momentu wejścia do gabinetu dentystycznego aż do rozwiązania problemu. Część tego modelu (tabele oznaczone jako user_account , status , user_has_status , role , user_has_role ) został przedstawiony i opisany w poprzednich artykułach. Może role i statusy wydają się tutaj niepotrzebne, ale pamiętaj, że w praktyce może być również pielęgniarka zajmująca się wywiadem (rejestracja), recepcjonistka, studentka stomatologii, kilku przeszkolonych asystentek stomatologicznych, a nawet wizytujący specjalista lub higienistka. Jednak szczegóły płatności nie będą brane pod uwagę w tym artykule.

Tabele w dentystycznej bazie danych

patient table to jedna z dwóch najważniejszych tabel w bazie danych. Przechowuje dane pacjentów i jest powiązana z dokumentami i wizytami pacjentów. Z wyjątkiem mail , wszystkie atrybuty w tabeli są obowiązkowe:

• name – imię pacjenta
• surname – nazwisko pacjenta
• identification_number – to pole służy do przechowywania unikalnego identyfikatora klienta, który jest używany w świecie rzeczywistym
• address – adres pacjenta
• phone – numer telefonu pacjenta
• mail – adres e-mail pacjenta

Drugą najważniejszą tabelą w bazie danych jest visit . W połączeniu z tabelą patient , przechowuje informacje o zdarzeniu, które wywołało wszystkie kolejne akcje. Atrybuty w tabeli to:

• visit_date – zawiera faktyczną datę i godzinę wizyty
• patient_id – czy identyfikator pacjenta jest powiązany z jego wizytą
• dentist_id – jest odniesieniem do user_has_role tabeli, zakładając, że rolą jest dentysta

Następna w kolejce jest anamnesis stół. W medycynie anamneza to procedura, w ramach której zbieramy i przechowujemy historię danych medycznych, takich jak aktualny stan pacjenta. anamnesis tabela przechowuje te dane. Ponieważ dzieje się to wkrótce po naszym przybyciu do biura, będziemy mieć najwyżej jedną anamnezę na wydarzenie. Atrybuty w tabeli to:

• anamnesis_id – jest podstawowym kluczem anamnesis tabela, która również odwołuje się do visit stół
• user_anamnesis_id – dotyczy to user_has_role stół. Zauważ, że dentysta nie musi być tym, który dokonał anamnezy.
• notes – zawiera notatki tekstowe dotyczące konkretnej anamnezy. To pole nie jest obowiązkowe.

anamnesis_type table to prosty słownik używany do przechowywania wszystkich możliwych wartości, do których odwołuje się anamnesis_catalog . Jedynym atrybutem jest type_name i może zawierać wartości takie jak „choroba”, „alergia”, „stosowany lek”. Oczywiście ten jedyny atrybut jest obowiązkowy.

anamnesis_catalog tabela to słownik, który zawiera bardziej szczegółowe informacje niż wartości przechowywane w anamnesis_type stół. Wykorzystamy go do przechowywania danych o konkretnych chorobach, alergiach i lekach. Wszystkie atrybuty są obowiązkowe i obejmują:

• catalog_name – to nazwa konkretnego anamnesis_type podkategoria
• anamnesis_type_id – jest odniesieniem do anamnesis_type stół

visit_anamnesis tabela służy do łączenia danych wizyt z wartościami z katalogu anamnezy. Każdy atrybut w tabeli jest wymagany:

• anamnesis_anamnesis_id – jest odniesieniem do anamnesis stół
• anamnesis_catalog_id – jest odniesieniem do anamnesis_catalog stół

Zwróć uwagę, że visit_anamnesis tabela to relacja wiele-do-wielu łącząca tabele oznaczone jako anamnesis i anamnesis_catalog . Nie ma sensu przechowywać tej pary (anamnesis_anamnesis_id &anamnesis_catalog_id ) dwa razy. Użyjemy tej pary jako klucza podstawowego.

document tabela to prosty katalog zawierający lokalizacje, w których zapisaliśmy dokumenty pacjentów. Przykładami takich dokumentów mogą być skany kart pacjentów, zdjęcia rentgenowskie i faktury. Oczywiście nie zapiszemy tych dokumentów bezpośrednio w bazie danych. To niegrzeczne uproszczenie systemu zarządzania dokumentami. Atrybuty w document tabele są (wszystkie są obowiązkowe):

• description – to krótki opis dokumentu
• location – zawiera dokładną lokalizację dokumentu
• patient_id – jest odniesieniem do patient stół

tooth table to prosty słownik, który jest używany później, gdy dentysta określi, który ząb był problemem. Wszystkie atrybuty w tej tabeli są wymagane. Są to:

• is_baby_tooth – to wartość logiczna, która po prostu oznacza, czy ząb jest ząbkiem niemowlęcym, czy nie. Oczywiście będziemy mieć zduplikowane wartości zębów, które mogą mieć jedno i drugie. Jest to ważne, ponieważ procedura może się różnić w zależności od typu zęba.
• tooth – to opis używany do wykonania pracy zęba – ogólnie rzecz biorąc, ta wartość będzie wyświetlana na ekranie.

problem_catalog table to kolejny prosty słownik. Zawiera listę wszystkich możliwych problemów, które zwykle występują na zębach lub w jamie ustnej. Przykładami możliwych wartości dla tego katalogu są:„próchnica zębów”, „erozja zębów”, „zapalenie dziąseł”, „owrzodzenia jamy ustnej” lub „nieatrakcyjny uśmiech”. Tylko problem_name atrybut jest obowiązkowy.

problem_detected tabela łączy dane dotyczące wizyt, zębów i katalogu problemów z treatment stół. Zawiera odniesienia do tooth , problem_catalog i visit tabele. Wszystkie atrybuty są obowiązkowe z wyjątkiem tooth_id . Powodem tego wyjątku jest to, że niektóre problemy nie dotyczą tylko jednego zęba (np. zapalenie dziąseł dotyczy dziąseł). Te trzy atrybuty razem tworzą klucz alternatywny (UNIKALNY). Pozostałe dwa atrybuty to:

• suggested_treatment_id jest odniesieniem do treatment stolik (zabieg sugerowany przez stomatologa). Może to być wartość NULL, gdy wszystko jest w porządku i nie potrzebujemy żadnego leczenia.
• selected_treatment_id to kolejne odniesienie do treatment stół. Zawiera dane dotyczące leczenia stomatologa i pacjenta, który wyraził zgodę na stosowanie. Może to być NULL, być może dlatego, że pacjent potrzebuje czasu na przemyślenie sugerowanego leczenia i innych możliwości.

Zwróć uwagę, że atrybuty suggested_treatment_id i selected_treatment_id oba odnoszą się do treatment stół. Możemy to zrobić, ponieważ musimy przechowywać najwyżej dwie wartości. Oczywiście, jeśli nie wiemy z góry, ile wartości chcemy przechowywać, powinniśmy użyć tutaj relacji wiele do wielu.

step tabela to prosty słownik zawierający wszystkie możliwe kroki we wszystkich zabiegach. Atrybuty (wszystkie są obowiązkowe) w tabeli to:

• step_name – to krótka nazwa kroku używana na ekranie
• description – to opis działań podjętych podczas tego kroku

treatment Stół jest bowiem słownikiem wszystkich zabiegów, jakie oferuje gabinet dentystyczny. Ponieważ większość zabiegów składa się zwykle z kilku etapów, musimy wiedzieć, który etap jest ostateczny. Wszystkie atrybuty w tabeli są wymagane:

• treatment_name – to nazwa zabiegu w systemie
• description – to krótki opis zabiegu
• final_step_id – jest odniesieniem do step stół. Możemy wykorzystać te informacje, aby wykryć, czy leczenie się skończyło i zainicjować automatyczne działanie, lub możemy po prostu pokazać te informacje użytkownikowi i pozwolić mu wybrać następne działanie.

treatment_steps stół to relacja wiele-do-wielu, która łączy kroki z zabiegami. Obowiązkowe atrybuty w tabeli to:

• treatment_id – jest odniesieniem do treatment stół
• step_id – jest odniesieniem do step stół
• step_order – to liczba określająca kolejność kroków w leczeniu

W tej tabeli zdefiniowane są dwa alternatywne klucze (UNIKALNE):

• sparuj (treatment_id &step_id ) – ten krok można przypisać do zabiegu tylko raz
• sparuj (treatment_id &step_order ) – zabieg nie może składać się z dwóch etapów o tym samym numerze zamówienia

visit_steps tabela to lista wszystkich kroków, które faktycznie zostały wykonane po tej wizycie. Istnieją dwa powody, dla których chcemy przechowywać je w osobnych tabelach:

1. Może wybraliśmy leczenie, ale nie potrzebujemy wszystkich zdefiniowanych dla niego kroków i
2. W ten sposób będziemy przechowywać rzeczywisty czas wykonania kroku.

Atrybuty w tabeli (wszystkie są obowiązkowe z wyjątkiem problem_detected_id i notes ) są następujące:

• visit_id – jest odniesieniem do visit stół
• treatment_steps_id – jest odniesieniem do treatment_steps stół
• problem_detected_id – jest odniesieniem do problem_detected stół. Ta relacja dostarcza nam informacji o tym, jaki problem zainicjował to działanie. Może być NULL, gdy dentysta zdecyduje się podjąć jakieś działanie, które nie jest związane z żadnym wykrytym problemem.
• step_time – to data i/lub godzina faktycznego wykonania kroku
• notes – w razie potrzeby są notatki dotyczące tego kroku

visit_status table to prosty słownik służący do przechowywania wszystkich możliwych statusów, jakie może mieć wizyta. Moglibyśmy użyć statusów takich jak „pierwsza wizyta w gabinecie w historii”, „pierwsza wizyta”, „leczenie w toku”, „leczenie zakończone sukcesem”. Zawiera tylko jeden atrybut, status_name , co jest obowiązkowe.

visit_status_history tabela służy do przechowywania danych o statusach, jakie przeszła wizyta. Chodzi o to, że status dodajemy ręcznie po wykonaniu pewnych czynności (np. po anamnezie, po wykonaniu kilku kroków jakiegoś leczenia). Atrybuty, z których wszystkie są wymagane, są następujące:

• status_time – to data/godzina wstawienia statusu
• visit_status_id – jest odniesieniem do visit_status stół
• visit_id – jest odniesieniem do visit stół

Możliwe ulepszenia modelu stomatologicznej bazy danych

Nasz model ma dobry początek, ale można go ulepszyć. Na przykład nie obejmuje następujących pozycji:

• metody płatności i faktury
• planowanie spotkań (chociaż można to zrobić, wstawiając dane do visit_steps tabela na przyszłe wydarzenia)
• obsługa dokumentów

Mimo to sprawia, że ​​myślisz inaczej o swoim gabinecie dentystycznym i jego procedurach, prawda?