Разработка серверной части агрегатора платных медицинских услуг

Размещено на http://www.allbest.ru/

Разработка серверной части агрегатора платных медицинских услуг



Введение

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

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

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

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

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

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

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

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

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

провести анализ бизнес процессов;

провести анализ существующих решений для поиска и записи к врачам;

сформировать требования к информационной системе;

провести анализ инструментальных средств разработки;

спроектировать use case диаграмму;

выполнить проектирование базы данных системы;

реализовать систему;

привести технико-экономическое обоснование разработки системы.

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



1. Анализ процесса поиска и записи к врачу

медицинский серверный информационный

1.1 Анализ бизнес процессов поиска клиники и записи на прием к врачу

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

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

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

После записи к врачу пациент приходит в назначенное время в клинику и проходит к нему на прием. Во время приема врач осматривает пациента, ставит диагноз и дает рекомендации пациенту. Данные о приеме врач записывает в бумажную карту пациента, которая хранится в клинике. Действия медицинских организаций регламентируются Федеральным законом №323 «Об основах охраны здоровья граждан», законом о защите прав потребителей, порядками и стандартами медицинской помощи, санитарными требованиями к медицинским учреждениям и другими документами.

Для лучшего восприятия ниже приведены рис. 1.1, рис. 1.2, рис. 1.3 и рис 1.4 созданные по технологии IDEF0 «as-is», на которых изображены бизнес процессы, происходящие при записи на прием и посещении врача в частной клинике.

Рисунок 1.1. Посещение врача «as-is»



Рисунок 1.2. Поиск врача декомпозиция «as-is»

Рисунок 1.3. Запись на прием декомпозиция «as-is»



Рисунок 1.4 Посещение врача декомпозиция «as-is»

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

Просмотр информации о клиниках и врачах;

Просмотр и добавление отзывов о клиниках и врачах;

Поиск в системе;

Запись и отмена записи пациента на прием;

Просмотр истории болезни пациента;

Контроль отзывов от пациентов, очистка от спама.

1.2 Анализ существующих решений

На российском рынке существует несколько программных продуктов с похожими функциональными возможностями, однако все они не соответствуют полному списку функциональных возможностей, возложенных на проектируемую информационную систему. Для сравнения возможностей были выбраны три информационных системы: DocDoc, К-Врачу и PRODOCTOROV.

1.2.1 Сервис для поиска врачей DocDoc

Сервис DocDoc был основан в 2011 году. Основные возможности сервиса - это поиск и запись пациентов в коммерческие клиники России. Сервис представляет возможность поиска врачей по таким параметрам как цена приема, специализация, опыт и рейтинг специалиста (рис. 1.5).

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

Рисунок 1.5. Фрагмент экранной формы поиска специалистов



Рисунок 1.6. Фрагмент экранной формы информации о специалисте

DocDoc позволяет произвести запись на прием к выбранному специалисту двумя способами. Первый способ заключается в выборе свободных даты и времени у специалиста онлайн (рис. 1.7)

Рисунок 1.7. Фрагмент экранной формы расписания специалиста



Второй способ записи на прием, это заказ звонка от оператора клиники. Для заказа звонка необходимо заполнить форму с контактной информацией и дождаться звонка оператора (рис. 1.8).

Рисунок 1.8. Фрагмент экранной формы записи к специалисту

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

1.2.2 Портал медицинских услуг К-Врачу

Портал К-Врачу был разработан компанией СВАН и предназначается для увеличения доступности медицинской помощи гражданам. Портал представляет возможность онлайн записи на прием к врачу в государственные медицинские организации. Запись возможна одним из двух способов: выбором свободных даты и времени специалиста, либо с помощью звонка в регистратуру медицинской организации. Одним из главных преимуществ портала является просмотр электронной медицинской карты пациента.

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

Поиск врача в системе возможен по населенному пункту, специализации врача, ближайшей свободной записи, а также по фамилии специалиста (рис. 1.9).

Рисунок 1.9. Фрагмент экранной формы списка специалистов

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

1.2.3 Сервис PRODOCTOROV

Сервис PRODOCTOROV создан в 2011 году компанией МедРейтинг и является агрегатором медицинских учреждений. Сервис позволяет выбрать и произвести онлайн запись на прием к врачу. Администраторами сервиса регулярно проводится очистка отзывов о специалистах от спама, рекламы и другой недостоверной информации. При поиске врача есть возможность произвести фильтрацию врачей по специальности, местоположению, клинике, заболеванию, полу, стажу врача. Также есть возможность выбрать платного или бесплатного врача. На странице специалиста присутствует информация о специальности врача, его стаже работы, его личного рейтинга и стоимости первичного приема (рис. 1.10).

