Model danych dla aplikacji do rezerwacji wizyt lekarskich

Rezerwacja wizyty lekarskiej za pomocą aplikacji online to innowacja, która upraszcza cały proces. Zanurzmy się w model danych stojący za aplikacją do rezerwacji spotkań.

Dlaczego warto korzystać z aplikacji? Ułatwia ludziom znalezienie wybranych lekarzy, umożliwiając im zapoznanie się z dokumentacją zawodową lekarza i recenzjami pacjentów. Gdy ktoś znajdzie lekarza, który mu się spodoba, może umówić się z nim na wizytę bez wychodzenia z aplikacji. Aplikacja może również pomóc lekarzom w skróceniu czasu oczekiwania pacjentów, pomóc im zaplanować pacjentów i mieć oko na opinie pacjentów online.

Wymagania dotyczące aplikacji na wizytę lekarską

Krótko mówiąc, oczekujemy, że nasza aplikacja:

Zezwalaj pacjentom na wyszukiwanie lekarzy różnych specjalizacji (lekarz rodzinny, kardiolog, podiatra itp.) według lokalizacji.
Pokaż uporządkowaną listę lekarzy w oparciu o ich wieloletnie doświadczenie, odległość od lokalizacji pacjenta, zalecenia dla pacjentów i ich wskaźniki oceny (zbiorcza ocena pacjenta dotycząca zachowania przy łóżku, czasu oczekiwania, personelu itp.)
Pokaż początkowe i uzupełniające opłaty za konsultacje lekarzy.
Przechwytuj i wyświetlaj profile lekarzy, w tym szczegółowe informacje o ich stopniach naukowych, certyfikatach, stażach oraz przeszłych i obecnych powiązaniach ze szpitalami.
Zapisuj opinie o lekarzach od użytkowników aplikacji. Ta recenzja zapewni dokładny podgląd lekarzy i ich personelu innym użytkownikom aplikacji.

I nie zapomnij o wyjątkowym punkcie sprzedaży aplikacji:pokazuje nadchodzące dostępne spotkania i umożliwia użytkownikom rezerwację jednego .

Kategoryzowanie wymagań aplikacji

Zasadniczo możemy podzielić wymagania aplikacji na te cztery obszary:

Zarządzanie danymi lekarzy – Lekarze mogą się zarejestrować i wprowadzić wszystkie swoje dane.
Zarządzanie lekarzami OPD (oddział ambulatoryjny) i szczegółami kliniki – Lekarze (lub ich personel) mogą rejestrować szczegóły dotyczące ich kliniki lub harmonogramu OPD i dostępności.
Zarządzanie danymi klienta i recenzji – Użytkownicy mogą się zarejestrować i wprowadzić swoje podstawowe dane. Mogą również publikować opinie o lekarzach.
Zarządzanie spotkaniami – Użytkownicy mogą wyszukiwać lekarzy na podstawie określonych kryteriów.

Przyjrzyjmy się tym obszarom indywidualnie.

Zarządzanie danymi lekarzy

Lekarze mogą zarejestrować się w aplikacji, wypełniając pewne obowiązkowe dane, ale funkcja rezerwacji wizyt jest włączona dopiero po wypełnieniu pełnego profilu. Obejmuje to ich kwalifikacje (stopnie zawodowe, certyfikaty/specjalizacje i staże) oraz ich przeszłe i obecne powiązania ze szpitalami i dostawcami usług opieki zdrowotnej.

Poniższe tabele zarządzają tymi informacjami.

doctor tabela przechowuje podstawowe dane o lekarzach, które wprowadzają podczas rejestracji. Kolumny w tej tabeli to:

id – Unikalny numer, który aplikacja przypisuje lekarzom podczas rejestracji.
first_name – Imię lekarza.
last_name – Nazwisko lekarza.
professional_statement – Szczegółowy przegląd kwalifikacji, doświadczenia lekarza, jego motta zawodowego itp. Te informacje są wprowadzane przez lekarza i są wyświetlane na stronie profilu każdego lekarza.
practicing_from – Data rozpoczęcia przez lekarza praktyki lekarskiej. Ma to ogromne znaczenie, ponieważ aplikacja będzie czerpać ocenę doświadczenia dla każdego lekarza na podstawie informacji w tej kolumnie.

