Модел на данни за приложение за резервация на медицински срещи

Резервирането на час при лекар с помощта на онлайн приложение е иновация, която опростява целия процес. Нека се потопим в модела на данни зад приложението за резервиране на срещи.

Защо да използвате приложение? Това улеснява хората да намерят избраните от тях лекари, позволявайки им да видят професионалните досиета на лекаря и прегледите на пациентите. Когато някой намери лекар, който харесва, той може да резервира час с него, без да напуска приложението. Приложението може също да помогне на лекарите да запазят времето за чакане на пациентите си възможно най-кратко, да им помогне да планират пациентите си и да им позволи да следят онлайн прегледите на пациентите.

Изисквания за приложението за медицински срещи

Накратко, очакваме нашето приложение да:

Позволете на пациентите да търсят лекари от различни специализации (семеен лекар, кардиолог, педиатър и др.) по местоположение.
Показване на подреден списък с лекари въз основа на техния дългогодишен опит, разстоянието им от местоположението на пациента, препоръките им за пациентите и техните индекси за преглед (колективна оценка на пациентите за поведение на леглото, време на чакане, персонал и т.н.)
Показване на първоначалните и последващите такси за консултация на лекарите.
Улавяйте и показвайте профилите на лекарите, включително подробности за техните степени, сертификати, стажове и минали и настоящи връзки с болници.
Записвайте отзиви за лекари от потребители на приложението. Този преглед ще даде задълбочен преглед на лекарите и техния персонал за други потребители на приложението.

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

Категоризиране на изискванията за приложения

По принцип можем да разделим изискванията на приложението на тези четири области:

Управление на данните на лекарите – Лекарите могат да се регистрират и да въведат всичките си данни.
Управление на OPD на лекарите (амбулаторно отделение) и подробности за клиниката – Лекарите (или техният персонал) могат да регистрират подробности за своята клиника или график на OPD и наличност.
Управление на данни за клиенти и преглед – Потребителите могат да се регистрират и да въвеждат основните си данни. Те също могат да публикуват отзиви за лекари.
Управление на срещи – Потребителите могат да търсят лекари въз основа на определени критерии.

Нека разгледаме тези области поотделно.

Управление на данните на лекарите

Лекарите могат да се регистрират в приложението, като попълнят определени задължителни данни, но функцията за записване на час се активира само след като попълнят пълния си профил. Това включва техните квалификации (професионални степени, сертификати/специализации и стажове) и техните минали и настоящи връзки с болници и доставчици на здравни услуги.

Таблиците, показани по-долу, управляват тази информация.

doctor таблицата съхранява елементарни данни за лекарите, които те въвеждат при регистрация. Колоните в тази таблица са:

id – Уникален номер, който приложението присвоява на лекарите по време на регистрация.
first_name – Името на лекаря.
last_name – Фамилия на лекаря.
professional_statement – Подробен преглед на квалификацията, опита на лекаря, неговото професионално мото и т.н. Тази информация се въвежда от лекаря и се показва на страницата на профила на всеки лекар.
practicing_from – Датата, на която лекарят е започнал да практикува медицина. Това има голямо значение, тъй като приложението ще извлече своята оценка за опит за всеки лекар въз основа на информацията в тази колона.

specialization таблицата съдържа всички съществуващи медицински специализации като ортопед, невролог, зъболекар и др. Един лекар може да има повече от една специализация; всъщност е доста обичайно лекарят да специализира в свързани области. Например неврологът може да бъде и психиатър; гинекологът може да бъде ендокринолог и т.н. Следователно, doctor_specialization таблица позволява връзка много към много между doctor и specialization маси. Атрибутите на тези две таблици се разбират сами.

qualification таблицата съхранява подробности за образованието и професионалните квалификации на лекарите, включително степени, сертификати, научни статии, семинари, текущо обучение и т.н. За да улесня различните видове квалификационни подробности, дадох на тези полета доста общи имена:

id – Първичният ключ на таблицата.
doctor_id – Препраща към doctor таблица и свързва лекаря с квалификацията.
qualification_name – Означава името на степента, сертификата, научния труд и др.
institute_name – Институцията, издала квалификацията на лекаря. Това може да бъде университет, лечебно заведение, международна асоциация на практикуващите лекари и др.
procurement_year – Датата, на която е получена или присъдена квалификацията.