Рисунок 1.10. Фрагмент экранной формы информации о специалисте

Также есть возможность произвести онлайн запись на прием, выбрав свободные дату и время, либо позвонив по указанному на странице телефону (рис. 1.11).

Рисунок 1.11. Фрагмент экранной формы расписания специалиста



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

Таблица 1.1. Сравнительный анализ существующих информационных систем

Возможность записи родственников на прием Нет Да Нет

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

1.3 Архитектура разрабатываемой системы

Архитектура разрабатываемой системы должна удовлетворять клиент-требованиям:

Клиентское приложение (далее - клиент).

Серверное приложение (далее - сервер).

База данных.

Взаимодействие между компонентами представлено на рис. 1.12 в виде диаграммы компонентов.

Рисунок 1.12. Взаимодействие между компонентами

Алгоритм работы разрабатываемой системы представлен на рис. 1.13

Рисунок 1.13. Диаграмма последовательности



Описание компонентов системы:

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

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

База данных - реализует хранение данных системы, взаимодействие с серверной частью осуществляется с помощью запросов.

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

1.4 Анализ инструментальных средств разработки

Важным шагом при проектировании информационной системы является выбор инструмента разработки. В качестве сравнения были рассмотрены три самых популярных фреймворка для PHP: Yii, Laravel и Symfony.

1.4.1 Фреймворк Yii

Yii - это бесплатный PHP фреймворк, позволяющий разрабатывать любые виды веб-приложений, благодаря своей основе компонентов, архитектуре и сложной поддержке кэширования. Фреймворк предоставляет множество проверенных и готовых к использованию функций, таких как построитель запросов и ActiveRecord для реляционных и NoSQL баз данных и RESTful API.

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

1.4.2 Фреймворк Laravel

Laravel - PHP фреймворк с открытым исходным кодом, который на данный момент является самым популярным среди западных разработчиков веб-приложений. С помощью менеджера пакетов Composer, фреймворк позволяет устанавливать и подключать компоненты для использования в приложении. Шаблон ActiveRecord - Eloquent ORM, позволяет установить отношения между объектами базы данных веб-приложения и выстраивать удобные запросы для манипуляции данными.

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

1.4.3 Фреймворк Symfony

Symfony - свободный фреймворк для быстрой разработки веб-приложений, состоящий из набора не связанных между собой компонентов, которые можно использовать повторно в проектах. Работа с базой данных обеспечивается интеграцией с библиотекой Doctrine.

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

1.4.4 Сравнительный анализ инструментальных средств разработки

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

Таблица 1.2. Сравнительный анализ фреймворков

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



1.5 Анализ систем управления базами данных

Важным параметром для разработки серверной части информационной системы является система управления базами данных (СУБД), в настоящее время наиболее популярными системами являются: Oracle, MySQL и PostgreSQL, которые и были выбраны для анализа СУБД.

1.5.1 СУБД Oracle

СУБД Oracle является одной из наиболее мощных современных систем управления базами данных, предназначенных для реализации баз данных уровня корпорации. Oracle располагает удобными и мощными средствами администрирования не только одного сервера, но и группы серверов.

Основными преимуществами можно считать поддержку баз данных объема до 64 Гбайт, мощные средства разработки и администрирования. Главными минусами являются серьезные аппаратные требования и высокая стоимость.

1.5.2 СУБД MySQL

СУБД MySQL получила широкое распространение в качестве средства работы с базами данных в веб-приложениях. Данная система нетребовательна к ресурсам сервера, очень быстрая и надежная, также следует отметить то, что данная система является бесплатной.

К основным преимуществам MySQL относят открытость исходного кода, быстродействие, безопасность и надежность. В настоящее время производительность MySQL сопоставима с такими СУБД как Oracle и MS SQL Server.

1.5.3 СУБД PostgreSQL

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

1.5.4 Сравнительный анализ СУБД

Критериями для оценки систем управления базами данных могут служить такие показатели как надежность, производительность, безопасность, а также системные требования СУБД. Результат сравнения данных систем управления базами данных представлен в табл. 1.3.

Таблица 1.3. Сравнительный анализ СУБД

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