specialization w tabeli znajdują się wszystkie istniejące specjalizacje medyczne, takie jak ortopeda, neurolog, stomatolog itp. Lekarz może mieć więcej niż jedną specjalizację; w rzeczywistości lekarze dość często specjalizują się w pokrewnych dziedzinach. Na przykład neurolog może być również psychiatrą; ginekolog może być endokrynologiem i tak dalej. Dlatego doctor_specialization tabela umożliwia relację wiele-do-wielu między doctor i specialization tabele. Atrybuty w tych dwóch tabelach są oczywiste.

qualification tabela zawiera szczegółowe informacje o wykształceniu i kwalifikacjach zawodowych lekarzy, w tym stopnie naukowe, certyfikaty, prace badawcze, seminaria, bieżące szkolenia itp. Aby ułatwić różne rodzaje szczegółów kwalifikacji, nadałem tym polom dość ogólne nazwy:

id – Klucz podstawowy tabeli.
doctor_id – Odwołuje się do doctor tabeli i wiąże lekarza z kwalifikacjami.
qualification_name – Oznacza tytuł stopnia, certyfikat, pracę naukową itp.
institute_name – Instytucja, która nadała lekarzowi kwalifikację. Może to być uniwersytet, instytucja medyczna, międzynarodowe stowarzyszenie lekarzy itp.
procurement_year – Data uzyskania lub przyznania kwalifikacji.

hospital_affiliation tabela zawiera informacje o przynależności lekarzy do szpitali i świadczeniodawców. Dane te służą wyłącznie do wyświetlania w profilu lekarza i nie mają znaczenia w funkcji rezerwacji wizyt. Dane OPD (oddział ambulatoryjny) są wprowadzane osobno i zostaną omówione w dalszej części tego artykułu.

Kolumny tej tabeli to:

id – Klucz podstawowy tabeli.
doctor_id – Odwołuje się do doctor tabeli i łączy lekarza z powiązanym szpitalem.
hospital_name – Nazwa szpitala stowarzyszonego.
city and country – Miasto i kraj, w którym znajduje się szpital. Te kolumny adresowe nie odgrywają żadnej roli w funkcji wyszukiwania aplikacji; są tylko do wyświetlania w profilu lekarza.
start_date – Kiedy rozpoczęła się współpraca lekarza ze szpitalem.
end_date – Kiedy związek się skończył. Można ją unieważnić, ponieważ obecne powiązania nie będą miały daty końcowej.

Zarządzanie szczegółami OPD/kliniki lekarzy

Informacje w tej sekcji są wprowadzane przez lekarzy (lub ich personel) i odgrywają istotną rolę w funkcjach wyszukiwania i rezerwacji aplikacji.

office tabela zawiera informacje o przychodniach szpitali, z którymi zrzeszeni są lekarze, a także o własnych przychodniach (np. gabinetach lub przychodniach). Kolumny w tej tabeli to:

id – Klucz podstawowy tej tabeli.
doctor_id – Odwołuje się do doctor tabeli i wskazuje odpowiedniego lekarza.
hospital_affiliation_id –Oznacza szpital, w którym lekarz jest dostępny dla OPD. Ponieważ kolumna ma zastosowanie do OPD, ale nie do klinik, nie można jej unieważnić.
time_slot_per_client_in_min – Przechowuje ilość czasu (w minutach) przeznaczoną na konsultacje. Liczbę minut wprowadzają lekarze na podstawie swojego doświadczenia. Ta kolumna pomaga aplikacji określić następny dostępny boks. Pamiętaj, że ten numer nie gwarantuje długości wizyty, ale pomaga zminimalizować czas oczekiwania pacjentów, którzy używają aplikacji do umawiania wizyty.
first_consultation_fee – Opłata pobierana przez lekarza za wizytę wstępną. Może się to wydawać nieistotne, ale jest bardzo ważne dla funkcji wyszukiwania; opłata jest bardzo powszechnym kryterium filtrowania.
followup_consultation_fee – Wielu lekarzy pobiera mniej za wizytę kontrolną niż za wstępną konsultację. W tej kolumnie przechowywane są dodatkowe koszty konsultacji.
street_address – Adres szpitala OPD lub przychodni.
city , state i country –Miasto, stan i kraj, w którym znajduje się szpital lub klinika.
zip – Kod pocztowy, pod którym znajduje się przychodnia lub szpital. Często ludzie szukają lekarzy w pobliskich obszarach, używając kodu pocztowego, więc to pole będzie ważne dla funkcji wyszukiwania w aplikacji.

