Проектирование информационной системы "Единая диспетчерская служба скорой помощи"

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

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

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

Abstract

The aim of this work is to design the architecture of an automated system and create its layout. The main task of the System is to automate the work of the ambulance operator, the system replaces the entire process from calling the coach to her arrival. In the course of the work, the current process of activity was studied, after which the analysis of existing automated systems for full compliance with the process was carried out. Further, the functions necessary for automation were formalized and a technical solution was developed to create the ultimate automated system. The technical solution contains descriptions of the functional ensuring reliability and high load.

As a result of the work, a workable system consisting of a web service and a database was obtained. In the future, the system will be upgraded with subsequent integration with third-party information systems.

The scope of work is 31 pages, including a cover page, an annotation, a table of contents and an annex. Graduation qualification work contains 9 illustration, 5 tables showing the structure of the database, as well as the topology of the system. 16 resources are used in the work.

Оглавление

Введение

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

1.1 Основные программные решения, эксплуатирующийся в сфере медицинской скорой помощи

1.2 Преимущества АС «Единая Диспетчерская Служба Скорой Помощи»

1.3 Последствия реализации АС

2. Прикладные решения

2.1 Алгоритм нормализации симптомов

2.2 Алгоритм ранжирования запросов

2.3 Алгоритм назначения запроса в работу

3. Архитектурное решение

3.1 Кластерная Архитектура

3.2 Гео-резервирование

3.3 Многоблочность

3.4 Особый пассивный блок Reserve

3.5 Кэширование запросов на стороне клиента

3.6 Схема топологии АС

3.7 ER-диаграмма базы данных

4. Макеты приложения

4.1 Пользовательский интерфейс клиентского мобильного приложения

4.2 Пользовательский интерфейс приложения бригады

5. Результаты тестирования

5.1 Функциональное тестирование

5.2 Нагрузочное тестирование

Заключение

Список использованных источников

Введение

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

Актуальность разработки и цели создания Системы

Пререквизитами создания АС являются несколько фактов:

Массовая автоматизация и внедрения АС в коммерческие проекты.

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

Социальная составляющая.

В социальной сфере жизни человека отсутствует возможность получения быстрой прибыли. Поэтому и финансовый вклад в эту область мал. По данным [3] на 2010 год объем вложений достигал 45 триллионов долларов по всему миру. Тем ни менее, эта сфера жизни сильно нуждается во внедрении систем автоматизации. С ростом городов растет и нагрузка на социальные службы. Чтобы сохранить баланс и производительность необходимо переходить к новым методам работы.

Отсутствие аналогичных решений на рынке.

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

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

Сокращение финансовых и нефинансовых издержек

Проектируемая АС «ЕДССП» разрабатывается с целью полной замены оператора и координатора бригады скорой помощи. Она покрывает весь процесс от вызова человеком кареты, до прибытия бригады. Это позволяет сократить персонал отделения, сократив тем самым финансовые издержки. Более того за счет автоматизации процесса минимизируется вероятность ошибки, а за счет использования алгоритмов снижает время прибытия кареты. Масштабируемость и надежность позволяет увеличить объем обрабатываемых запросов.

Оптимизация процесса и удобство.

За счет использования современных способов коммуникации, человеку достаточно открыть приложение, ввести что с ним случилось и отправить запрос. Знание успокаивает, это доказала компания UBER, предоставив своим клиентам, информацию о местоположении автомобиля в режиме реального времени. Аналогичное решение применяется в АС «ЕССПД», это поможет сократить случае застраивания кареты из-за трафика во дворах.

Назначение Системы

АС «Единая Диспетчерская Служба Скорой Помощи» предназначена для полной автоматизации процесса вызова бригады скорой помощи. Начиная от звонка в 03 или 112, и заканчивая приездом конкретной кареты [6]. К функционалу системы относится:

Вызов бригады скорой помощи;

Управление очередью заявок и приоритезация обращений по тяжести;

Автоматическое назначение обращения бригаде;

Отслеживание свободных бригад по участкам;

Передача информации бригаде;

Ведение реестра обращений.

Концепция приложения

В концепции представлены кейсы взаимодействия с системой как со стороны пользователя, так и со стороны бригады скорой помощи [7].

Пользовательский сценарий:

Вход в приложение

Заполнение полей:

Симптомы;

Возраст - полоса с четырьмя делениями 0-20|20-60|60-80|80-100 (заполняется автоматически);

ФИО (заполняется автоматически);

Номер моб. Телефона (заполняется автоматически);

Местоположение (заполняется автоматически) [15];

Вызывая для себя или для другого человека.

Нажатие кнопки "Вызов"

Отображение советов по оказанию первой помощи до приезда мед. команды

Отображается карта с иллюстрацией движения автомобиля скорой

Сценарий сотрудников бригады кареты скорой помощи:

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

Мед. бригада видит симптомы, адрес клиента, его ФИО и номер телефона;

По приезду на место бригада уведомляет об этом;

При завершении вызова бригада уведомляет об этом.

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

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

Таблица 4 Сравнение АС по ключевым параметрам

Исходя из таблицы выше видно, что существующие АС проигрывают по ключевым параметрам разрабатываемой. Главное преимущество АС «ЕДССП» - полная автоматизация процесса в сочетании с надежностью и отказоустойчивостью. Этот факт говорит о явной потребности рынка в разрабатываемой АС.

1.3 Последствия реализации АС

По предварительным расчётам, реализация и внедрение «Единой Диспетчерской Службы Скорой Помощи» отразиться на следующих показателях:

Качество предоставление услуг скорой помощи

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

Минимизация количества ошибок

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

Устранения риска человеческого фактора

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

Снижение расходов отделения скорой помощи

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

Уменьшение тяжелых последствий из-за опоздания кареты

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

2. Прикладные решения

2.1 Алгоритм нормализации симптомов

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

За основу взят обзор алгоритмов [16]. В качестве инструмента формализации входных данных выбран предиктивный ввод. Сам механизм предиктивного ввода реализуется при помощи метода нагруженного дерева (анг. tries).

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

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

Рисунок 1 Нагруженное дерево.

Поиск данных в trie быстрее в худшем случае, O (m) time (где m - длина строки поиска) по сравнению с несовершенной хэш-таблицей. У несовершенной хеш-таблицы могут быть ключевые коллизии. Ключевое столкновение -- это хеш-функция, отображающая разные ключи в одну и ту же позицию в хеш-таблице. Наихудшая скорость поиска в несовершенной хеш-таблице -- это время O (N), но гораздо более типично O (1), с O (m) временем, потраченным на оценку хэша.

В trie нет столкновений разных ключей.

Сам поиска слова по ключу представлен на Рисунок 2 Поиск значения в дереве.

В качестве входных данных предстает статический словарь с симптомами. Каждый симптом является ключом для дерева.

Рисунок 2 Поиск значения в дереве

Для реализации алгоритма используется библиотека autocomleate разработанная Vivek Narayanan и лицензированная BSD [14].

2.2 Алгоритм ранжирования запросов

Следующим этапом процесса является ранжирование запроса для постановки его в очередь.

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

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

Рисунок 3 Ранжирование заявки

2.3 Алгоритм назначения запроса в работу