2. Проектирование информационной системы для поиска клиники и записи на прием к врачу

2.1 Формализация функциональных требований к системе

Для проектирования информационной системы необходимо формализовать требования к проектируемой системе. Исходя из анализа предметной области к системе были предъявлены следующие функциональные требования:

регистрация пользователей;

авторизация пользователей;

просмотр пользователями информации о клиниках и врачах;

просмотр пользователями отзывов о клиниках и врачах;

добавление пациентами отзывов о клиниках и врачах;

поиск в системе;

запись пациента на прием;

отмена записи пациента на прием;

добавление и редактирование контактных данных пациента;

добавление и редактирование информации о клинике;

добавление и редактирование расписания работы врача;

добавление врачами данных в историю болезни пациента;

просмотр врачами и пациентами истории болезни пациента;

удаление отзывов администратором системы;

удаление пользователей администратором системы;

выдача администратором системы прав пользователя.

Рассмотрим диаграммы процесса посещения врача после внедрения информационной системы, которые представлены на рис. 2.1, рис. 2.2, рис. 2.3 и рис. 2.4.



Рисунок 2.1. Посещение врача «to-be»

Рисунок 2.2. Поиск врача декомпозиция «to-be»



Рисунок 2.3. Запись на прием декомпозиция «to-be»

Рисунок 2.4. Посещение врача декомпозиция «to-be»

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



2.2 Разработка Use Case диаграммы

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

Основываясь на описании предметной области и сформулированных прецедентов, диаграмма Use Case (диаграмма прецедентов) будет включать в себя пятерых "актеров" «Пациент», «Специалист клиники», «Администратор клиники», «Администратор системы» и «Неавторизованный пользователь». Диаграмма прецедентов представлена на рис. 2.5.

Рисунок 2.5. Диаграмма Use Case



2.3 Спецификация прецедентов

Триггер: Новый пользователь хочет зарегистрироваться в информационной системе.

Таблица 2.1. Описание прецедента "Регистрация"

Альтернативные потоки:

Е1: Логин занят. Выдается сообщение о невозможности использования логина. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Авторизация.

Актор: Неавторизованный пользователь.

Краткое описание: пользователь вводит логин и пароль и нажимает кнопку «Войти».

Триггер: Неавторизованный пользователь хочет пройти авторизацию.

Таблица 2.2. Описание прецедента "Авторизация"



Альтернативные потоки:

Е1: Логин или пароль введены неверно. Выдается сообщение на экран о том, что логин или пароль введены неверно. Прецедент завершается.

Название: Поиск в системе.

Актор: Неавторизованный пользователь, пациент, специалист клиники, администратор клиники.

Краткое описание: пользователь ищет клинику или врача по названию или ФИО специалиста.

Триггер: Пользователь хочет найти клинику или специалиста.

Таблица 2.3. Описание прецедента "Поиск в системе"

Альтернативные потоки:

Е1: Данные по поисковой строке не найдены. Выводится сообщение об отсутствии данных. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не находится. Прецедент завершается.

Название: Просмотр информации о специалистах.

Актор: Неавторизованный пользователь, пациент, специалист клиники, администратор клиники.

Краткое описание: пользователь просматривает информацию о специалисте клиники.

Триггер: Пользователь хочет просмотреть информацию о специалисте клиники.



Таблица 2.4. Описание прецедента "Просмотр информации о специалистах"

Альтернативные потоки:

Е1: БД не отвечает. БД перестает отвечать. Запись не находится. Прецедент завершается.

Название: Просмотр информации о клиниках.

Актор: Неавторизованный пользователь, пациент, специалист клиники, администратор клиники.

Краткое описание: пользователь просматривает информацию о клинике.

Триггер: Пользователь хочет просмотреть информацию о клинике.

Таблица 2.5. Описание прецедента "Просмотр информации о клиниках"

Таблица 2.6. Описание прецедента "Просмотр истории болезни"

Альтернативные потоки:

Е1: История болезни пуста. Отображение сообщения об отсутствии истории болезни. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не находится. Прецедент завершается.

Название: Запись на прием.

Актор: Пациент, администратор клиники.

Краткое описание: пользователь производит запись на прием к врачу.

Триггер: Пользователь хочет записаться к врачу.

Таблица 2.7. Описание прецедента "Запись на прием"

Альтернативные потоки:

Е1: Время занято. Отображение сообщения о занятом времени. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Отмена записи на прием.