Dlaczego istnieje oddzielna tabela „biuro”, skoro szczegóły OPD można łatwo śledzić w tabeli „hospital_affiliation”?

Trzy powody:

Lekarz może być związany ze szpitalem w jednym aspekcie swojej pracy (tj. wykonywaniu operacji), ale nie w innych (tj. przyjmowaniu pacjentów). Możemy utracić takie powiązania, jeśli spróbujemy zachować dane biura w hospital_affiliation tylko stół.
Wielu lekarzy nie jest związanych ze szpitalami, ale ma własne kliniki lub gabinety. Musimy również przechowywać informacje dla tych lekarzy.
Lekarz może mieć kilka gabinetów w różnych lokalizacjach lub pracować w kilku oddziałach szpitala. Jeśli lekarz zostanie pokazany jako związany tylko z jedną lokalizacją szpitala, możemy stracić niektóre informacje. Z tego powodu przechowujemy oddzielne dane adresowe.

office_doctor_availability tabela przechowuje dostępność lekarzy OPD/klinik pod względem przedziałów czasowych (powiedzmy 2 godziny rano i 4 godziny wieczorem). Dzielenie dnia w ten sposób jest dość powszechne, więc posiadanie dodatkowego stołu do przechowywania slotów dostępności ma sens. Ponadto lekarze mogą pracować na więcej niż jednej zmianie OPD. Kolumny w tej tabeli to:

id – Klucz podstawowy tabeli.
office_id – Odwołuje się do tabeli „biurowej”.
day_of_week – Dzień tygodnia, tj. poniedziałek, wtorek itp. Dzięki temu lekarze mogą mieć różne dyspozycyjności w różne dni (na przykład weekendy vs. dni powszednie).
start_time – Kiedy lekarz jest gotowy na przyjęcie pierwszego pacjenta.
end_time – Kiedy planowane jest zakończenie ostatniego spotkania lub zmiany.
is_available – Pozwala lekarzom zaznaczyć swoją dostępność w określonych dniach lub przedziałach czasowych. Ta kolumna jest inicjowana domyślnie na „Y” i jest aktualizowana na „N”, gdy lekarze zaznaczą swoją niedostępność.
reason_of_unavailablity – Wielu lekarzy woli ujawnić, dlaczego są niedostępni lub muszą odwołać wizytę. Pomaga to w budowaniu przejrzystej relacji między lekarzami a ich pacjentami. Ponieważ jest to opcjonalne, zachowałem to jako kolumnę dopuszczającą wartość null.

in_network_insurance tabela przechowuje informacje o ubezpieczeniach. W wielu krajach usługi medyczne są bardzo kosztowne, a ubezpieczenie zdrowotne jest obowiązkowe. W takich przypadkach ta tabela zawiera szczegółowe informacje o tym, jakie firmy ubezpieczeniowe są w pełni akceptowane w szpitalu OPD lub klinice.

Zarządzanie danymi klienta i przeglądami

Dla pacjenta rejestracja w aplikacji wymaga bardzo mało informacji. Odtąd będę używał słowa „klient” zamiast „użytkownika” lub „pacjenta”.

client_account tabela przechowuje podstawowe dane dla klientów. Dane te są rejestrowane w momencie rejestracji. Kolumny w tej tabeli to:

id – Unikalny numer przypisany do każdego klienta.
first_name – Imię klienta.
last_name – Nazwisko klienta.
contact_number – Numer telefonu klienta, najlepiej telefon komórkowy, na który można przesłać informacje o spotkaniu. Jest to również numer, pod którym z klientem mogą się skontaktować pracownicy gabinetu lekarskiego.
email – Adres e-mail klienta. Aplikacja może wysyłać klientom przypomnienia o spotkaniach.

client_review tabela nie tylko oferuje informacje zwrotne (tj. opinie klientów) dla lekarzy, ale także pomaga potencjalnym klientom w wyborze lekarzy. Jest integralną częścią tej aplikacji. Kolumny w tej tabeli to:

