Перейти к основному содержанию
ИТарктика
УДК 004.4
Осипов Константин Сергеевич
преподаватель, Колледж экономики, права и информатики, федеральное государственное бюджетное образовательное учреждение высшего образования «Сыктывкарский государственный университет имени Питирима Сорокина».
Разработка технологии универсального сопряжения информационных систем, на примере системы записи к врачу
Аннотация:

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

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

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

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

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

Архитектура базы данных

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

Для проведения анализа выбраны следующие свободно распространяемые СУБД: MySQL, PostgreSQL, MongoDB. Анализ проводился по следующим метрикам: устойчивость при нагрузке (максимальное количество запросов в секунду, время, затраченное на обработку 100, 1000, 10000 запросов, стресс тест до состояния «отказ в обслуживании») и устойчивость на комбинированных запросах. Очевидно, что результаты анализа будут также зависеть от конфигурации сервера. Поэтому данный эксперимент проводился на следующем оборудовании: VDS-сервер с технологией виртуализации KVM. CPU: 2 ядра, 3.2 ГГц. RAM: 2048 МБ. HDD: 50 Гб. Сеть: 100 Мбит/с. ОС: CentOS 7. Результаты экспериментов представлены в таблице 1.

Таблица 1

Тип теста/Тип СУБД

MySQL

PostgreSQL

MongoDB

Max количество запросов в секунду

9000

7500

7000

Время (в секундах), затраченное на обработку 100/1000/10000 запросов

0,01/0,1/1,1

0,013/0,13/1,3

0,014/0,14/1,4

Стресс-тест до состояния «отказ в обслуживании»

~25000 запросов

~18000 запросов

~19000 запросов

Устойчивость на комбинированных запросах (количество запросов в секунду)

7500

6000

6000

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

Следующий шаг в построении архитектуры БД - разработка модели методом "сущность-связь".  Поскольку предметная область уже определена, установим основные сущности в ее рамках. Первая сущность, клиент. Так как пользователи будут регистрироваться в системе, необходимо  хранить их данные. Следующие сущности ¾ это специалист, клиника и информационная система.

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

Проектирование универсального интерфейса

Для успешного проектирования универсального интерфейса решено провести анализ бизнес-процесса "запись к врачу". Для анализа воспользуемся нотацией IDEF0. Контекстная диаграмма представлена на рисунке 1. На рисунке 2 изображена декомпозиция контекстной диаграммы.

kl

Исходя из схем, проведено проектирование универсального интерфейса и осуществлен переход от варианта «as is - как есть» к варианту «to be - как должно быть». Его работа осуществляется следующим образом. Клиент на сайте выбирает нужный вариант (то есть время посещения, специалист, клиника), вся введенная им информация отправится на сервер системы. На сервере универсальный интерфейс, на основе информации о клинике и ее системе, которую получает из базы, выбирает необходимый драйвер для подключения к информационной системе клиники. Далее происходит выгрузка данных о пациенте и выбранном им времени в базу данных клиники. Приложение-клиент на компьютере администратора, отправляет уведомление о том, что появился новый пациент.

Программирование серверной компоненты, веб-интерфейса, веб-сервисов

Для удобства дальнейшей реализации системы принято решение разрабатывать все ее компоненты (серверную и клиентскую части) на языке программирования Java. Разработка велась согласно Scrum-методологии [1]. То есть за короткие по времени, жёстко фиксированные итерации, разрабатывался тот или иной функционал различных компонент [2].

В первую очередь запущена серверная компонента. Для реализации использован контейнер сервлетов ApacheTomcat. Выбор данного решения основан проведенными исследованиями. Испытывались два контейнера сервлетов, ApacheTomcat и GlassFish. С точки зрения производительности и устойчивости к нагрузкам, первый вариант обошел своего оппонента.

Перед реализацией веб-интерфейса необходимо реализовать веб-сервисы. Проведены исследования, которые показали, что имеет смысл, в настоящее время использовать архитектуру RESTful в отличие от архитектуры SOAP. Одним из преимуществ RESTful является то, что эта архитектура позволяет осуществлять передачу данных непосредственно по HTTP.

Веб-интерфейс реализован с помощью Groovy объектно-ориентированного языка программирования, разработанного специально для платформы Java. Таким образом, привязка разработанного «тонкого» веб-клиента осуществлена проще, чем, если бы веб-портал был написан, например, на PHP.  Разработанные groovy-скрипты подключаются к серверной компоненте, получают запрашиваемую у сервера информацию и динамически наполняют веб-страницы.

Groovy выбран из соображений быстроты генерации динамических веб-страниц. В ходе проведенного анализа установлено, что генерация страниц, написанных на groovy, на 1 секунду быстрее страниц написанных на PHP. Если в небольших проектах это не критично, то по мере масштабирования разрабатываемой системы разница во времени генерации ответа клиенту может оказать неприятное воздействие на восприятие пользователями веб-интерфейса. Нет необходимости загружать сервер дополнительным программным обеспечением. Так как, если бы использовался язык PHP, то пришлось бы устанавливать ПО для обработки написанных скриптов. В случае с groovy это реализует Apache Tomcat с установленным плагином.

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

Реализация универсального интерфейса

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

Для универсального интерфейса применена технология REST. В Java есть API для работы с REST-сервисами – JAX-RS [3]. Процесс работы осуществляется следующим образом:

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

Отладка универсального интерфейса

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

Заключение

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

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

Список литературы

  1. Мартин, Р. К. Быстрая разработка программ: принципы, примеры, практика [Текст] : пер. с англ. / Р. К. Мартин, Дж. В. Ньюкирк, Р. С. Косс – Москва : Вильямс, 2004. – 752 с.
  2. Кораблев, А. Ю. Методология Scrum при подготовке инновационных студенческих проектов [Текст] / А. Ю. Кораблев // Инноцентр. – 2016. – №4(13). – С. 1-6.
  3. Webber, J. REST in Practice: Hypermedia and Systems Architectur [Electronic resource] / J. Webber, S. Parastatidis, I. Robinson. –
    Sebastopol : O'Reilly Media, 2010. – 448 p.

References

  1. Martin, R. K. Rapid development of programs: principles, examples, and practice [Text] : translated from English. / R. K. Martin, J. V. Newkirk, R. S. Koss – Moscow : Williams, 2004. – 752 p.
  2. Korablev, A. Yu Scrum Methodology in the preparation of innovative student projects [Text] / A. Korablev // Innocenter. – 2016. – №4(13). – Р. 1-6.
  3. Webber, J. REST in Practice: Hypermedia and Systems Architectur [Electronic resource] / J. Webber, S. Parastatidis, I. Robinson. –
    Sebastopol : O'Reilly Media, 2010. – 448 p.