Актор: Пациент, администратор клиники.

Краткое описание: пользователь производит отмену записи на прием к врачу.

Триггер: Пользователь хочет отменить запись к врачу.

Таблица 2.8. Описание прецедента "Отмена записи на прием"

Е1: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Просмотр отзывов.

Актор: Пациент, специалист клиники, неавторизованный пользователь, администратор клиники, администратор системы.

Краткое описание: пользователь просматривает отзывы о враче/клинике.

Триггер: Пользователь хочет просмотреть отзывы о враче/клинике.

Таблица 2.9. Описание прецедента "Просмотр отзывов"

Таблица 2.10. Описание прецедента «Добавление отзывов»

Альтернативные потоки:

Е1: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Редактирование контактных данных.

Актор: Пациент.

Краткое описание: пользователь редактирует свои контактные данные.

Триггер: Пользователь хочет отредактировать свои контактные данные.



Таблица 2.11. Описание прецедента "Редактирование контактных данных"

Альтернативные потоки:

Е1: Данные введены в некорректном формате. Отображение сообщения о некорректности данных. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Выдача прав пользователя.

Актор: Администратор системы.

Краткое описание: администратор системы дает права специалисту клиники или администратору клиники.

Триггер: Пользователь хочет выдать права доступа.

Таблица 2.12. Описание прецедента "Выдача прав пользователя"

Альтернативные потоки:

Е1: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Удаление отзывов.

Актор: Администратор системы.

Краткое описание: администратор системы удаляет отзыв.

Триггер: Пользователь хочет удалить отзыв.

Таблица 2.13. Описание прецедента "Удаление отзывов"

Альтернативные потоки:

Е1: Пользователь передумывает и нажимает кнопку «Отмена». Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не удаляется. Прецедент завершается.

Название: Удаление пользователя.

Актор: Администратор системы.

Краткое описание: администратор системы удаляет пользователя.

Триггер: Пользователь хочет удалить пользователя.

Таблица 2.14. Описание прецедента "Удаление пользователей"



Альтернативные потоки:

Е1: Пользователь передумывает и нажимает кнопку «Отмена». Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не удаляется. Прецедент завершается.

Название: Редактирование личной информации врача.

Актор: Специалист клиники, администратор клиники.

Краткое описание: пользователь редактирует свои данные.

Триггер: Пользователь хочет отредактировать свои данные.

Таблица 2.15. Описание прецедента "Редактирование личной информации врача"

Альтернативные потоки:

Е1: Данные введены в некорректном формате. Отображение сообщения о некорректности данных. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Добавление данных в историю болезни.

Актор: Специалист клиники.

Краткое описание: пользователь добавляет данные в историю болезни.

Триггер: Пользователь хочет добавить данные в историю болезни.



Таблица 2.16. Описание прецедента "Добавление данных в историю болезни "

Альтернативные потоки:

Е1: Данные введены в некорректном формате. Отображение сообщения о некорректности данных. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Редактирование расписания работы врача.

Актор: Специалист клиники, администратор клиники.

Краткое описание: пользователь редактирует расписание работы врача.

Триггер: Пользователь хочет отредактировать расписание работы врача.

Таблица 2.17. Описание прецедента "Редактирование расписания работы врача"



Альтернативные потоки:

Е1: Данные введены в некорректном формате. Отображение сообщения о некорректности данных. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

Название: Редактирование информации о клинике.

Актор: Администратор клиники.

Краткое описание: пользователь редактирует информацию о клинике.

Триггер: Пользователь хочет отредактировать информацию о клинике.

Таблица 2.18. Описание прецедента "Редактирование информации о клинике"

Альтернативные потоки:

Е1: Данные введены в некорректном формате. Отображение сообщения о некорректности данных. Прецедент завершается.

Е2: БД не отвечает. БД перестает отвечать. Запись не сохраняется. Прецедент завершается.

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



Рисунок 2.6 Прецедент «Просмотр истории болезни»

Рассмотрим процесс «Записи на прием» подробнее на диаграмме активности, которая приведена на рис. 2.7. Прецедент «Запись на прием». Пользователь открывает страницу врача, открывает расписание врача, выбирает свободную запись, после чего получает уведомление о записи на прием.



Рисунок 2.7. Прецедент «Запись на прием»

2.4 Проектирование базы данных

Исходя из описания бизнес-процессов можно выделить несколько блоков данных, которые будут использоваться в системе:

Сведения о клинике:

наименование;

