Система онлайн регистрации в поликлинике

PHP также поддерживает "общение"  с другими сервисами с использованием  таких протоколов, как LDAP, IMAP, SNMP, NNTP, POP3, HTTP, COM (на платформах Windows) и многих других. Кроме того, мы имеем возможность работать с сетевыми сокетами "напрямую". PHP поддерживает стандарт обмена сложными структурами данных WDDX. Обращая внимание на взаимодействие между различными языками, следует упомянуть о поддержке объектов Java и возможности их использования в качестве объектов PHP [4].

PHP способен не только выдавать HTML. С помощью PHP возможно формирование изображений, файлов PDF и даже роликов Flash (с использованием libswf и Ming), создаваемых "на лету". PHP также способен выдавать любые текстовые данные, такие, как XHTML и другие XML-файлы, осуществлять автоматическую генерацию таких файлов и сохранять их в файловой системе вашего сервера вместо того, чтобы отдавать клиенту, организуя, таким образом, кеш динамического содержания, расположенный на стороне сервера.

Таким образом, способности PHP поистине поражают. Далеко не все они, безусловно, были использованы при разработке приложения, но возможность использования их в дальнейшем, при доработке и совершенствовании приложения, в совокупности с понятным, несложным синтаксисом и легкостью написания, нетребовательностью к среде разработке, склонили выбор в сторону PHP.

 

 

ГЛАВА 2. АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ И СОЗДАНИЕ МОДЕЛИ ПРИЛОЖЕНИЯ

 

2.1. Анализ предметной области. Концептуальная модель базы данных.

Итак, как уже говорилось выше, наше приложение предназначено для онлайн регистрации в поликлинике. Проанализировав поставленную задачу,  изложим предполагаемую структуру и функции приложения.

1. В первую очередь, приложение должно содержать список поликлиник города, к которым будут прикрепляться пациенты.
2. В каждой поликлинике есть некоторое количество врачей.
3. Кроме того, к каждой поликлинике прикрепляется список зарегистрировавшихся пациентов.
4. И врачи, и пациенты обладают рядом схожих черт, например имя и фамилия, год рождения. Выделим эти черты в отдельную сущность – персона.
5. У каждой персоны есть адрес, состоящий из названия города, улица, номера дома. Кроме того, адрес может быть также у поликлиники.
6. Каждая поликлиника отвечает за некоторую часть города, которая обычно выражается списком улиц. Выделим улицу в отдельную сущность, она пригодится нам еще после – при распределении пациентов между поликлиниками.
7. Поликлиника состоит из кабинетов, большинство из которых закреплены за специалистами, которые ведут в них прием.
8. Каждый врач в поликлинике имеет свою специализацию, которая, кроме прочего, будет определять продолжительность приема этого специалиста.
9. У каждого врача есть свой график работ, отражающий часы приема в тот или иной день недели в виде некоторого временного промежутка.
10. Этот временной период, характеризующийся временем начала и временем окончания также выделим в отдельную сущность.
11. Введем понятие «талончика», которому соответствует одно посещение врача пациентом. Каждому талончику соответствует временной промежуток, который мы выделили ранее.
12. Рабочий день доктора представляется в виде списка таких посещений. Введем отдельную сущность, которая будет хранить «талончики» за определенную дату для каждого врача.
13. У пациента есть история болезни.
14. История болезни представляет собой список предыдущих посещений врача. Каждому посещению поставлен в соответствие один из «талончиков».

Исходя из всего вышесказанного, можно создать концептуальную модель базы данных.

 

Рис.1 Концептуальная модель базы данных.

 

2.2. Распределение ролей пользователей. Диаграмма переходов.

Выше, мы уже говорили о  том, что в нашем приложении будет  несколько пользователей различного рода. Во-первых, это будут пациенты, во-вторых, врачи, и, в-третьих, администраторы приложения.

В связи с этим, позже, уже в физическую модель базы данных, нами будет добавлена еще одна таблица, не имеющая отношения к  предметной базе, как таковой, но хранящая учетные записи пользователей.

Мы поговорим об этом позже, а сейчас речь пойдет о том, какие  действия смогут выполнять различные  пользователи в системе.

Изначально все пользователи попадают на страницу приветствия. Мы уже говорили о том, что врачи  не смогут зарегистрироваться в системе  самостоятельно. Также понятно, что  никто не сможет сам зарегистрироваться как администратор системы.

Таким образом, любой пользователь, который пройдет регистрацию, будет  известен системе, как пациент. После  регистрации, во время которой создается  учетная запись, запись в списке пациентов поликлиники, создается  новая история болезни для  этого пользователя, новая запись в таблице персон, хранящая личные данные, такие как имя, и прочие вспомогательные записи, пациент  переходит на главную страницу приложения.

Также на эту страницу можно  попасть, войдя в систему под  учетной записью пациента.

На главной странице посетитель видит основную информацию о поликлинике, к которой приписан, кроме того, оттуда можно попасть на страницу с историей болезни. Там же расположена ссылка на страницу просмотра и редактирования учетной записи. Кроме этого, на главной странице находится ссылка, перейдя по которой, можно будет записаться на прием к врачу, если последовательно выбрать специалиста, дату, а затем время.

 