hospital_affiliation таблицата съхранява информация за връзките на лекарите с болниците и доставчиците на здравни услуги. Тези данни са само за показване в профила на лекар и нямат значение в функцията за записване на час. Данните за OPD (амбулаторно отделение) се въвеждат отделно и ще бъдат разгледани по-късно в тази статия.

Колоните на тази таблица са:

id – Първичният ключ на таблицата.
doctor_id – Препраща към doctor таблица и свързва лекаря със свързаната болница.
hospital_name – Името на свързаната болница.
city and country – Градът и държавата, където се намира болницата. Тези адресни колони не играят никаква роля във функцията за търсене на приложението; те са само за показване в профила на лекаря.
start_date – Когато започва връзката на лекаря с болницата.
end_date – Когато връзката приключи. Тя е нула, тъй като текущите връзки няма да имат крайна дата.

Управление на OPD/подробности за клиниката на лекарите

Информацията в този раздел се въвежда от лекари (или техния персонал) и играе важна роля във функциите за търсене и резервиране на приложението.

office таблицата съдържа информация за амбулаторията на болниците, с които лекарите са свързани, както и техните собствени клиники (т.е. кабинети или хирургии). Колоните в тази таблица са:

id – Първичният ключ на тази таблица.
doctor_id – Препраща към doctor таблица и посочва съответния лекар.
hospital_affiliation_id – Означава болницата, където лекарят е на разположение за OPD. Тъй като колоната е приложима за OPD, но не и за клиники, тя е нула.
time_slot_per_client_in_min – Съхранява количеството време (в минути), отредено за консултации. Броят на минутите се въвежда от лекарите въз основа на техния опит. Тази колона помага на приложението да определи следващия наличен слот. Имайте предвид, че този номер не е гаранция за продължителността на срещата, но помага да се сведе до минимум времето за чакане на пациентите, ако използват приложението, за да резервират час.
first_consultation_fee – Таксата, начислена от лекаря за първоначално посещение. Това може да изглежда маловажно, но е много важно за функцията за търсене; таксата е много често срещан критерий за филтриране.
followup_consultation_fee – Много лекари таксуват по-малко за последващо посещение, отколкото за първоначална консултация. Тази колона съхранява разходите за последваща консултация.
street_address – Адресът на болницата OPD или клиниката.
city , state и country – Град, щат и държава, където се намира болницата или клиниката.
zip – Пощенският код, където се намира клиниката или болницата. Често хората търсят лекари в близките райони с помощта на пощенски код, така че това поле ще бъде важно за функцията за търсене на приложението.

Защо има отделна таблица „офис“, когато подробностите за OPD могат лесно да бъдат проследени в таблицата „hospital_affiliation“?

Три причини:

Лекар може да е свързан с болница за един аспект от работата си (т.е. извършване на операции), но не и за други (т.е. преглеждане на пациенти). Може да загубим такива връзки, ако се опитаме да запазим подробности за офиса в hospital_affiliation само маса.
Много лекари не са свързани с болници, но имат свои собствени клиники или кабинети. Трябва да съхраняваме информация и за тези лекари.
Един лекар може да има няколко кабинета на различни места или да работи в няколко клона на болница. Ако е показано, че лекарят е свързан само с едно болнично място, можем да загубим част от информацията. Това е причината да поддържаме отделни данни за адреса.

office_doctor_availability таблицата съхранява наличността на OPD/клиниката на лекарите по отношение на времеви интервали (да речем 2 часа сутрин и 4 часа вечер). Разделянето на деня по този начин е доста често срещано явление, така че има смисъл да имате допълнителна маса за съхранение на слотове за наличност. Освен това лекарите могат да работят повече от една смяна на OPD. Колоните за тази таблица са:

id – Първичният ключ на таблицата.
office_id – Препраща към таблицата „офис“.
day_of_week – Денят от седмицата, т.е. понеделник, вторник и т.н. Това позволява на лекарите да имат различни наличности за различните дни (например през уикендите спрямо делничните дни).
start_time – Когато лекарят е готов за първия пациент.
end_time – Когато е планирано да приключи последната среща или смяна.
is_available – Позволява на лекарите да маркират наличността си за определени дни или времеви интервали. Тази колона се инициализира с „Y“ по подразбиране и се актуализира до „N“, когато лекарите отбележат липсата им.
reason_of_unavailablity – Много лекари предпочитат да разкрият защо не са на разположение или трябва да отменят час. Това помага да се изградят прозрачни отношения между лекарите и техните пациенти. Тъй като не е задължително, запазих тази колона с нула.