сведения о специализации;

город

адрес;

телефон;

описание.

Сведения о специалисте:

сведения о виде активности;

ФИО;

год начала работы;

сведения об образовании;

сведения о курсах повышения квалификации;

категория;

стоимость первичного приема;

рабочий телефон

описание;

ключевые навыки;

электронная почта;

пароль для входа в систему.

Сведения об отзывах:

сведения о специалисте;

сведения о клинике;

сведения о пациенте;

оценка;

отзыв.

Сведения о пациенте:

ФИО

e-mail;

роль;

пароль для входа в систему.

Сведения о связи клиники и специалиста:

сведения о клинике;

сведения о специалисте.

Сведения о расписании:

сведения о клинике;

сведения о специалисте;

день недели;

время начала работы;

время окончания работы.

Сведения о занятом времени:

сведения о клинике;

сведения о специалисте;

сведения о пациенте;

дата;

время.

Сведения о временном отсутствии специалиста:

сведения о клинике;

сведения о специалисте;

дата начала отсутствия;

дата окончания отсутствия.

Сведения о медицинской карте:

сведения о пациенте;

сведения о специалисте, проводившем прием;

дата приема;

поставленный диагноз;

описание;

рекомендации.

На основе полученных данных была составлена ER-диаграмма, представленная на рис. 2.8.



Рисунок 2.8. ER-диаграмма

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



Описание полей, используемых в таблицах, представлено в табл. 2.19.

Таблица 2.19. Описание данных



3. Разработка информационной системы

3.1 Анализ интегрированных сред разработки

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

3.1.1 Интегрированная среда разработки NetBeans

Интегрированная среда разработки для языка программирования PHP, создание которой было начато еще в 1996 году. Имеет поддержку русского и английского языков. Основными функциями среды редактирования являются:

редактор автоматического завершения PHP кода с заложенной подсветкой синтаксиса, ошибок, вхождений;

отладка кода;

удобный интерфейс;

система навигации;

просмотр истории работы с файлом.

Расширение возможностей системы возможно при помощи установки дополнительных плагинов.

3.1.2 Интегрированная среда разработки PHP Storm

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

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

3.1.3 Интегрированная среда разработки Eclipse PDT

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

Данная интегрированная среда имеет возможность сворачивать часть кода в одну строку, имеет возможность рефакторинга, редактор также производит анализ кода и в случае необходимости исправляет его самостоятельно. Eclipse PDT позволяет производить локальную отладку PHP-скриптов, а также имеет возможность объединения с Zend Server и XDebug и производить отладку с их помощью.

3.1.4 Сравнительный анализ интегрированных сред разработки

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



Таблица 3.1. Сравнительный анализ интегрированных сред разработки

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

3.2 Описание API системы

В соответствии с задачами, решаемыми в системе, реализованы методы REST API для полноценной работы системы. В табл. 3.2 представлено описание методов, необходимых для решения поставленной задачи.



Таблица 3.2. Описание методов API

3.3 Описание работы основных методов

База данных для информационной системы создана при помощи миграций. При помощи миграций созданы следующие таблицы:

clinic;

schedule;

activity;

clinic_specialist;

busy_time;

absence;

specialist;

patient;

review;

medical_card;

speciality.

На рис. 3.1 представлен листинг файла миграции для создания таблицы с данными о клинике.

<?php

use Illuminate\Support\Facades\Schema;

use Illuminate\Database\Schema\Blueprint;

use Illuminate\Database\Migrations\Migration;

class Clinic extends Migration

{

/**

* Run the migrations.

*

* @return void

*/

public function up()

{

Schema::create('clinic', function (Blueprint $table) {

$table->integer('id')->index()->autoIncrement();

$table->string('name');

$table->string('id_speciality');

$table->string('town');

$table->string('address');

$table->string('phone');

$table->string('description');

});

}

/**

* Reverse the migrations.

*

* @return void

*/

public function down()

{

Schema::drop('clinic');

}

}



Рисунок 3.1. Листинг файла миграции данных о клинике

Класс Clinic содержит в себе 2 функции. Функция up позволяет создать таблицу clinic с заданной структурой. Функция down позволяет удалить таблицу clinic.

Для получения, добавления, удаления и редактирования данных были разработаны API сервисы. Листинг файла с сервисами представлен на рис. 3.2.

<?php

/** Clinic */

Route::get('/getclinic/{id?}','ClinicController@getClinics');