Рис.2 Диаграмма переходов для пользователя.

Войдя в систему под  учетной записью врача, пользователь попадает в свой личный кабинет. Там  отражен список пациентов на сегодня  и время, на которое они записаны. Таким образом, врач может планировать  свое время, например, уделяя больше времени  пациенту, если после него образовался  свободный промежуток, или устроив  себе небольшой перерыв для отдыха.

Кроме того, выбрав одну из записей, он может ознакомиться с историей болезни этого пациента, симптомами, которые зафиксировали другие специалисты, их заключениями, и, таким образом, поставить  более точный диагноз.

В процессе приема, или непосредственно  после него, врач заполняет отчет  о приеме пациента.

 

Рис 3. Диаграмма переходов для врача.

Администратор, войдя в  систему, попадает на страницу управления приложением. С этой страницы, перейдя  по ссылкам, он может попасть в  разделы управления поликлиниками, записями врачей и записями других администраторов.

В каждом из этих разделов он может выполнять добавление, удаление и редактирование выбранных записей.

 

Рис 4. Диаграмма переходов для администратора.

 

 

 

ГЛАВА 3. ПРОГРАММНАЯ  РЕАЛИЗАЦИЯ

 

1. Физическая модель базы данных

Итак, в нашей базе данных создадим следующие таблицы:

1. Polyclinic – предназначена для хранения записей о всех поликлиниках города. В ней хранится название поликлиники, и ссылка на адрес – поле ID_Address. Это поле не является обязательным и может быть Null.
2. Room – содержит все помещения поликлиники. Поля этой таблицы – ID_ Polyclinic – поликлиника, в которой расположено данное помещение. Room_Number – номер этого помещения или кабинета.
3. Doctor – таблица, предназначенная для хранения записей о все врачах, закрепленных за поликлиникой. Содержит поля ID_ Polyclinic – ссылка на поликлинику, за которой закреплен этот доктор, поле ID_ Room – ссылка на кабинет, в котором принимает доктор (может быть Null), ID_Specialization – специализация этого доктора, ID_Shedule – график работы врача, ID_Person – ссылка на запись в таблице с личной информацией.
4. Patient – зарегистрированные пациенты. Таблица содержит поля ID_Card – ссылка на личную историю болезни, ID_Person – ссылка на запись в таблице с личной информацией, ID_ Polyclinic – ссылка на поликлинику, за которой закреплен этот пациент, Place_Of_Employment – место работы пациента.
5. Person – таблица для хранения личных данных врачей и пациентов. Содержит в себе такие поля, как First_Name – имя, Last_Name – фамилия, Patronymic – отчество, Date_Of_Birth – дата рождения, Home_Telephone – домашний телефон (может быть Null), ID_Address – ссылка на адрес. В отличие от таблицы поликлиник, это поле является обязательным.
6. Address – таблица, хранящая адреса. В поле City содержит название города – пока это только Гродно, House_Number – номер дома, Apartment_Number – номер квартиры. Также содержит поле ID_Street – ссылка на улицу, которые мы вынесли в отдельную сущность.
7. Street – таблица, содержащая список улиц, за которые отвечают поликлиники. Содержит поле для хранения ссылки на поликлинику – ID_ Polyclinic, а также поле с названием улицы –Name_Of_Street.
8. Specialization – таблица, хранящая список различных специализаций, которые может иметь врач. Содержит поле с названием этой специализацией – Name_ Specialization, и поле, хранящее продолжительность приема для врачей этой специальности – Time_To_Receive.
9. Shedule – сущность, хранящая расписание работы для каждого из врачей. Содержит ссылку на запись в списке врачей – ID_ Doctor. В полях Monday Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday содержит ссылки на определенные временные промежутки, которые отражают время работы врача в соответствующий день.
10. TimePeriod – таблица для хранения временных промежутков различного назначения. Одни предназначены для определения продолжительности рабочего дня доктора, другие служат для ограничении времени приема одного посетителя. Таблица содержит поля с временем начала промежутка и временем окончания промежутка – Time_Begin и Time_End, соответственно.
11. Ticket – временной промежуток, предназначенный для приема одного пациента. Является частью рабочего дня доктора – содержит ссылку на этот рабочий день – ID_ Workday. Кроме того, содержит ссылку на временной промежуток ID_ TimePeriod, ограничивающий его продолжительность.
12. Workday – сущность для хранения совокупности всех записей Ticket, относящихся к этому дню. Содержит поле ID_ Doctor, указывающее на запись врача, которому принадлежит этот день и поле Date_Workday, в котором записана дата этого дня.
13. Card_Patient – сущность, предназначенная для хранения совокупности всех визитов конкретного пациента.
14. Visit – список посещений врача. Хранит ссылку на историю болезни – какого-либо пациента – поле ID_ Card. Один визит соответствует одному талончику – поле ID_ Ticket. Посещение хранит дату – Date_Visit, кроме того есть поле с заключением врача – Report и поле с назначениями – Doctor_Evidence.
15. Users – таблица для хранения учетных записей пользователя. Содержит поле с логином – Login, поле с паролем – Password, тип пользователя(«пациент», «врач», «администратор») – поле Type, ссылка на запись доктора, если пользователь – врач – ID_Doctor(может быть Null), ссылка на запись пациента, если пользователь «пациент» – ID_Patient(может быть Null). В случае если пользователь является администратором – оба эти поля содержат Null. Кроме того, в этой таблице есть поле Description, предназначенное для хранения дополнительной информации о пользователе.

