V003477 Отчет о преддипломной практике Создание компонента проведения опросов в режиме on-line системы мониторинга эпидемиологии заболеваний

1 Введение

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

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

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

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

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

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

В настоящее время практика учета случаев заболеваний, выявленных и зарегистрированных учреждениями различной формы собственности по стране неоднородна. В отдельных субъектах Российской Федерации упорядочено представление в единый центр информации от всех медицинских учреждений, расположенных на его территории (независимо от ведомственной принадлежности), и эти данные обобщаются в итоговых статистических документах о состоянии здоровья населения [1]. Некоторые территории добились представления информации о зарегистрированных случаях патологических состояний от ведомственных структур, но правомерно не включают ее в общие по территории отчеты и просто архивируют, так как совершенно очевидно, что предварительно необходимо исключить дублирование информации.

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

Целью преддипломной практики является создание компонента проведения опросов в режиме on-line системы мониторинга эпидемиологии заболеваний, позволяющего проводить эпидемиологические исследования хронических неинфекционных заболеваний по следующим нозологиям, а именно: ревматоидный артрит, болезни глаз, аритмия, артериальная гипертензия, болезни органов дыхания, болезни почек, сколиоз – в разрезе субъектов и муниципальных образований Российской Федерации.

2 Анализ предметной области

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

Основными причинами, ограничивающими использование традиционных данных о заболеваемости населения, являются:

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

2. Отсутствие системы полицевого учета пациентов.

3. Значительные трудности в проверке полноты и качества заполнения учетных форм.

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

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

Для более подробного представления предметной области была построена диаграмма «IDEF0». IDEF0 – методология функционального моделирования и графическая нотация, предназначенная для формирования и описания бизнес-процессов. Используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции [3].

IDEF0 сочетает в себе небольшую по объему графическую нотацию (она содержит только два обозначения: блоки и стрелки) со строгими и четко определенными рекомендациями, в совокупности предназначенными для построения качественной и понятной модели системы.

В IDEF0 моделируются управление и механизмы исполнения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм исполнения – объекты, которые непосредственно выполняют преобразование входа в выход, но не потребляются при этом сами по себе.

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

I (Input) – вход – нечто, что потребляется в ходе выполнения процесса;

С (Control) – управление – ограничения и инструкции, влияющие на ход выполнения процесса;

О (Output) – выход – нечто, являющееся результатом выполнения процесса;

М (Mechanism) – исполняющий механизм – нечто, что используется для выполнения процесса, но не потребляется само по себе [4].

Функциональная модель системы распространенности заболевание представлена на Рисунке 2.1.

Рисунок 2.1 – Функциональная модель системы

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

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

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

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

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

 На основе полученных данных анализируется распространенность заболеваний в разрезе субъектов и муниципальных образований Российской Федерации.

 Декомпозиции функциональной модели, представленной на Рисунке 2.1, позволяет увидеть верхний уровень работы системы. Для более детального рассмотрения необходимо произвести декомпозицию. Декомпозированная схема IDEF0 представлена в Приложении А.

Для представления функционирования программного компонента проведения опросов в режиме on-line была построена отдельная диаграмма IDEF0, представленная на Рисунке 2.2.

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

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

Исполнителями моделируемого действия выступают пользователь (зарегистрированный или незарегистрированный) и администратор, который своевременно вносит необходимые поправки и следит за работой программного компонента.

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

Рисунок 2.2 – Функциональная модель опросника

3  Проектирование

Проектирование является одним из самых сложных и важных этапов разработки любой системы.

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

3.1 Выявление требований

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

3.1.1 Бизнес-требования

Бизнес-требования содержат высокоуровневые цели организации или заказчиков системы. Как правило, их высказывают те, кто финансируют проект, покупатели системы, менеджер реальных пользователей, отдел маркетинга [5]. В этом документе объясняется, почему организации нужна такая система, то есть описаны цели, которые организация намерена достичь с ее помощью. Для данной системы было выработано три бизнес-требования. Информация о них размещена в Таблице 3.1.

Таблица 3.1 – Бизнес-требования

№ Название требования Описание требования

1 Наличие главной (целевой) страницы системы Данная страница является главной и должна отражать цели системы, краткую и понятную информацию о том, какими функции она обладает.

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

2 Расширение прав для зарегистрированных пользователей системы

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

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

Из описанных в Таблице 3.1 требований пользователя к разрабатываемому программному компоненту проведения опросов в режиме on-line непосредственно относится требование под номером 1.

3.1.2 Пользовательские требования

Пользовательские требования определяют набор пользовательских целей или задач, которые должна решать система, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения, пользовательских историй, сценариев взаимодействия [6]. Выработанные пользовательские требования были разделены на требования пользователя и администратора системы, и описаны в Таблицах 3.2 и 3.3.

Таблица 3.2 – Требования пользователя

№ Название требования Описание требования

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

2 Возможность прохождения опроса Пользователю должна быть предоставлена возможность пройти опрос по семи нозологиям

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

3 Возможность ввода персональных первичных данных Пользователю должна быть предоставлена возможность ввести персональные первичные данные; некоторые пункты (ФИО, e-mail) не обязательны для заполнения.

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

5 Возможность использования фильтрации по стратифицирующим признакам и перечню нозологий

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

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

6 Возможность просмотра собственного профиля Зарегистрированному пользователю должна быть предоставлена возможность просмотра собственного профиля в системе.

7 Возможность редактирования профиля Зарегистрированному пользователю должна быть предоставлена возможность редактирования настроек собственного профиля в системе.

8 Возможность смены пароля Зарегистрированному пользователю должна быть предоставлена возможность смены пароля.

9 Возможность просмотра статистических графиков Зарегистрированному пользователю должна быть предоставлена возможность просмотра статистических графиков.

