Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное
учреждение высшего образования
«Петрозаводский государственный университет»
Институт математики и информационных технологий
Кафедра информатики и математического обеспечения
_________________
(подпись соискателя)
Панфилова Оксана Сергеевна
Выпускная квалификационная работа на степень бакалавра
Разработка прототипа информационной системы
«Регистр пациента»
Направление 09.03.02 — Информационные системы и технологии
Научный руководитель:
ст. преподаватель М. А. Чарута
_________________
(подпись руководителя)
Петрозаводск — 2018
Содержание
Введение .................................................................................................................. 3
1 Бизнес-процессы предметной области ........................................................... 5
1.1 Исследование предметной области............................................................. 5
1.2 Функциональное моделирование бизнес-процессов................................. 7
2 Требования к прототипу системы ................................................................ 10
2.1 Требования к системе в целом ................................................................... 10
2.2 Функциональные возможности разделов ................................................. 12
3 Проектирование ............................................................................................... 15
3.1 Построение концептуальной модели предметной области .................... 15
3.2 Создание схемы базы данных .................................................................... 17
3.3 Архитектура проекта .................................................................................. 19
4 Реализация прототипа системы .................................................................... 21
4.1 Контроль доступа ...................................................................................... 21
4.2 Реализация функций системы ................................................................... 23
4.3 Реализация интерфейса системы............................................................... 24
4.4 Метрики кода ............................................................................................... 26
Список используемой литературы .................................................................. 30
Приложение А: Часть функциональной модели системы. ......................... 34
Приложение Б: Сущности и их атрибуты. ..................................................... 41
Приложение В: Документация по базе данных............................................. 47
Приложение Г: RBAC-таблицы. ...................................................................... 52
2
Введение
В современной гастроэнтерологии особую остроту имеет проблема неспецифических воспалительных заболеваний (НВЗК). Несвоевременная диагностика и отсутствие единого подхода к лечению среди практикующих врачей
по всему миру приводят к серьезным последствиям для пациентов, например, к
высокой частоте осложнений, и даже в некоторых случаях к летальному исходу
[1].
Одной из задач российской группы по изучению неспецифических воспалительных заболеваний кишечника является создание региональных, а затем
федерального регистра больных [1]. Так в качестве территориальной базы пациентов Республики Карелия для ГБУЗ РК «Республиканская больница им.
В.А. Баранова» специально разработана программа, зарегистрированная в Реестре программ Федеральной службы по интеллектуальной собственности «Роспатент» от 06.07.2015 г. как «Программа для сбора и анализа данных пациентов
с воспалительными заболеваниями кишечника в Республике Карелия».
При эксплуатации программы был выявлен ряд проблем, основными из
которых являются:
1. Децентрализованное хранение информации о состоянии пациентов без возможности ее импорта и экспорта между компьютерами пользователей.
2. Отсутствие возможности добавления новых параметров мониторинга.
3. Невозможность автоматизированного статистического исследования развития воспалительных заболеваний кишечника у пациентов.
4. Поиск записей ведется вручную.
Было принято решение создать новую информационную систему, использование которой решит ранее описанные проблемы, добавит новые функциональные возможности и будет являться единым региональным регистром пациентов с неспецифическими воспалительными заболеваниями кишечника.
Целью работы является разработка прототипа информационной системы
3
«Регистр пациента» для мониторинга состояния пациентов с НВЗК Республики
Карелия.
Для достижения поставленной цели требуется решение следующих задач:
1. Исследование предметной области.
2. Разработка функциональной модели прототипа системы.
3. Разработка требований к прототипу системы.
4. Проектирование базы данных.
4.1 Разработка концептуальной модели предметной области.
4.2 Создание схемы базы данных.
5. Реализация прототипа системы.
5.1 Реализация контроля доступа на основе ролей.
5.2 Разработка интерфейса прототипа системы.
5.3 Реализация части функций прототипа системы.
Существуют похожие разработки в г. Тюмень (программа для ЭВМ: имеется свидетельство о государственной регистрации
—
«Автоматизированная
система «Формирование регистра больных с воспалительными заболеваниями
кишечника») и г. Москва (база данных «Московский областной регистр больных воспалительными заболеваниями кишечника»: свидетельство о государственной регистрации №2012621045 от 21.08.2012 г.). Вышеуказанные регистры
пациентов и разрабатываемый отличаются друг от друга, так как учитывают
методику работы врачей региона, для которого они предназначены. Кроме того,
у проектов разные технологические базы [2] [3].
Данная работа состоит из введения, четырех глав и заключения. Первая
глава посвящена бизнес-процессам предметной области. Во второй главе приводятся требования, предъявляемые к прототипу информационной системы.
Третья глава описывает процесс проектирования, а четвертая — реализации. В
заключении формулируются достигнутые результаты.
4
1 Бизнес-процессы предметной области
1.1 Исследование предметной области
Данная предметная область является частью процесса функционирования
ГБУЗ РК «Республиканская больница им. В. А. Баранова» и представляет собой
мониторинг состояния пациентов с НВЗК Республики Карелия для оценки состояния пациентов и эффекта назначенной терапии, принятия решения о методах лечения пациентов, проведения наблюдения за динамикой состояния пациентов и течением заболевания.
Сбор информации происходит при каждом визите пациента, во время которого фиксируется дата посещения, и отслеживаются следующие параметры
мониторинга: общие сведения о пациенте, симптоматика, параметры диагностики (для распознавания болезни) [4] и лечения.
Общие сведения о пациенте включают в себя фамилию, имя, отчество,
номер телефона, дату рождения, информацию о месте жительства, страховой
номер индивидуального лицевого счета (СНИЛС), вид страховки, наименование учреждения, оказывающее медицинскую помощь пациенту, диагноз и степень инвалидности. История изменения этой информации не отслеживается.
Медицинское страхование осуществляется в двух видах: обязательном
(ОМС) и добровольном (ДМС) [5].
Симптоматические параметры являются совокупностью признаков группы неспецифических воспалительных заболеваний кишечника, включающей в
себя неспецифический язвенный колит и болезнь Крона [6] [7].
Диагностическими параметрами является информация о госпитализации,
частоте вызовов скорой помощи и обращений к врачу, дате последней колоноскопии, результате морфологии, внекишечных симптомах, наличии или отсутствии ремиссии, применении определенного вида хирургического лечения.
Параметрами лечения являются препараты различных групп, их суточная
5
доза, также для некоторых препаратов определяется тип применения, например,
системного действия.
Любая группа параметров мониторинга может измениться в будущем.
Это зависит от методики, выбранной врачами для мониторинга.
На этапе анализа собранной информации врач изучает визиты пациентов
за определенный период, на основании которых делает заключение о состоянии
здоровья пациентов, оценку эффекта назначенной терапии и др.
Источниками информации о пациентах служат документы, указанные в
пункте 2.1.6 приказа № 191 от 01.06.2011 главного врача ГБУЗ «Республиканская больница им. В.А. Баранова» [8].
Пациенты при обращении в стационар республиканской больницы подписывают согласие на обработку персональных данных. Это юридический документ, который является частью истории болезни при поступлении в стационар (одна из страниц) или медицинской карточки, заведенной на больного.
Оказание медицинской помощи пациентам регулируется действующим
законодательством Российской Федерации, постановлениями Правительства
Российской Федерации, приказами федеральных и региональных органов исполнительной власти в сфере здравоохранения и другими документами [9].
6
1.2 Функциональное моделирование бизнес-процессов
Для построения функциональной модели бизнес-процессов была выбрана
методология моделирования, основанная на графическом представлении системы, IDEF0 [10]. При разработке модели использовался документ «Методология
функционального моделирования IDEF0. Руководящий документ», который не
был утвержден в Российской Федерации как стандарт, но приобретает все
большую популярность [11].
Рассмотрим построение функционального блока A-0 контекстной диаграммы «Мониторинг состояния пациентов с НВЗК Республики Карелия», изображенной на рисунке 1.
Рис. 1: Контекстная диаграмма
Для выполнения этой функции требуется информация от пациента, например, фамилия, имя, отчество, состояние здоровья. Поэтому входящая граничная стрелка называется «информация от пациента», так как эти сведения
включают в себя информацию не только о самом пациенте, но и о его визите.
7
Вторая стрелка объединяет в себе совокупность критериев мониторинга и их
свойства. К примеру, это препараты и их характеристики. Третья стрелка называется «Информация от пользователей программных средств», которая представляет собой не только информацию от врачей, использующих информационную систему для мониторинга, но и от других сотрудников.
Выходами являются перечисленные в первой главе цели мониторинга,
отчеты и обновленная информация в базе данных.
Механизмами являются истории болезней, персонал и др.
Управляющими стрелками являются выбранная методика мониторинга,
законодательство, документы и распоряжения, регламентирующие деятельность по мониторингу, например, приказ главного врача № 191 от 01.06.2011 г.
и т. д. Назовем все эти документы как «регламентирующие документы».
Стоит отметить, что названия некоторых стрелок приведены в обобщенной форме, чтобы не нагружать модель и не «привязывать» функции к организационной структуре больницы во избежание рассмотрения модели с субъективной точки зрения [10]. Например, стрелка механизма «персонал» объединяет
в себя различных сотрудников, имеющих отношение к осуществлению деятельности по мониторингу пациентов (врачи, сотрудники отдела информатизации и телемедицины и т.д.).
Всего было построено двадцать восемь диаграмм. Функции некоторых
бизнес-процессов не включены в модель из-за малой значимости для целей моделирования. В приложении А приведена функциональная модель реализованных функций и схема уровня A0, отображающая основные бизнес-процессы.
Перечень всех узлов представлен на рисунке 2.
8
Рис. 2: Иерархия функциональной модели системы
9
2 Требования к прототипу системы
В процессе работы над проектом отдельные пункты требований изменялись и уточнялись по согласованию между разработчиком и заказчиком. Ограничения, накладываемые на входные данные, учтены при проектировании базы
данных и не описаны далее.
В данной главе приводится утвержденный заказчиком список требований, необходимый для дальнейшего описания реализованных функций со
ссылками на диаграммы IDEF0.
2.1 Требования к системе в целом
Система должна быть разработана с помощью веб-технологий и работать
по изолированной локальной сети организации заказчика.
Доступ к системе должен осуществляться:
1. с использованием пароля и уникального логина, которые предоставляет системный администратор;
2. посредством веб-интерфейса с помощью SSL (TLS) сертификатов и протокола HTTPS.
Пользователей системы разделяются на три группы в соответствии с правами доступа:
1. Врач. Имеет доступ к следующим функциям: работать с записью о визите
(A1 и диаграммы вложенных уровней), работать с записями о визитах пациентов (A2 и диаграммы вложенных уровней).
2. Врач с расширенными правами. Имеет доступ к следующим функциям: работать с записью о визите (A1 и диаграммы вложенных уровней), работать с
записями о визитах пациентов данных (A2 и диаграммы вложенных уровней), работать со справочниками базы (A31 и диаграммы вложенных уровней).
10
3. Системный администратор. Имеет доступ к функциям администрирования
информационной системы для мониторинга (A3 и диаграммы вложенных
уровней).
Система должна состоять из следующих разделов:
1. Вход в систему.
2. Главное меню.
3. Создать запись о визите.
4. Поиск и просмотр записей.
5. Пользователи.
6. Препараты.
7. Поликлиники.
8. Места жительства.
9. Профиль пользователя.
Все данные системы должны храниться в структурированном виде под
управлением реляционной cистемы управления базами данных MySQL версии
5.6.39-log – MySQL Community Server (GPL). Исключения составляют изображения. Такие файлы хранятся в файловой системе на сервере.
Для реализации серверной части должен использоваться язык PHP версии
5.5.38. Язык взаимодействия пользователя с системой: русский.
Программное обеспечение клиентской части должно удовлетворять следующим требованиям:
1. Браузер, поддерживающий HTML 5.0.
2. Включена поддержка Javascript, cookies.
3. Операционная система: Windows версии 8.1 и выше.
По согласованию между заказчиком и разработчиком интерфейс может
меняться. На странице «Вход в систему», «Главное меню» должно присутствовать изображение с логотипом организации заказчика.
11
2.2 Функциональные возможности разделов
В перечисленных ниже разделах должны быть реализованы указанные
функции.
«Пользователи» (A32, A33 и вложенные в них уровни):
1. Добавление пользователя с назначением прав доступа.
2. Редактирование пароля и/ или роли пользователя.
3. Просмотр списка пользователей (по пять записей на странице или весь список).
4. Удаление пользователя.
5. Фильтрация списка пользователей по имени.
6. Сброс фильтров.
7. Сортировка списка пользователей по имени в алфавитном порядке:
по возрастанию (от «А до Я») или убыванию (от «Я до А»).
В списке пользователей должны отображаться все пользователи, за исключением текущего. Удалять можно любого пользователя, за исключением текущего.
«Поликлиники» (A311 и вложенные в него уровни):
1. Добавление учреждения.
2. Редактирование учреждения.
3. Просмотр списка поликлиник (по пять записей на странице или весь список).
4. Удаление поликлиники.
5. Фильтрация списка поликлиник по названию, группе или названию и группе.
6. Сброс фильтров.
7. Сортировка списка поликлиник по наименованию в алфавитном порядке: по
возрастанию (от «А до Я») или убыванию (от «Я до А»).
«Препараты» (A312 и вложенные в него уровни):
1. Добавление препарата.
2. Редактирование препарата.
3. Просмотр списка препаратов (по пять записей на странице или весь список).
4. Удаление препарата.
12
5. Фильтрация списка препаратов по названию, группе или названию и группе.
6. Сброс фильтров.
7. Сортировка списка препаратов по наименованию или группе в алфавитном в порядке: по возрастанию (от А до Я) или убыванию (от Я до А).
«Места жительства» (A313 и вложенные в него уровни):
1. Добавление населенного пункта.
2. Просмотр списка мест жительства (по пять записей на странице или весь
список).
3. Просмотр списка мест жительства.
4. Удаление населенного пункта.
5. Фильтрация списка мест жительства по названию, группе или названию и
группе.
6. Сброс фильтров.
7. Сортировка
списка мест жительства
по наименованию в алфавит-
ном порядке: по возрастанию (от А до Я) или убыванию (от Я до А).
В разделе «Вход в систему» осуществляется функция авторизации пользователя по паролю и уникальному логину, отслеживается включение и отключение клавиши Caps Lock с уведомлением об этом событии. В случае успешной
авторизации пользователю открывается доступ к функциям других разделов в
зависимости от прав доступа, выполняется переход на страницу «Главное меню». Иначе, необходимо повторить вышеописанную процедуру.
«Главное меню» — это страница с основным меню системы, которая
должна содержать кнопки, при нажатии на которые осуществляется переход в
другие разделы системы в соответствии с правами доступа.
В разделе «Главное меню» необходимо поместить ссылку на текст документа «Руководство пользователя».
Для всех авторизованных пользователей системы должна быть доступна
функция просмотра руководства пользователя на странице «Главное меню».
Чтобы открыть файл для просмотра, необходимо нажать на ссылку «Руководство пользователя». После чего документ должен открыться в браузере или
13
сохраниться на компьютер в зависимости от настроек браузера.
Документ «Руководство пользователя» должен быть представлен в неполном виде в формате pdf: разделы для включения утверждаются заказчиком
после его разработки. Полный текст документа должен храниться на сервере.
Из всех разделов, за исключением «Вход в систему», можно попасть в
«Главное меню» по ссылке с надписью «Главное меню», а также необходимо
реализовать функцию выхода из системы, при выполнении которой закрывается доступ ко всем разделам и открывается во «Вход в систему».
В разделе «Профиль пользователя» авторизованным пользователям
должна быть доступна функция смены пароля. Доступ к профилю необходимо
осуществлять через «Главное меню».
14
3 Проектирование
3.1 Построение концептуальной модели предметной области
Первым шагом в проектировании базы данных является построение концептуальной модели предметной области [12]. В данной работе для ее описания
использовалась модель «сущность-связь» (ER-модель), визуализация которой
выполнена с помощью нотации Баркера.
На основании проведенного исследования, описанного в главе 1, и анализа результатов интервьюирования представителей заказчика выделены сущности и их атрибуты. Результат работы представлен в приложении Б.
Построенная модель изображена на рисунке 3.
Стоит отметить, что модель, скорее всего, содержит не все атрибуты
сущностей по причине отсутствия на текущий момент основного сотрудника
заказчика, утверждающего методику мониторинга. К тому же некоторые из
сущностей с одним атрибутом были выделены с учетом перспективы увеличения у них количества атрибутов. Например, сущность «госпитализация», возможно, будет иметь свойство «тип» (плановая, внеплановая). Пока такие характеристики не были учтены.
15
Рис. 3: ER-модель в нотации Баркера
16
3.2 Создание схемы базы данных
Для ER-модели существует метод ее преобразования в реляционную модель данных [12]. С его помощью создана схема базы данных. Далее выполнена
денормализация данных и у всех таблиц, полученных в результате преобразования сущностей и связей, введены искусственные идентификаторы для увеличения скорости обработки запросов к базе данных [12]. Также была обеспечена
целостность базы данных.
Особого внимания требует описание преобразования отношения между
сущностями «визит» и «диагностика», «лечение», «симптоматика». Рассмотрим
их преобразование в реляционную модель подробнее. Отношения между сущностями «Визит» и «Симптоматика», «Визит» и «Диагностика», «Визит» и
«Лечение» имеют кардинальность «один к одному». Значит, при построении
таблиц для этих связей в качестве их идентификаторов можно выбрать первичный ключ любой из двух сущностей [12]. Во всех случаях выберем идентификатор таблицы tblvisit, являющейся преобразованной к реляционной форме
сущностью «визит». Тогда tblvisit и полученные таблицы будут иметь один и
тот же первичный ключ. Выполним оптимизацию, объединив четыре таблицы в
одну (tblvisit). Таким образом, были получены три внешних ключа в таблице
tblvisit. Таблицы tblsymptomatic, tblcuringdisease и tblvisitdiagnostics не были
объединены с tblvisit, так как это может сильно повлиять на скорость обработки
запросов в будущем.
Полученная реляционная модель изображена на рисунке 4, документация
к базе данных приведена в приложении В. Всего было создано двадцать пять
таблиц и двадцать три связи.
17
Рис. 4: Реляционная модель базы данных
18
3.3 Архитектура проекта
Для реализации прототипа системы был выбран фреймворк Yii (базовая
версия шаблона приложения 2.0.13-dev), так как он сокращает время разработки, затрачиваемое на решение однообразных задач [13][14]. Одним из преимуществ Yii является то, что он основан на архитектурном шаблоне проектирования MVC. Такой подход обеспечивает разделение данных, интерфейса пользователя и логики приложения на три отдельных компонента, называемых модель, представление и контролер [15].
Для удобства разработки заказчиком был выделен тестовый виртуальный
сервер Apache, функционирующий в сети Интернет. При переносе кода на нем
были изменены не только настройки приложения, но и его структура. Одной из
причин этому послужила доступность из веб-обозревателя всех файлов, размещаемых на сервере. Дело в том, что структура шаблона приложения включает
файлы и каталоги, которые рекомендуется сделать недоступными из вебобозревателя, чтобы защитить приложение от несанкционированного доступа.
Это достигается за счѐт структуры проекта и установки определѐнных прав для
всех файлов и каталогов. Важно, чтобы каталог web был корневой общедоступной директорией сервера [16].
Чтобы обеспечить безопасность и функционирование системы на виртуальном сервере, были приняты следующие меры:
1. Все файлы фреймворка размещены в папке public_html виртуального сервера.
2. Затем папка web переименована в папку public_html (такие имена имеют все
общедоступные папки на сервере).
3. Остальные папки перенесены в созданную папку system c правами rwxr-xr-x.
4. Изменен входной скрипт приложения (index.php).
5. В папку system добавлен файл .htaccess с командой «deny from all», скры-
19
вающий папку system из веб-обозревателя [17].
6. В папке public_html (ранее web) добавлены новые параметры сервера с помощью файла дополнительной конфигурации (htaccess), рекомендованного в
документации фреймворка по настройке работы приложения в среде общего
хостинга для веб-сервера Apache [18].
7. Выполнен переход с HTTP на HTTPS протокол. В связи с этим внесены изменения в файл htaccess папки public_html (общедоступная папка виртуального сервера).
В остальном структура приложения соответствует шаблону Yii 2.0 Basic.
Основные изменения касались папок models, views и controllers, хранящих в себе модели, виды и контроллеры системы соответственно [19]. Согласно
принятым в Yii правилам именования контроллеров и папок, хранящих внутри
себя преставления, были сделаны следующие соглашения по разделению функций между контроллерами в соответствии с названиями разделов системы:
1. Вход в систему и Главное меню: Login.
2. Создать запись о визите: AddVisit.
3. Поиск и просмотр записей: Visits.
4. Пользователи: Users.
5. Препараты: Medicaments.
6. Поликлиники: Polyclinics.
7. Места жительства: PlaceLiving.
8. Профиль пользователя: Profile.
Модели именуются как и таблицы базы данных, но без префикса «tbl».
Так, например, контроллер с именем ProfileController.php будет взаимодействовать с файлами представлений в папке views/profile и необходимой моделью, в
данном случае с Users.php.
20
4 Реализация прототипа системы
4.1 Контроль доступа
Проверка наличия прав пользователя на выполнение некоторых действий
осуществляется с помощью контроля доступа на основе ролей (RBAC) [20].
Роль — это некоторое множество разрешений (permissions). Например, роль
системного администратора, одним из разрешений для которого может являться право на добавление нового пользователя. Доступ пользователя к определенному методу определяется результатом проверки того, назначена ли ему роль, содержащая необходимые разрешения для доступа к данному методу или нет.
Другими словами, выполняется проверка правила (rule). Если она пройдена, то
пользователю предоставляется доступ к данному методу.
После выполнения настройки RBAC, основанного на хранении информации о привилегиях пользователей в базе данных, автоматически были сгенерированы необходимые таблицы для хранения ролей и разрешений (приложение
Г). Также создан контроллер (RbacController.php) для инициализации ролей и
разрешений. В системе доступны следующие разрешения:
1. Разрешение acsessToMainMenu на получение прав доступа к функциям раз-
делов «Создать запись о визите», «Поиск и просмотр записей», «создать отчѐт», «Посмотреть статистику».
2. Разрешение editDatabaseDirectories на получение прав доступа к функциям
разделов «Препараты», «Места жительства», «Поликлиники».
3. Разрешение acsessToUsersDatabase на получение прав доступа к функциям
раздела «Пользователи».
Пример фрагмента кода, инициализацирующего разрешения, приведѐн
ниже:
// инициализируем компонент authManager, обеспечивающий
21
// функциональность RBAC
$am = Yii::$app->authManager;
// удаляем старые данные RBAC из базы данных
$am->removeAll();
// добавляем разрешение acsessToUsersDatabase
$acsessToUsersDatabase = $auth->createPermission('acsessToUsersDatabase');
$acsessToUsersDatabase->description = 'Доступ к разделу Пользователи';
$ am ->add($acsessToUsersDatabase);
Файл RbacControler.php создает следующие роли:
1. Врач: doctor.
2. Врач c расширенными правами: doctor_admin.
3. Системный администратор: sa.
В качестве примера ниже приведен фрагмент кода, создающий роль «sa» и назначающий ей разрешения editDatabaseDirectories и acsessToUsersDatabase:
// добавляем роль sa (системный администратор) и
$sa = $am->createRole('sa');
// создаем описание роли
$sa->description = 'Системный администратор';
$am->add($sa);
// даем этой роли разрешения editDatabaseDirectories, acsessToUsersDatabase
$am->addChild($sa, $editDatabaseDirectories);
$am->addChild($sa, $acsessToUsersDatabase);
22
4.2 Реализация функций системы
Все созданные модели расширяют возможности класса ActiveRecord, который обеспечивает объектно-ориентированный интерфейс для доступа и
управления данными, хранящимися в базе данных [21]. Класс позволяет не писать в коде SQL-выражения, а использовать его методы.
C целью обеспечения повышенной безопасности паролей пользователей
используется алгоритм шифрования, устойчивый к атаке перебором, bcrypt [22].
Создание паролей и их проверка при аутентификации пользователей осуществляется с помощью вспомогательных функций Yii, которые упрощают использование PHP-функции crypt: generatePasswordHash() и validatePassword() [23]. Таким образом, в базе данных пароли не хранятся в открытом виде, а представляет собой хеши. Использование функции bcrypt ресурсоемкий процесс, но для
разрабатываемой системы такое решение подойдет, так как планируемая нагрузка будет составлять не более десяти человек, работающих одновременно с
системой. Кроме того, при реализации функций системы, учтены рекомендации
из документации к фреймворку Yii по разработке безопасных приложений [16],
такие, как фильтрация ввода, экранирование вывода, предотвращение SQLиньекций, CSRF-атак и другие.
Согласно требованиям заказчика необходимо было реализовать лишь
функции некоторых разделов, поэтому для остальных в соответствующих контроллерах созданы «методы-заглушки», позволяющие при переходе из главного
меню в выбранный раздел отобразить HTML-страницы, которые в дальнейшем
будут соответствовать основной странице выбранного раздела. Для таблиц, не
используемых на данный момент в системе, сгенерированы модели, представляющие из себя класс ActiveRecord.
23
4.3 Реализация интерфейса системы
При реализации интерфейса системы использовались виджеты — элементы для создания некоторой сложной части пользовательского интерфейса,
представляющей из себя самостоятельную единицу [24]. В системе применялись следующие из них:
1. ActiveForm, создающий интерактивную HTML-форму для одной и более моделей данных [25].
2. Pjax, интегрирующий JavaScript-плагин pjax jQuery. Его преимуществом является возможность обновлять содержимое страниц без полной перезагрузки
макета или ресурсов (js, css) [26].
3. Breadcrumbs, предназначенный для реализации навигации [27].
4. GridView, отображающий информацию справочников системы в виде таблицы. Кроме того, этот виджет связывается с моделью поиска для реализации
функций фильтрации и сортировки [28].
Также использовалось расширение bootstrap, объединяющее в себе такие
технологии, как Twitter Bootstrap, HTML, CSS и JavaScript. Например, виджет
Alert отображает различные предупреждения пользователю [29].
Для реализации таких возможностей, как скрытие различных уведомлений пользователя через определенное время после полной загрузки страницы,
отслеживание события включения и отключения клавиши Caps Lоck на странице «Вход в систему» и многих других используется кросплатформенная библиотека для взаимодействия JavaScript и HTML, JQuery. Yii-приложение автоматически подключает еѐ, так как многие компоненты во фреймворке работают
на основе этой библиотеки.
При верстке страниц для разделов «Препараты», «Места жительства»,
«Пользователи», «Поликлиники», «Профиль пользователя» был создан общий
файл представления шаблона, что позволяет не включать повторно однообразный код в файлы представлений [30]. Также для них был создан свой комплект
ресурсов, расширяющий возможности класса AssetBundle [31]. Для разделов
24
«Главное меню» и «Вход в систему» реализованы собственные наборы ресурсов. По требованию заказчика клиентами системы являются только компьютеры, поэтому верстка выполнялась лишь для различных расширений экрана такого типа устройств.
На рисунках 5-7 приведены несколько снимков экрана программы.
Рис. 5: Главное меню системы для пользователя с ролью «врач с расширенными
правами»
Рис. 6: Раздел «Препараты» с использованием виджета GridView
25
Рис. 7: Страница «Добавить место жительства»
В качестве пользовательской документации по требованию заказчика
разработан документ «Руководство пользователя», содержащий в себе разделы
согласно п.3.4 РД 50-34.698-90 [32]. Ссылка на документ в системе оформлена
согласно требованиям. По решению заказчика пользователям на текущий момент доступен раздел «Описание операций». Полный текст документа размещен в папке system на тестовом сервере.
4.4 Метрики кода
Приведенные в таблице 1 метрики кода отражают краткое описание частей проекта, а также показывают, с использованием каких технологий они были
реализованы. Данные показатели можно было бы оптимизировать в плане компактности кода, например, сжать HTML-код. Но на данный момент это не сделано, чтобы код был легко читабельным, так как разработка будет продолжаться. Самой трудоемкой оказалась реализация моделей, контроллеров и представлений. На языке программирования PHP написано пятьдесят шесть процентов
от всего кода. Конфигурационная часть составляет небольшое количество строк
кода, так как по большом счету она не изменялась.
26
Описание файлов (папка)
Классы контроллеров (control-
Строк кода (комментариев из них)
PHP
HTML
JQuery
CSS
1048 (147)
-
-
-
1191 (240)
-
-
-
550
1591
-
-
lers)
Классы моделей (models)
Файлы представлений (views)
(148)
Файлы для определения под-
120 (15)
-
-
-
СSS-файлы (css)
-
-
-
569 (29)
JS-файлы (js)
-
-
154
-
ключаемых комплектов ресурсов
(assets)
Запись входного скрипта и вебресурсов (public_html)
(21)
Конфигурационные файлы (con-
20
-
-
-
2929 (402)
1591
154
569 (29)
(148)
(21)
≈ 30 %
≈3%
fig)
Итого
Процент от общего числа строк
≈ 56 %
кода
Таблица 1: Метрики кода
27
≈ 11 %
Заключение
В ходе выполнения выпускной квалификационной работы была достигнута поставленная цель — разработать прототип информационной системы
«Регистр пациента» для мониторинга состояния пациентов с неспецифическими воспалительными заболеваниями кишечника Республики Карелия. Ниже перечислены итоговые результаты работы:
1. На основании изученной предметной области составлено краткое описание
методики мониторинга состояния пациентов с неспецифическими воспалительными заболеваниями кишечника врачей ГБУЗ РК «Республиканская
больница им. В.А. Баранова».
2. Сформирован список нефункциональных и функциональных требований к
прототипу системы, а также проектных ограничений.
3. Разработана функциональная модель в нотации IDEF0.
4. Построена концептуальная модель предметной области с помощью ERмодели в нотации Баркера, к которой составлено описание сущностей и их
атрибутов
5. Создана схема реляционной базы данных для системы управления базами
данных MySQL.
6. Выполнена оптимизация базы данных для ускорения выполнения запросов.
7. Организован контроль доступа к системе на основе ролей, что позволяет повысить безопасность системы.
8. Реализована требуемая функциональная часть с помощью PHP-фреймворка
Yii.
9. Создан интерфейс для реализованных разделов прототипа системы.
10. Составлен документ «Руководство пользователя» по п.3.4 РД 50-34.698-90 в
соответствии с требованиями заыказчика.
На текущий момент разработанный прототип системы устраняет многие
из недостатков предыдущей программы, используемой для мониторинга пациентов. Важным преимуществом является то, что прототип повышает уровень
28
информационной безопасности за счет назначения определенных прав пользователям, чего не было в другой программе. Архитектура проекта позволяет организовывать обмен информацией между компьютерами врачей, что позволит в
дальнейшем создавать отчеты и просматривать различную статистическую информацию. К тому же добавлены новые функциональные возможности: администрирование системы, добавление новых параметров мониторинга.
В процессе выполнения проекта получены навыки работы с заказчиком,
проектирования и разработки веб-приложений. Кроме того, изучено множество
технической документации, в том числе руководящих документов и дополнительной литературы по тематике проекта.
В будущем планируется расширить возможности системы путем реализации новых функций и подготовки необходимой технической документации.
29
Список используемой литературы
[1] Воробьев, Г. И. Неспецифические воспалительные заболевания кишечника /
Г. И. Воробьев, И. Л. Халиф. – М.: Миклош, 2008. — 400 c.
[2] Ростовщикова, К. А. Опыт ведения регистра пациентов с воспалительными
заболеваниями кишечника в г. Тюмень и тюменской области / К. А. Ростовщикова. и др. // Медицинская наука и образование Урала. — 2011. — 3-2— С. 115116.
[3] Бакулин, И. Г. К вопросу о распространенности и заболеваемости воспалительными заболеваниями кишечника в Москве/ И. Г. Бакулин. и др. // Фарматека. — 2016. — № 2. — С. 69-73.
[4] Тарантул, В. З. Толковый биотехнологический словарь (русско-английс-кий)
/ В. З. Тарантул. – Москва: Языки славянской культуры, 2009. – 936 c.
[5] Медицинское страхование и его виды [Электронный ресурс]. Министерство
здравоохранения
Архангельской
области
©.
Режим
доступа:
https://www.minzdrav29.ru/health/health_insurance/, свободный. — Заглавие с экрана. — (Дата обращения: 10.05.2018).
[6] Симптоматика [Электронный ресурс]. Академик © 2000–2016. — Режим
доступа: http://dic.academic.ru/dic.nsf/medic2/43115, свободный. — Заглавие с
экрана. — (Дата обращения: 10.05.2018).
[7] Воробьев, Г. И. Воспалительные заболевания кишечника / Г. И. Воробьев,
И. Л. Халиф. — Москва: Миклош, 2008. — 422 c.
[8] Порядок оказания специализированной амбулаторной медицинской помощи
в государственном бюджетном учреждении здравоохранения «Республиканская
больница им. В.А.Баранова» [Электронный ресурс]. Республиканская больница
им. В. А. Баранова © 2015. — Режим доступа: http://hospital.karelia.ru/dejatelnost/konsul-tativnaja-poliklinika-pr-lesnoj-40/informacija-dlja-vrachej/porjadokokazanija-specializirovannoj-ambulatornoj-medicinskoj-pomocshi-v-gosudarstvenn
om-bjudzhetnom-uchrezhdenii-zdravoohranenija-respublikanskaja-bol-nica-im-v-abaranova, свободный. —Заглавие с экрана. — (Дата обращения: 09.05.18)
30
[9] Официальный сайт ГБУЗ РК «Республиканская больница им. В. А. Баранова», Организация медицинской помощи [Электронный ресурс]. Республиканская
больница
им.
В.
А.
Баранова
©
2015.
—
Режим
доступа:
http://hospital.karelia.ru/o-bol-nice/organizacija-medicinskoj-pomocshi/, свободный.
— Заглавие с экрана. — (Дата обращения: 09.05.2018).
[10] Руководящий документ IDEF0 — 2000. Методология функционального
моделирования IDEF0. – Москва: ГОССТАНДАРТ РОССИИ, 2000. — 75 с.
[11] Орлова, Ю. А. Современные концепции управления предприятием / Ю. А.
Орлова, Ю. А. Зубарев. — Волгоград: ФГОУВПО «ВГАФК», 2010. — 370 c.
[12] Щеголева, Л. В. Проектирование информационной системы: структурный
подход/ Л. В. Щеголева, А. Н. Кириленко. — Петрозаводск: Петрозаводский
государственный университет, 2013. — 104 c.
[13] Полное руководство по Yii 2.0, Что такое Yii [Электронный ресурс]. Yii ©
2008—2018. — Режим доступа: https://www.yiiframework.com/doc/guide/2.0/ru/
intro-yii, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[14] Yii 2 Basic Project Template [Электронный ресурс]. GitHub Inc © 2018, —
Режим доступа: https://github.com/yiisoft/yii2-app-basic, свободный. — Заглавие
с экрана. — (Дата обращения: 26.05.2018).
[15] Полное руководство по Yii 2.0, Обзор [Электронный ресурс]. Yii © 2008 –
2018. — Режим доступа: https://www.yiiframework.com/doc/guide/2.0/ru/intro-yii,
свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[16] Полное руководство Yii 2.0 на русском, Лучшие практики безопасности
[Электронный
ресурс].
Yii
©
2008–2018.
—
Режим
доступа:
https://p0vidl0.info/yii2-api-guides/guide-ru-security-best-practices.html,
свобод-
ный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[17] .htaccess в примерах [Электронный ресурс]. PHP.SU © 2006–2018. —Режим
доступа: http://www.php.su/articles/?cat=apache&page=011, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[18] Apache HTTP Server Tutorial: .htaccess files [Электронный ресурс]. The
Apache
Software
Foundation
©
31
2018.
—
Режим
доступа:
http://httpd.apache.org/docs/trunk/howto/htaccess.html, свободный. — Заглавие с
экрана. — (Дата обращения: 26.05.2018).
[19] Назначение папок и файлов в Yii2 [Электронный ресурс]. Liblessons ©
2018.
—
Режим
доступа:
https://liblessons.ru/programming/framework-
yii2/naznachenie-papok-faylov-yii2/, свободный. — Заглавие с экрана. — (Дата
обращения: 26.05.2018).
[20] Полное руководство (v2), Первое знакомство, Запуск приложения [Электронный ресурс]. Borales © 2012–2018, Yii Software LLC © 2008–2018. — Режим доступа: https://yiiframework.com.ua/ru/doc/guide/2/start-workflow/, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[21] Полное руководство по Yii 2.0, Active Record [Электронный ресурс].
Yii © 2008–2018 — Режим доступа: https://www.yiiframework.com/doc/
guide/2.0/ru/db-active-record, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[22] Yiiframework, The Definitive Guide to Yii 2.0, Authorization [Электронный
ресурс]. Yii © 2008–2018. — Режим доступа: https://www.yiiframework.com/doc/
guide/2.0/en/security-authorization, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[23] API Documentation for Yii 2.0, Class yii\base\Security [Электронный ресурс].
Yii © 2008–2018. — Режим доступа: https://www.yiiframework.com/doc/api/2.0/
yii-base-security, свободный. – Заглавие с экрана. – (Дата обращения:
26.05.2018).
[24] Полное руководство (v2), Структура приложения, Виджеты [Электронный
ресурс]. Borales © 2012–2018, Yii Software LLC © 2008—2018 — Режим доступа: https://yiiframework.com.ua/ru/doc/guide/2/structure-widgets/, свободный. —
Заглавие с экрана. — (Дата обращения: 26.05.2018).
[25] API Documentation for Yii 2.0, Class yii\widgets\ActiveForm [Электронный
ресурс].
Yii
©
2008–2018.
—
Режим
доступа:
https://www.yiiframework.com/doc/api/2.0/yii-widgets-activeform, свободный. —
Заглавие с экрана. — (Дата обращения: 26.05.2018).
32
[26] API Documentation for Yii 2.0, Class yii\widgets\Pjax [Электронный ресурс].
Yii © 2008–2018. — Режим доступа: https://www.yiiframework.com/doc/api/2.0/
yii-widgets-pjax, свободный. — Заглавие с экрана. — (Дата обращения:
26.05.2018).
[27] API Documentation for Yii 2.0, Class yii\widgets\Breadcrumbs [Электронный
ресурс]. Yii © 2008–2018. — Режим доступа: https://www.yiiframework.com/doc/
api/2.0/yii-widgets-breadcrumbs, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[28] API Documentation for Yii 2.0, Class yii\grid\GridView [Электронный ресурс]. — Режим доступа: https://www.yiiframework.com/doc/api/2.0/yii-gridgridview, свободный. — Заглавие с экрана. — (Дата обращения: 26.05.2018).
[29]
Yiiframework,
yii\bootstrap\Alert
yiisoft/yii2-bootstrap,
[Электронный
API
ресурс].
Documentation
—
Режим
Class
доступа:
https://www.yiiframework.com/extension/yiisoft/yii2-bootstrap/doc/api/2.0/yiibootstrap-alert, свободный. — Заглавие с экрана. — (Дата обращения:
26.05.2018).
[30] Yiiframework, The Definitive Guide to Yii 2.0, Assets [Электронный ресурс].
Yii © 2008–2018. — Режим доступа: https://www.yiiframework.com/doc/guide/
2.0/en/structure-assets, свободный. – Заглавие с экрана. — (Дата обращения:
26.05.2018).
[31] Yiiframework, API Documentation for Yii 2.0 Class yii\web\AssetBundle
[Электронный
ресурс].
Yii
©
2008–2018.
—
Режим
доступа:
https://www.yiiframework.com/doc/api/2.0/yii-web-assetbundle, свободный. – Заглавие с экрана. — (Дата обращения: 26.05.2018).
[32] РД 50-34.698-90 Автоматизированные системы. Требования к содержанию
документов. — Москва: ИПК Изд-во стандартов, 2002.
33
Приложение A: Часть функциональной модели
системы.
Рис. А.1:Диаграмма A0
Рис. А.2:Диаграмма A3
34
Рис. А.3:Диаграмма A31
Рис. А.4:Диаграмма A311
35
Рис. А.5:Диаграмма A3111
Рис. А.6:Диаграмма A3112
36
Рис. А.7:Диаграмма A312
Рис. А.8:Диаграмма A3121
37
Рис. А.9:Диаграмма A3122
Рис. А.10:Диаграмма A313
38
Рис. А.11:Диаграмма A3131
Рис. А.12:Диаграмма A3132
39
Рис. А.13:Диаграмма A32
Рис. А.14:Диаграмма A33
40
Приложение Б: Сущности и их атрибуты
41
Продолжение таблицы Б.1
42
Продолжение таблицы Б.1
43
Продолжение таблицы Б.1
44
Продолжение таблицы Б.1
45
Продолжение таблицы Б.1
Таблица Б.1: Сущности и их атрибуты
46
Приложение В: Документация по базе данных
Таблица В.1: tblabdominalpain (внекишечный симптом)
Таблица В.2: tblcallambulance (вызов скорой помощи)
Таблица В.3: tblcrohndisease (болезнь Крона)
Таблица В.4: tbldiagnos (диагноз)
Таблица В.5: tblcuringdisease (лечение)
Таблица В.6: tblinsuranse (страхование)
47
Таблица В.7: tbldiagnostics (диагностика)
Таблица В.8: tbldiarrhea (диарея)
Таблица В.9: tbldisability (инвалидность)
Таблица В.10: tblextraintestinalsympt (внекишечный симптом)
Таблица В.11: tblhospitalization (госпитализация)
48
Таблица В.12: tblmedicament (препарат)
Таблица В.13: tblpatient (пациент)
Таблица В.14: tblplaceofliv (место жительства)
49
Таблица В.15: tblpolyclinic (поликлиника)
Таблица В.16: tblpresensesympt (обнаруженный внекишечный симптом)
Таблица В.17: tblrectalbleeding (ректальное кровотечение)
Таблица В.18: tblsurgicaltherapy (хирургическое лечение)
Таблица В.19: tblsymptomatic (симптоматика)
50
Таблица В.20: tbltemp (температура)
Таблица В.21: tbltenesmus (тенезмы)
Таблица В.22: tbltriptodoctor (обращение к врачу)
Таблица В.23: tblulcerativecolitis (НЯК)
Таблица В.24: tbluser (пользователь)
Таблица В.25: tblvisit (визит)
51
Приложение Г: RBAC-таблицы
1. Таблица auth_item содержит роли/разрешения и их описание.
2. Таблица auth_item_child содержит наследования ролей и разрешений друг
от друга.
3. Таблица auth_assignment хранит данные о назначении пользователям ролей и разрешений.
4. Таблица auth_rule хранит индивидуальные правила.
Рис. Г.1: RBAC-таблицы
52
Отзывы:
Авторизуйтесь, чтобы оставить отзыв