Исходя из вышесказанного создаем физическую модель нашего приложения.

 

 Рис.5 Физическая модель базы данных.

 

3.2. Структура web-приложения

Выделим и рассмотрим несколько основных страниц.

1. Страница приветствия.

Рис.6 Страница приветствия.

 

На странице приветствия  пользователь может войти в систему, если он уже зарегистрирован, или перейти к регистрации. Помним, что регистрироваться в системе можно только в качестве пациента.

2. Страница регистрации.

Рис. 7 Страница регистрации

При регистрации пользователь вводит некоторые личные данные, которые  сохраняются в базе данных в таблице  Персона(Person) и закрепляются за только что созданной записью в списке пациентов.

Мы видим, что при вводе  адреса пациент не выбирает город  – это связано с тем, что  в базе хранятся пока только гродненские  поликлиники. Кроме того, пользователь не вводит улицу, а выбирает из списка. Дело в том, что за каждую улицу  отвечает определенная поликлиника. Чтобы  закрепить пациента за его поликлиникой, мы используем именно эту часть данных. И, чтобы пользователь не смог ввести улицу, которая не закреплена ни за одной поликлиникой (например, его  поликлиника еще не обслуживается  системой, или название улицы введено  с ошибками), он выбирает свою улицу  из списка уже имеющихся. Если пользователь не нашел свою улицу, он может написать письмо администратору (ссылка «Контакты») с просьбой добавить, его письмо будет рассмотрено.

3. Главная страница.

 

Рис.8 Главная страница.

 

 Попав на главную страницу, пользователь может просмотреть свою историю болезни, свой профиль, а также записаться на прием  к врачу.

4. История болезни.

Рис.9 История болезни.

 

На странице с историей болезни, пациент может еще раз просмотреть, например, назначения врача, если он забыл.

5. Запись на прием к врачу. Выбор специалиста.

Рис.10 Запись прием к врачу. Выбор  специалиста.

Пациент может осуществлять поиск по специальностям или по имени  врача,  установив соответствующий  флажок. После выбора, он переходит  к следующему этапу – выбор  даты.

6. Запись на прием к врачу. Выбор даты.

Рис.11 Запись на прием к  врачу. Выбор даты.

 

Выбрав дату, переходим  к выбору конкретного времени. Получим  список талончиков, занятых и не занятых. Выбираем тот, который свободен, нажимаем кнопку «Записаться»

7. «Виртуальный кабинет»

Рис.12 «Виртуальный кабинет»

 

Выбрав один из пунктов, он сможет ознакомиться с историей болезни  выбранного пациента, или заполнить  отчет о приеме – во время приема, или непосредственно после него.

8. Страница администрирования.

Рис.13 Страница администрирования.

 

Переходя по ссылкам, администратор  может управлять различными разделами  приложения – добавлять, удалять  и редактировать записи поликлиник, врачей и других пользователей с учетной записью «Администратор».

 

ЗАКЛЮЧЕНИЕ

В ходе курсовой работы нами была изучена и проанализирована предметная область, после чего составлена база данных, соответствующая этой предметной области.

Корме того, было разработано  веб-приложение, позволяющее редактировать, добавлять, удалять, и отображать содержимое базы удобным для пользователя способом.

Приложение позволяет  регистрироваться в поликлинике  и записываться на прием к специалисту, просматривать свою историю болезни.

Врачам приложение позволит ознакомиться с историей болезни  пациента и добавить новую запись о проведенном приеме.

Кроме этого, в приложении будет администратор, который сможет управлять основными разделами  приложения.

Приложение, на наш взгляд, весьма актуально. В наш век, когда  технологии развиваются очень стремительно, компьютеризация захватывает самые различные сферы жизни человека.

Электронные приложения пользуются большой популярностью. И это  справедливо.

Приложение позволяет  экономить время и энергию, избавляет  от бумажной работы, облегчает каталогизацию  и ведение статистики.

Наше приложение, в частности, избавляет поликлинику от бумажных историй болезни, которые занимают много места, часто теряются, как  вами, так и регистратурой,  приобретают  в процесс использования весьма неприглядный вид и являются пережитками  прошлого века.

Раньше их поиск занимал  весьма продолжительное время, теперь это длиться доли секунды.

Раньше регистратура и  архивы занимали значительную часть  поликлиники, теперь это небольшое  помещение – рабочее место  администратора.

У приложения большие возможности  для дальнейшего развития.

Мы может добавить поликлиники  других городов, возможно, всей страны. Поиск тогда будет осуществляться не только по названию улицы, но и по названию города или села.

На главной странице, кроме  адреса поликлиники, можно добавить схему проезда, или ссылку на карту  системы Google – сейчас это весьма распространенный сервис.