10 Возможность просмотра графиков регрессии При выборе двух коррелятов (из всего списка доступных) зарегистрированному пользователю должна быть предоставлена возможность просмотра графиков регрессии.

11 Возможность наглядного для пользователя представления результатов статистического анализа данных При выборе трех и более коррелятов (из всего списка доступных) для регрессионного анализа, а также при проведении регрессионного и дисперсионного анализов зарегистрированному пользователю должна быть предоставлена

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

13 Возможность выгрузки статистических данных в формате «.csv». Зарегистрированному пользователю должна быть предоставлена возможность выгрузки статистических данных в формате «.csv».

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

15 Возможность выбора типа отображаемого графика Зарегистрированному пользователю должна быть предоставлена возможность выбора типа отображаемого графика путём выбора необходимой опции из списка доступных.

Из описанных в Таблице 3.2 требований пользователя к разрабатываемому программному компоненту проведения опросов в режиме on-line относятся требования под номерами 2, 3 и 14.

Таблица 3.3 – Требования администратора

№ Название требования Описание требования

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

2 Возможность выгрузки статистических данных в текстовом виде. Пользователю должна быть предоставлена возможность выгрузки статистических данных в текстовом виде.

3 Возможность просмотра статистики об активности пользователей Администратору должна быть предоставлена возможность просмотра статистики об активности пользователей.

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

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

3.1.3 Функциональные требования

Функциональные требования определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований [7]. Эти требования должны показать разработчикам, что они должны делать, чтобы выполнить все пользовательские требования. Выработанные функциональные требования занесены в Таблицу 3.4.

Таблица 3.4 – Функциональные требования

№  Название требования Описание требования

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

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

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

4 Возможность редактирования собственного профиля Зарегистрированному пользователю должна быть предоставлена возможность редактирования информации, содержащейся в профиле. Пользователь может загружать изображение профиля: ограничение на загрузку – файл до 5 Мб, принимаемые форматы – «.jpg», «.png».

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

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

7 Возможность просмотра статистики регистраций Администратору системы должна быть предоставлена возможность просмотра статистики регистраций в административной панели. Должна быть возможность просмотра и вывода статистики по дням, неделям, месяцам и годам. Возможность выгрузки статистики формате «.csv».

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

9 Возможность выгрузки статистических данных в формате «.csv». Зарегистрированному пользователю должна предоставляться возможность выгрузки статистических данных в формате «.csv».

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

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

12 Возможность загрузки новых, редактирования и удаления справочных таблиц Администратору должен быть предоставлен доступ к СУБД (логин/пароль) загрузки новых, редактирования и удаления справочных таблиц.

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

Из описанных в Таблице 3.4 функциональных требований к системе к разрабатываемому программному компоненту проведения опросов в режиме on-line относятся требование под номером 13.

3.1.4 Системные требования

Системные требования описывают требования к аппаратному и программному обеспечению для функционирования создаваемой системы. К параметрам аппаратного обеспечения относятся тип и частота процессора, объем оперативной памяти, объем жесткого диска [5]. К параметрам программного обеспечения можно отнести операционную систему, необходимые сервисы для функционирования создаваемого программного продукта. Эти требования очень важны, так как они напрямую зависят от целевой аудитории, для которой создается программный продукт. Так же к системным требованиям относятся нефункциональные требования, предъявляемые системе. Системные требования, выработанные для создаваемой системы, занесены в Таблицу 3.5. Также все описанные требования относятся и к разрабатываемому программному компоненту проведения опросов в режиме on-line.

Таблица 3.5 – Системные требования

№ Название требования Описание требования

1 Требования к безопасности При разработке системы необходимо предусмотреть защиту от взлома на всех этапах использования.

2 Стабильность работы Система должна стабильно работать и не конфликтовать со следующими браузерами: Google Chrome, Opera, Mozilla, Internet Explorer 10 (11).

3 Скорость работы сервера Время ответа на любой запрос не должно превышать 20 секунд.

4 Требования к хостингу Для разворачивания серверной части системы на боевом сервере необходимо, чтобы он обладал следующими характеристиками: не менее 20 Гб свободного пространства на жестком диске, 4 Гб оперативной памяти, четырехъядерный процессор с частотой не менее 3 ГГц, пропускная способность канала – 10 МБ/сек.

5 Web-сервер В качестве web-сервера должен быть выбран «Apache» из-за высокой скорости работы и возможности гибкой настройки.

6 Система управления базой данных (СУБД) В качестве СУБД должен использоваться «PostgreSQL». Данная СУБД предоставляет высокую скорость работы и большое количество надстроек.

3.2 Диаграмма прецедентов

Диаграммы прецедентов составляют модель прецедентов (вариантов использования, use-cases). Диаграмма для данной системы представлена на Рисунке 3.6.

Прецедент – это функциональность системы, позволяющая пользователю получить некий значимый для него, ощутимый и измеримый результат. Каждый прецедент соответствует отдельному сервису, предоставляемому моделируемой системой в ответ на запрос пользователя, т. е. определяет способ использования этой системы. Именно по этой причине use cases, или прецеденты, часто в русской терминологии фигурируют как варианты использования [8]. Варианты использования чаще всего применяются для спецификации внешних требований к проектируемой системе или для спецификации функционального поведения уже существующей системы. Кроме этого, варианты использования неявно описывают типичные способы взаимодействия пользователя с системой, позволяющие корректно работать с предоставляемыми системой сервисами.

Прецеденты, непосредственно относящиеся к программному компоненту проведения опросов в режиме on-line, выделены на Рисунке 3.6 прямоугольником.

Также была построена диаграмма прецедентов непосредственно для разрабатываемого программного компонента (Рисунок 3.7).

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

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