id – Klucz podstawowy tej tabeli.
user_account_id – Wskazuje, który użytkownik przesyła recenzję.
doctor_id – Recenzja lekarza.
is_review_anonymous – Czy nazwisko klienta zostanie opublikowane wraz z recenzją, czy nie. To jest funkcja bezpieczeństwa dla klientów.
wait_time_rating – Ta kolumna liczbowa zawiera ocenę w zakresie od 1 (najgorszy) do 10 (najlepszy). Odzwierciedla opinię klienta o tym, jak długo czekał na wizytę u lekarza.
bedside_manner_rating –Przechowuje opinię klienta o zachowaniu lekarza przy łóżku (np. czy lekarz jest miły, współczujący, dobrze się komunikuje itp.)
overall_rating – Ocena klienta dotycząca ich ogólnych doświadczeń z lekarzem.
review – Klienci mogą tutaj przekazać swoją szczegółową opinię.
is_doctor_recommended – Ta kolumna wskaźnika określa, czy klient poleciłby lekarza.
review_date – Kiedy recenzja została przesłana.

Zarządzanie spotkaniami

Ta sekcja jest najważniejszym punktem USP (Unique Selling Point) dla tej aplikacji, ponieważ pozwala klientom sprawdzić dostępność różnych lekarzy i umówić się na wizytę.

appointment tabela zawiera szczegóły spotkań dla klientów. Jego kolumny obejmują:

id – Każdemu spotkaniu przypisany jest unikalny numer. Ten numer jest wymieniony w innym miejscu.
user_account_id – Który klient rezerwuje wizytę.
office_id – Wskazuje, który lekarz i który szpital OPD lub klinika jest zaangażowany w wizytę.
probable_start_time – To jest kolumna sygnatury czasowej, w której znajduje się prawdopodobny czas rozpoczęcia spotkania. Godziny rozpoczęcia wizyt lekarskich są zwykle prawdopodobne, a nie bezwzględne.
actual_end_time – Faktyczny czas zakończenia konsultacji. Początkowo ta kolumna jest pusta, ponieważ wiele czynników może mieć wpływ na zakończenie spotkania. Dlatego jest to kolumna dopuszczająca wartość null.
appointment_status_id – Odwołuje się do tego appointment_status tabeli i wskazuje aktualny status spotkania. Możliwe wartości statusu to „aktywny”, „anulowany” i „zakończony”. Początkowo status byłby „aktywny”. Stanie się „kompletny” po zakończeniu wizyty. Zostanie „anulowany”, jeśli klient anuluje wizytę.
appointment_taken_date – Data umówienia się na spotkanie.
app_booking_channel_id – Kanał, przez który zarezerwowano spotkanie. Istnieje wiele kanałów, przez które umawiane są wizyty:przez aplikację, dzwoniąc do szpitala, dzwoniąc do lekarza lub ich biura itp.

Zobacz pełny model danych

Funkcja wyszukiwania w działaniu

Poszukajmy okulisty w kodzie pocztowym 63101. Wyniki wyszukiwania powinny być uporządkowane według następujących kryteriów:

Największe doświadczenie
Najwyższa ocena rekomendacji klientów
Najniższa opłata za konsultację wstępną

Oto kod:

SELECT doctor_name, hospital_name, practicing_from, first_consultation_fee, recomm_count FROM
(SELECT d.doctor_id, d.first_name || ‘ ‘ || d.last_name as doctor_name, 
ha.hospital_name, d.practicing_from, o.first_consultation_fee 
FROM office o, doctor d, doctor_specialization ds, specialization s, hospital_affiliation ha 
WHERE o.doctor_id = d.id AND d.id = ds.doctor_id 
AND s.id = ds.specialization_id AND s.specialization_name = ‘Ophthalmologist’
AND o.hospital_affiliation_id = ha.id (+)
AND o.zip = ‘63101’) doctor_detail, 
(SELECT doctor_id, count(1) as recomm_count FROM client_review 
WHERE is_doctor_recommended = ‘Y’ GROUP BY doctor_id) review_count
WHERE doctor_detail.doctor_id = review_count.doctor_id
ORDER BY doctor_detail.practicing_from DESC, review_count.recomm_count DESC doctor_detail.first_consultation_fee ASC;

Co byś dodał?

Co jeszcze można dodać do tej aplikacji i tego modelu danych? Podziel się swoimi poglądami w komentarzach.