in_network_insurance таблицата съхранява застрахователна информация. В много страни медицинските услуги са много скъпи и здравното осигуряване е задължително. В такива случаи тази таблица съдържа подробности за това кои застрахователни компании са напълно приети в болничната OPD или клиниката.

Управление на данни за клиенти и преглед

За пациент регистрацията за приложението изисква много малко информация. От тук нататък ще използвам „клиент“, а не „потребител“ или „пациент“.

client_account таблицата съхранява основни подробности за клиентите. Тези подробности се записват в момента на регистрация. Колоните в тази таблица са:

id – Уникален номер, присвоен на всеки клиент.
first_name – Име на клиента.
last_name – Фамилия на клиента.
contact_number – Телефонен номер на клиента, за предпочитане мобилен номер, на който може да се изпраща информация за среща. Това е и номерът, на който персоналът на лекарския кабинет може да се свърже с клиента.
email – имейл адрес на клиента. Приложението може да изпраща напомняния за срещи на клиенти.

client_review таблицата не само предлага обратна връзка (т.е. отзиви на клиенти) за лекарите, но също така помага на потенциалните клиенти да изберат лекари. Това е неразделна част от това приложение. Колоните за тази таблица са:

id – Първичният ключ на тази таблица.
user_account_id – Означава кой потребител изпраща прегледа.
doctor_id – Преглежданият лекар.
is_review_anonymous – Дали името на клиента ще бъде публикувано с рецензията или не. Това е функция за сигурност за клиентите.
wait_time_rating – Тази колона с числа съдържа рейтинг от 1 (най-лош) до 10 (най-добър). То отразява мнението на клиента за това колко време е чакал да види лекаря.
bedside_manner_rating – Съхранява мнението на клиента за поведението на лекаря до леглото (т.е. ако лекарят е мил, състрадателен, комуникира добре и т.н.)
overall_rating – Оценка на клиента за общия им опит с лекаря.
review – Клиентите могат да дадат своите подробни отзиви тук.
is_doctor_recommended – Тази колона за индикатор показва дали клиентът би препоръчал лекаря.
review_date – Кога е изпратен прегледът.

Управление на срещи

Този раздел е най-важният USP (Unique Selling Point) за това приложение, тъй като позволява на клиентите да проверят наличността на различни лекари и да резервират час.

appointment таблицата съдържа подробности за срещи за клиенти. Неговите колони включват:

id – На всяка среща се присвоява уникален номер. Този номер е посочен другаде.
user_account_id – Кой клиент записва срещата.
office_id – Означава кой лекар и коя болница OPD или клиника участва в назначаването.
probable_start_time – Това е колона с времеви отпечатък, която съдържа вероятния начален час на срещата. Началните часове на медицинските срещи обикновено са вероятни, отколкото абсолютни.
actual_end_time – Действителното крайно време на консултацията. Първоначално тази колона е празна, тъй като много фактори могат да повлияят на края на срещата. Следователно това е колона с нула.
appointment_status_id – Това се препраща от appointment_status таблица и означава текущото състояние на срещата. Възможните стойности за състояние са „активен“, „отменен“ и „завършен“. Първоначално статусът ще бъде „активен“. Той ще стане „завършен“, след като назначението бъде извършено. Той ще стане „отменен“, ако клиентът отмени срещата си.
appointment_taken_date – Датата, на която е направена среща.
app_booking_channel_id – Каналът, през който е резервирана среща. Има множество канали, чрез които се правят срещи:чрез приложението, чрез обаждане в болницата, чрез обаждане на лекаря или техния кабинет и т.н.

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

Функцията за търсене в действие

Нека потърсим офталмолог в пощенски код 63101. Резултатите от търсенето трябва да бъдат подредени по следните критерии:

Най-много опит
Най-висока оценка на клиентските препоръки
Най-ниска такса за първоначална консултация

Ето кода:

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;

Какво бихте добавили?

Какво друго може да се добави към това приложение и този модел на данни? Споделете вашите мнения в коментарите.