Route::get('/getspecforclinic/{id}','ClinicController@getSpecForClinic');

Route::post('/add/clinicspecialist','ClinicController@createClinicSpecialist');

Route::post('/add/clinic','ClinicController@createClinic');

Route::post('/add/speciality','ClinicController@createSpeciality');

Route::post('/edit/clinicspecialist','ClinicController@editSpecForClinic');

Route::post('/edit/clinic','ClinicController@editClinic');

Route::post('/edit/speciality','ClinicController@editSpeciality');

Route::post('/delete/clinicspecialist/{id}','ClinicController@deleteClinicSpecialist');

Route::post('/delete/clinic/{id}','ClinicController@ deleteClinic');

Route::post('/delete/speciality/{id}','ClinicController@deleteSpeciality');

/** Specialist */

Route::get('/getspecialist/{id?}','SpecialistController@getSpecialist');

Route::get('/getspecialistreview/{id}','SpecialistController@getSpecialist');

Route::post('/add/schedule','SpecialistController@createSchedule');

Route::post('/add/activity','SpecialistController@createActivity');

Route::post('/add/absence','SpecialistController@createAbsence');

Route::post('/add/specialist','SpecialistController@createSpecialist');

Route::post('/edit/schedule','SpecialistController@editSchedule');

Route::post('/edit/activity','SpecialistController@editActivity');

Route::post('/edit/absence','SpecialistController@editAbsence');

Route::post('/edit/specialist','SpecialistController@editSpecialist');

Route::post('/delete/schedule/{id}','SpecialistController@deleteSchedule');

Route::post('/delete/activity/{id}','SpecialistController@deleteActivity');

Route::post('/delete/absence/{id}','SpecialistController@deleteAbsense');

Route::post('/delete/specialist/{id}','SpecialistController@deleteSpecialist');

/** Patient */

Route::get('/getuserdata/{id}','PatientController@getUserData');

Route::get('/getuserbusytime/{id}','PatientController@getUserBusyTime');

Route::post('/add/review','PatientController@createReview');

Route::post('/add/busytime','PatientController@createUserBusyTime');

Route::post('/add/medicalcard','PatientController@createMedicalCard');

Route::post('/edit/review','PatientController@editReview');

Route::post('/edit/patient','PatientController@editPatient');

Route::post('/edit/busytime','PatientController@editUserBusyTime');

Route::post('/edit/medicalcard','PatientController@editMedicalCard');

Route::post('/delete/review/{id}','PatientController@deleteReview');

Route::post('/delete/patient/{id}','PatientController@deletePatient');

Route::post('/delete/busytime','PatientController@deleteBusytime');

Route::post('/delete/medicalcard','PatientController@deleteMedicalCard');

/** Option */

Route::get('/getsearchresult','OptionController@getSearchResult');

Route::post('/registration','OptionController@createPatient');

Route::get('/auth','OptionController@getAuthData');

Рисунок 3.2. Листинг файла миграции данных о клинике

Для работы API сервисов были разработаны 4 управляющих контроллера системы:

ClinicController;

PatientController;

SpecialistController;

OptionController.

Рассмотрим листинг файла контроллера ClinicController представленный на рис. 3.3.

<?php

namespace App\Http\Controllers;

use Illuminate\Foundation\Bus\DispatchesJobs;

use Illuminate\Http\Request;

use Illuminate\Routing\Controller as BaseController;

use Illuminate\Foundation\Validation\ValidatesRequests;

use Illuminate\Foundation\Auth\Access\AuthorizesRequests;

use Illuminate\Support\Facades\DB;

/** Clinic speciality clinic_specialist**/

class ClinicController extends BaseController

{

use AuthorizesRequests, DispatchesJobs, ValidatesRequests;

public function getClinics($id = 0)

{

try {

if ($id == 0) {

$data = DB::table('clinic')

->get();

} else {

$data = DB::table('clinic')

->where('id', '=', $id)

->get();

}

return response()->json($data, 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function getSpecForClinic($id)

{

try {

$data = DB::table('clinic')

->join('clinic_specialist', 'clinic.id', '=', 'clinic_specialist.id_clinic')

->join('specialist', 'specialist.id', '=', 'clinic_specialist.id_specialist')

->leftJoin('activity', 'specialist.id_activity', '=', 'activity.id')

->where('clinic.id', '=', $id)

->select('specialist.id as spec_id', 'specialist.fio', 'specialist.year_start_work', 'specialist.education',

'specialist.courses', 'specialist.category', 'specialist.first_price', 'specialist.phone',

'specialist.description as spec_decs', 'activity.name', 'clinic.id as clinic_id',

'clinic.name as clinic_name', 'clinic.speciality as clinic_speciality', 'clinic.town as clinic_town',

'clinic.address as clinic_address', 'clinic.phone as clinic_phone', 'clinic.description as clinic_desc')

->get();

return response()->json($data, 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function createClinic(Request $request)

{

try {

DB::table('clinic')->insert([

[

'name' => $request->name,

'id_speciality' => $request->id_speciality,

'town' => $request->town,

'address' => $request->address,

'phone' => $request->phone,

'description' => $request->description

]

]);

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function createSpeciality(Request $request)

{

try {

DB::table('speciality')->insert([

[

'name' => $request->name,

]

]);

return response()->json('success', 200);

Продолжение рисунка 3.3. Листинг файла контроллера ClinicController

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function createClinicSpecialist(Request $request)

{

try {

DB::table('clinic_specialist')->insert([

[

'id_clinic' => $request->id_clinic,

'id_specialist' => $request->id_specialist,

]

]);

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function editSpecForClinic(Request $request)

{

try {

DB::table('clinic_specialist')->where('id', $request->id)

->update([

'id_clinic' => $request->id_clinic,

'id_specialist' => $request->id_specialist

]);

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function editClinic(Request $request)

{

try {

DB::table('clinic')->where('id', $request->id)

->update([

'name' => $request->name,

'id_speciality' => $request->id_speciality,

'town' => $request->town,

'address' => $request->address,

'phone' => $request->phone,

'description' => $request->description

]);

return response()->json('success', 200);

Продолжение рисунка 3.3. Листинг файла контроллера ClinicController

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function editSpeciality(Request $request)

{

try {

DB::table('speciality')->where('id', $request->id)

->update([

'name' => $request->name

]);

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function deleteClinic($id)

{

try {

DB::table('clinic')

->where('id', $id)

->delete();

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function deleteClinicSpecialist($id)

{

try {

DB::table('clinic_specialist')

->where('id', $id)

->delete();

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

public

function deleteSpeciality($id)

{

try {

DB::table('speciality')

->where('id', $id)

Продолжение рисунка 3.3. Листинг файла контроллера ClinicController

->delete();

return response()->json('success', 200);

} catch (\Exception $e) {

return response()->json('failed', 500);

}

}

}

Продолжение рисунка 3.3. Листинг файла контроллера ClinicController

Класс ClinicController содержит в себе несколько функций для работы с данными о клинике.

Функция getClinics, принимает необязательный параметр id - идентификатор клиники. Внутри функции выполняется запрос к базе данных, в результате которого программа получает данные о всех клиниках, либо одной клинике, в зависимости от наличия переданного параметра. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция getSpecForClinics, принимает параметр id - идентификатор клиники. Внутри функции выполняется запрос к базе данных, в результате которого программа получает данные о специалистах, привязанных к выбранной клинике. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция createSpeciality принимает в себя параметр request, который содержит в себе значение поля name.

Внутри функции выполняется запрос к базе данных, который создает в таблице Speciality новую запись с данными, которые были получены функцией. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция createClinic принимает в себя параметр request, который содержит в себе следующие данные:

name;

id_speciality;

town;

address;

phone;

description.

Внутри функции выполняется запрос к базе данных, который создает в таблице Clinic новую запись с данными, которые были получены функцией. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция createClinicSpecialist принимает в себя параметр request, который содержит в себе следующие данные:

id_clinic;

id_specialist.

Внутри функции выполняется запрос к базе данных, который создает в таблице clinic_specialist новую запись с данными, которые были получены функцией. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция editClinicSpecialist принимает в себя параметр request, который содержит в себе следующие данные:

id;

id_clinic;

id_specialist.

Внутри функции выполняется запрос к базе данных, который заменяет данные в строке с идентификатором, полученным в функции, в таблице clinic_specialist на данные, которые были получены функцией. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция editSpeciality принимает в себя параметр request, который содержит в себе следующие данные:

id;

name.

Внутри функции выполняется запрос к базе данных, который заменяет данные в строке с идентификатором, полученным в функции, в таблице Speciality на данные, которые были получены функцией. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция editClinic принимает в себя параметр request, который содержит в себе следующие данные:

id;

name;

id_speciality;

town;

address;

phone;

description.

Внутри функции выполняется запрос к базе данных, который заменяет данные в строке с идентификатором, полученным в функции, в таблице clinic на данные, которые были получены функцией. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция deleteClinic принимает в себя параметр request, который содержит в себе идентификатор клиники. Внутри функции выполняется запрос к базе данных, который удаляет строку таблицы clinic идентификатор которой был получен в функции. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция deleteClinicSpecialist принимает в себя параметр request, который содержит в себе идентификатор связи клиники и специалиста. Внутри функции выполняется запрос к базе данных, который удаляет строку таблицы clinic_specialist идентификатор которой был получен в функции. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

Функция deleteSpeciality принимает в себя параметр request, который содержит в себе идентификатор связи специализации. Внутри функции выполняется запрос к базе данных, который удаляет строку таблицы speciality идентификатор которой был получен в функции. Функция помещена в конструкцию try-catch в следствие чего в случае ошибки программа не будет закрыта.

3.4 Результаты работы основных методов

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

Рассмотрим работу сервиса для добавления новой клиники. Вызов данного сервиса происходит при обращении к адресу http://localhost:8000/api/add/clinic. Для добавления клиники в качестве входных параметров передадим данные указанные в табл. 3.3.

Таблица 3.3. Входные параметры для добавления клиники



Описание description В 1991 году на заре становления бизнеса в России, компания «ЮНИТ» открыла первую в Перми частную стоматологическую клинику.

С тех пор наша компания успешно развивается. Сегодня «ЮНИТ» - это 4 клиники: 2 взрослых и 2 детских.

Заполним форму для отправки запроса в программе «Postman» данными, необходимыми для выполнения запроса. Форму с подготовленными данными можно увидеть на рис. 3.4.

Рисунок 3.4 - Подготовка данных для выполнения запроса

После отправки запроса происходит его выполнение. При успешном выполнении запроса сервер возвращает ответ “success” со статусом 200. Ответ на запрос можно увидеть на рис. 3.5.

Рисунок 3.5 - Ответ сервера после выполнения запроса



Рассмотрим работу сервиса для получения данных о всех клиниках. Вызов данного сервиса происходит при обращении к адресу http://localhost:8000/api/getclinic. Для получения данных о всех клиниках не нужно передавать никакие параметры. Заполненную форму для выполения запроса можно увидеть на рис. 3.6.

Рисунок 3.6 - Подготовка данных для отправки запроса на получение данных

После отправки запроса происходит его выполнение. При успешном выполнении запроса сервер возвращает ответ json с данными и статус ответа 200. Результаты выполнения запроса можно увидеть на рис.3.7.

Рисунок 3.7 - Результат выполнения запроса на получение данных

Рассмотрим работу сервиса для редактирования данных о клинике. Вызов данного сервиса происходит при обращении к адресу http://localhost:8000/api/edit/clinic. Для редактирования клиники в качестве входных параметров передадим данные указанные в табл. 3.4.

Таблица 3.4. Входные параметры для редактирования клиники

С тех пор наша компания успешно развивается. Сегодня «ЮНИТ» - это 4 клиники: 2 взрослых и 2 детских.

Заполним форму для отправки запроса в программе Postman данными, необходимыми для выполнения запроса. Форму с подготовленными данными можно увидеть на рис. 3.8.

Рисунок 3.8 - Подготовка данных для выполнения запроса



После отправки запроса происходит его выполнение. При успешном выполнении запроса сервер возвращает ответ “success” со статусом 200. Ответ на запрос можно увидеть на рис.3.9.

Рисунок 3.9 - Ответ сервера после выполнения запроса

Рассмотрим работу сервиса для удаления данных о выбранной клинике. Вызов данного сервиса происходит при обращении к адресу http://localhost:8000/api/delete/clinic/{id}. Для удаления данных о выбранной клинике необходимо передать в качестве параметра ее идентификатор. Заполненную форму для выполнения запроса можно увидеть на рис. 3.10.

Рисунок 3.10 - Подготовка запроса на удаление данных о клинике

После отправки запроса происходит его выполнение. При успешном выполнении запроса сервер возвращает ответ “success” со статусом 200. Ответ на запрос можно увидеть на рис.3.11.



Рисунок 3.11 - Ответ сервера после выполнения запроса



4. Технико-экономическое обоснование разработки информационной системы

4.1 Цели и задачи проекта

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

...