Дизайн-мышление в проектах внедрения медицинских информационных систем

Подробности

Опубликовано: 10.07.2020 11:29

Автор: Юмашева Анастасия Олеговна

Просмотров: 3506

Аннотация: в работе реализуется автоматизация процесса приема врача-офтальмолога для уменьшения времени выполнения рабочих процессов и снижение вероятности появления ошибок в работе. Предметом исследования являются такие бизнес-процессы, как первичный приём, офтальмологический осмотр и постановка диагноза. Цель работы – демонстрация применения метода дизайн-мышления в проектах внедрения медицинских информационных систем на примере автоматизации работы врача офтальмолога с использованием MS Access.
Скачать: PDF, PPT, MP4.
Ключевые слова: дизайн-мышление, невербальные средства моделирования, пространственные средства моделирования, эмпатия, генерация идей, метод новичка, метод что как почему, метод интервью для эмпатии, метод экстремальных пользователей, метод аналогии, доверительный коэффициент Стьюдента.

Введение

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

Чтобы избежать этого, при создании любого продукта нужно в первую очередь исходить из потребностей и нужд тех, на кого он ориентирован, не упуская при этом из внимания производственных возможностей. Этим целям служит методология, называемая дизайн-мышлением. Особенностями данной методологии являются ориентация на пользователя, исследование проблемы и её контекста с разных сторон, творческий подход к решению проблемы и использование графических средств моделирования [1, 2].

Объектом исследования данной работы является отсутствие автоматизации процесса приёма врача-офтальмолога, из-за чего на одни и те же процессы затрачивается больше времени и выше вероятность ошибки. Предметом исследования являются такие бизнес-процессы, как первичный приём, офтальмологический осмотр и постановка диагноза. Решением поставленных задач будет моделирование и создание необходимого программного обеспечения. Цель работы – демонстрация применения метода дизайн-мышления в проектах внедрения медицинских информационных систем на примере автоматизации работы врача офтальмолога с использованием MS Access. Задачи для реализации цели:

• Проанализировать метод дизайн-мышления для внедрения медицинских информационных систем.
• Идентифицировать требования к процессам приема пациента, проверки зрения и постановки диагноза врачом-офтальмологом.
• Спроектировать процессы в ARIS VACD и ARIS eEPC для модели AS-IS и TO-BE до 3-4 уровней детализации; данные – UML CD, включая нормализацию таблиц; структуру приложения, а также блок-схему заданной разрабатываемой функции.
• Реализовать и количественно оценить программное приложение для автоматизации работы больницы, включая разработку заданной функции, в среде MS Access.

Раздел 1. Обзор литературных источников

В данном разделе дан обзор литературных источников, с использованием материалов которых выполнялась данная работа. Для изучения понятия и особенностей дизайн-мышления обратились к книге «Дизайн-мышление в бизнесе» Тима Брауна [1], где автор рассказывает о применении методов профессионального дизайна в решении бизнес-задач. В первой части подробно рассказывается о сути дизайн-мышления и его особенностях, а во второй и третьей части даются предметные рекомендации применения методологии в индивидуальной работе и работе организаций. В книге Остервальдера А. «Построение бизнес-моделей. Настольная книга стратега и новатора» [2] идёт упор на графическую часть дизайн-мышления – визуальное представление основных факторов, влияющих на успех организации. Книга адресована предпринимателям и руководителям, которые хотели бы создать новую или реорганизовать имеющуюся модель бизнеса. Рассматривались также работы Сташенко М. «Мы ищем, что в мире можно улучшить» [3] и «Что такое дизайн-мышление» Храмковой Е. и [4], Известьевой Е. [5] – статьи дают начальное понимание сути и назначения дизайн-мышления. В «Руководстве по дизайн-мышлению» Андронова Д., Карпушиной О. Молчановой Ю. и Хлоповой А. приводятся этапы дизайн-мышления и описываются разнообразные методы, которыми можно воспользоваться на каждом из этапов [6].

Статья «Требования. Анализ требований, виды требований» [7] посвящена понятию, видам и анализу требований. В учебном пособии Гвоздевой Т.В., Баллод Б.А. «Проектирование информационных систем» [8] представлены этапы разработки информационной системы в соответствии с ГОСТами; различные подходы к проектированию информационных систем; современные технологии и методологии проектирования; методы и средства проектирования систем; характеристика применяемых технологий проектирования; методики планирования и управления проектами на каждой стадии проектирования. В учебном пособии Варзунова А. В., Торосяна Е. К., Сажневой Л. П. «Анализ и управление бизнес-процессами» [9] представлен комплекс вопросов, связанных с анализом и управлением бизнес-процессами на предприятии. Изложены сущности функционального и процессного подходов к управлению, рассмотрено понятие бизнес-процесса, представлена классификация бизнес-процессов. Основное содержание пособия посвящено анализу и оптимизации бизнес-процессов, изложены способы и технологии описания и моделирования процессов, правила и рекомендации по выбору приоритетных процессов для оптимизации, а также конкретные приемы повышения эффективности процессов. 

Методические указания по дисциплине «Модели и методы информационно-управляющих систем» И.В. Абрамова [10] знакомят  с моделями «AS-IS» и «TO-BE», которые отражают моделирование системы в изначальном состоянии и после привнесения изменений. Для изучения разработки информационных систем обращались к «Анализ, проектирование и разработка корпоративных информационных систем: уровень процессов» и «Информационные технологии в биотехнических системах: задания по практическим и лабораторным работам» Степанова Д.Ю. [11, 12]. Данные работы в наиболее наглядном и кратком виде описывают такие темы, как анализ, уровни процессов, архитектура предприятия, а также концепция, методы, уровни моделирования и связи между ними. Так же в первой работе наглядно описаны модели «AS-IS» и «TO-BE».

 Статья «Институт типовых решений – производство, нотация описания бизнес-процессов ARIS eEPС, распространенные ошибки моделирования» [13] знакомит  с методологией описания бизнес-процессов eEPC ARIS, базирующейся на концепции ARIS, приводит основные понятия и принципы в наглядной форме на примерах. В этой статье рассмотрено «урезанное» подмножество eEPC ARIS, которое наиболее часто применяется для документирования бизнес-процессов на проектах автоматизации. Книга Дейт К. Дж. «Введение в системы баз данных» [14] содержит исчерпывающее введение в обширную теорию систем баз данных, сделан акцент на усвоении сути и глубоком понимании излагаемого материала, а не просто на его формальном изложении. В книге Владимира Репина и Виталия Елиферова «Процессный подход к управлению. Моделирование бизнес-процессов» [15] приводятся методики выделения процессов в организации, моделирования процессов в нотациях IDEF0, IDEF3, DFD, ARIS, «Процедура» среды моделирования Business Studio, BPMN, предлагаются способы построения сети бизнес-процессов.

К работе Уокенбаха Дж. «Excel 2010. Профессиональное программирование на VBA» [16] обращались, чтобы получить базовые знания по этому языку программирования для выполнения одной из функций приложения, а к работе «Основы визуальной алгоритмизации: Учебное пособие для студентов» Афанасьевой Т.В. [17] – для построения алгоритма этой функции. В книге «Visual Basic для студентов и школьников» Культина Н.Б., Цоя Л.Б. [18] рассматривается процесс создания программ различного назначения на языке программирования Visual Basic – от простейших до программ работы с графикой и базами данных, демонстрируется среда разработки, приводится описание языка программирования Visual Basic, рассматриваются основные алгоритмические структуры. Наконец, учебное пособие Штенникова Д.Г. «Разработка информационных систем в образовании» [19] и методические указания Клебанова Б.И. «Проектирование автоматизированных систем обработки информации и управления» [20] содержат большой объём информации об информационных системах, их проектированию, разработке, функциональных и технических требованиях, тестировании и оценке.

Существует множество различных моделей жизненного цикла ПО, одна из них – спиральная модель. В ней делается упор на начальные этапы ЖЦ системы: анализ и проектирование. Спиральная модель – классический пример применения эволюционной стратегии разработки [4]. Особенность данной модели заключается в том, что прикладное программное обеспечение создается не сразу, а по частям (модулям) с использованием метода прототипирования. В данной модели прототип – действующее программное обеспечение, реализующее отдельные функции и внешний интерфейс пользователя [5]. Как показано на рис. 1.1, модель определяет четыре действия, каждое из которых соответствует своему квадранту спирали:

• подготовка – сбор требований и ограничений;
• планирование – формирование плана проекта и анализ рисков;
• моделирование и конструирование (разработка) – подготовка моделей и реализация продукта следующего уровня;
• развертывание – оценка заказчиком текущей версии продукта.  

Раздел 2. Теоретическая часть

2.1. Методология разработки приложения

2.1.1. Особенности дизайн-мышления

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

• Действовать в соответствии со стратегиями, ориентированными на решение задач – то есть, вместо того, чтобы принять проблему как заданную, проектировщики исследуют данную проблему и её контекст.
• Перенимать и использовать продуктивные рассуждения.
• Использовать невербальные, графические и/или пространственные средства моделирования.

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

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

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

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

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

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

2.1.2. Этапы разработки приложения 

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

2.2. Проектирование приложения

2.2.1. Эмпатия 

Эмпатия – основа дизайна, ориентированного на человека. На этом этапе изучаются пользователи, их нужды и предпочтения, в том числе и с помощью непосредственного общения вживую и постановки себя на их место. Таким образом, можно выяснить скрытые потребности пользователей, их эмоции в ответ на тот или иной опыт, определить, каким является целевой пользователь. Требования к приложению можно получить следующим образом [6]:

• Метод «Новичка» – погружаясь в предметную область, походить к ней без оценок и стереотипов, проявлять любопытство, слушать и наблюдать, чтобы получать информацию без призмы предубеждений.
• Метод «Что? Как? Почему?» – изучив общую картину, углубиться в конкретную ситуацию и разобрать её на составляющие, чтобы выявить скрытые потребности пользователей.
• Метод «Интервью для эмпатии» – проводится интервью, чтобы узнать и прояснить эмоции, потребности и опыт непосредственных пользователей.
• Метод «Экстремальных пользователей» – взаимодействие с пользователями с противоположными точками зрения на предметную область, например, поклонниками продукта и людьми,  которые никогда о нём не слышали.
• Метод аналогии – позволяет взглянуть на предметную область с неожиданной стороны, изучая ситуации, не связанные непосредственно с предметной областью, но имеющие те же аспекты.

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

2.2.2. Фокусировка

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

Пользовательские требования – определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе [7]. База данных должна быть способна выполнять следующие функции:

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

Функциональные требования вытекают из пользовательских требований и определяют действия, которые система должна быть способной выполнить, связь входа/выхода в поведении системы [8]. База данных должна содержать следующие таблицы:

• Пациенты – для хранения информации о пациентах.
• Осмотр – для хранения информации о результатах осмотра.
• Приём – для хранения информации о приёме врача.
• Врачи – для хранения информации о врачах.
• Диагнозы – для выбора необходимого диагноза из готовой базы.

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

Таблица 2.1. Список требований

2.2.3. Генерация идей

Этот этап нужен для перехода от проблемы к ее решению. Он позволяет: 

• Выбросить из головы очевидные решения и начать думать вне шаблонов.
• Увеличить потенциал инновационности решения.
• Открыть новые области для исследования.
• Создать гибкий (за счет вариативности идей) и плавный (за счет огромного количества идей) инновационный процесс.

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

При проектировании модели бизнес-процесса обычно сначала строится модель уже существующей организации работы – AS-IS («Как есть»). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной [9]. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-BE («Как будет») – модели новой организации бизнес-процессов [10].

Для наглядного моделирования бизнес-процессов воспользуемся нотацией ARIS VACD и eEPC. ARIS – методология и программный продукт для моделирования бизнес-процессов организаций. Любая организация в методологии ARIS рассматривается с пяти точек зрения: организационной, функциональной, обрабатываемых данных, структуры бизнес-процессов, продуктов и услуг. При этом каждая из этих точек зрения разделяется ещё на три подуровня: описание требований, описание спецификации, описание внедрения. ARIS предоставляет визуальный инструментарий для обеспечения наглядности моделей. Для моделирования бизнес-процессов воспользуемся приложением ARIS Express.

Существует несколько нотаций проектирования, которые подходят для разных уровней описания [11, 12]. Нотация ARIS Value Added Chain Diagram (ARIS VACD) используется для верхнеуровневого (1 уровень) описания. На этих уровнях описываются ключевые процессы, выполняемые в организации.

Нотация ARIS – eEPC (extended Event Driven Process Chain) (расширенная модель цепочки процессов, управляемых событиями) подходит для более низкоуровневого (2-8 уровень) описания процессов. Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса [13, 14]. Графические элементы данных нотаций приведены в таблицах 2.2 и 2.3.

Таблица 2.2. Условные обозначения нотации ARIS VACD

Наименование	Описание	Графическое представление
Процесс	Отражает процессы, выполняемые в организации
Входящий/исходящий объект	Отражает носители информации
Организационная единица	Отражает реальные различные организационные звенья предприятия

Таблица 2.3. Графические элементы ARIS eEPC

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

При рассмотрении процессов на первом уровне выделяются 4 основных процесса: приём пациента, проверка зрения, диагностика, контроль лечения (рис. 2.1).

Рис. 2.1. 1-й уровень в нотации ARIS VACD

Рис. 2.2. 2-й уровень в нотации ARIS eEPC в модели AS-IS

Далее необходимо перейти ко второму уровню описания каждого из процессов последовательно в начале в модели «AS-IS», а затем в модели «TO-BE». Для наглядности рассмотрим модели на примере модели 2 уровня «Принять пациента»; остальные модели 2-го и 3-го уровней будут представлены в приложении А. Итак, при приёме пациента основными процессами будут: получить либо создать карту пациента, опросить пациента и назначить медицинские тесты (рис. 2.2). При введении разрабатываемого приложения для автоматизации процесс упрощается за счёт того, что врачам не приходится тратить время на поиск или создание бумажной карты (рис. 2.3).

Рис. 2.3. 2-й уровень в нотации ARIS eEPC в модели TO BE

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

Рис. 2.4. Карта процессов

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

Отношение называется приведенным к первой нормальной форме, если все его атрибуты простые. Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и значения в каждом неключевом атрибуте однозначно определяются значением первичного ключа. Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и все неключевые атрибуты не зависят друг от друга [15]. Полученная архитектура данных приведена к третьей нормальной форме и представлена на рисунке 2.5.

Рис. 2.5. Архитектура данных разрабатываемого приложения

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

Таблица 2.4. Атрибуты таблицы «Пациенты»

Таблица 2.5. Атрибуты таблицы «Осмотр»

Таблица 2.6. Атрибуты таблицы «Приём»

Таблица 2.7. Атрибуты таблицы «Врачи»

Таблица 2.8. Атрибуты таблицы «Диагнозы»

2.2.3. Описание разрабатываемого приложения

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

Рис. 2.6. Страница авторизации

На рисунке 2.7 представлена главная вкладка интерфейса приложения, куда пользователь перенаправляется после авторизации.

Рис. 2.7. Главная страница интерфейса

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

Рис. 2.8. Страница интерфейса «Пациенты»

Вкладка «Найти пациента» будет содержать варианты «Найти пациента по коду», «По фамилии» и «По дате осмотра». Результаты запроса будут представлены в виде формы, похожей на форму на рисунках 2.9-2.10.

Вкладка, представляющая данные офтальмологического осмотра, будет довольно объёмной из-за количества специфической информации, которую необходимо структурировано представить (рис. 2.9-2.10). Эти данные можно будет отправить на печать и выдать пациенту.

Рис. 2.9. Страница интерфейса «Осмотр офтальмолога», верх

Рис. 2.10. Страница интерфейса «Осмотр офтальмолога», низ

Вкладка «Приём» (рис. 2.11) позволит записать пациента в выбранное время к выбранному врачу. Эти данные будут потом отображаться во вкладке «Врачи», чтобы врач мог видеть все записи, относящиеся к нему.

Рис. 2.11. Страница интерфейса «Приём»

Структура отчёта по диагнозам представлена на рисунке 2.12. Пациенты будут сгруппированы по диагнозам для более наглядной картины. База диагнозов будет содержать все офтальмологические диагнозы в соответствии с МКБ-10, чтобы при диагностировании врач мог выбрать вариант из полного списка.

Рис. 2.12. Страница интерфейса «Диагнозы»

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

Рис. 2.13. Страница интерфейса «Врачи»

Взаимодействие между страницами отображено на схеме приложения, приведённой на рисунке 2.14.

Рис. 2.14. Схема приложения

Раздел 3. Программно-алгоритмическая часть

3.1. Прототипирование 

3.1.1. Среда управления базами данных Microsoft Access

Среда Microsoft Access обладает всеми чертами классической системы управления базами данных (СУБД). Access – это не только мощная, гибкая и простая в использовании СУБД, но и система для разработки приложений баз данных. К числу наиболее используемых компонентов Access относятся средства разработки объектов и мастера, которые можно использовать для создания таблиц, запросов, различных типов форм и отчетов. Чтобы полностью автоматизировать работу приложения, можно использовать макросы для связывания данных с формами и отчетами. Для проектирования базы данных необходимо располагать описанием выбранной предметной области, которое должно охватывать реальные объекты и процессы, определять все необходимые источники информации для обеспечения предполагаемых запросов пользователя и решаемых в приложении задач.

3.1.2. Язык программирования Visual Basic for Applications

СУБД Microsoft Access обладает весьма удобными визуальными инструментами для разработки приложений, что позволяет создавать функциональные продукты без необходимости прибегать к программному коду. Тем не менее, линейка Microsoft Office, которой принадлежит Access, так же предоставляет возможность работать и с языком программирования Visual Basic for Applications, упрощённой версией Visual Basic, которая дополняет и расширяет функциональность ранее использовавшихся специализированных макроязыков. Достоинствами VBA можно назвать простоту освоения, благодаря которой работать с ним могут пользователи, не знакомые ранее с программным кодом, а также написание скрипта прямо в среде программного продукта [16].

3.1.3. Программная реализация приложения

На рисунках 3.1-3.2 будут показаны скриншоты некоторых элементов интерфейса приложения. Все скриншоты можно найти в приложении Б.

Рис. 3.1. Главная страница приложения

Рис. 3.2. База пациентов

Для того чтобы реализовать функцию авторизации, прибегнем к программному коду Visual Basic for Applications. На рисунке 3.3 представлена форма авторизации – первое, что видит пользователь при запуске приложения.

Рис. 3.3. Форма авторизации

Рис. 3.4. Блок-схема функции авторизации

Теперь представим функцию авторизации в виде блок-схемы для дальнейшего программирования (рис. 3.4) [17]. Как видно из блок-схемы, для приложения предусмотрена авторизация для администрации: при указанном логине и пароле пользователь получает доступ к форме «Врачи редактировать» (рис. 3.6), где можно добавлять и изменять данные сотрудников, а также просмотреть и изменить пароли для авторизации. Из главной страницы доступ к этой функции не получить.

Рис. 3.5. VBA код для авторизации

Рис. 3.6. Страница редактирования записей о сотрудниках

На рисунке 3.5 показан непосредственно код, позволяющий персоналу входить в БД под своим номером в качестве логина и паролем, предусмотренным при регистрации нового сотрудника [18].

3.2. Тестирование

Тестирование программного обеспечения – процесс анализа программного продукта и сопутствующей документации с целью выявления недостатков в работе и повышения его качества [19]. Функциональное тестирование – это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Результаты функционального тестирования представлены в таблице 3.1. Из результатов видно, что все функции разрабатываемой системы функционируют должным образом.

Таблица 3.1. Функциональное тестирование

Функция	Реализация	Графическое представление
Авторизация	Событие, прописанное через VBA в форме авторизации
Ввод и сохранение новых данных	Открытие формы на добавление и встроенный макрос «Сохранить»
Поиск по записям	Форма на основе параметрического запроса
Выбор диагнозов из базы	Выкатной список, основанный на таблице «Диагнозы»
Печать результатов осмотра	Макрос печати формы

Нагрузочное тестирование – подвид тестирования производительности, сбор показателей и определение производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе [20]. Для его проведения рассмотрим время отклика разработанной системы при работе с разным числом записей. В начале, с помощью электронного секундомера проведём 5 измерений времени отклика системы для каждого из выбранного кол-ва записей, результаты занесём в таблицу 3.2. 

Таблица 3.2. Нагрузочное тестирование 

Рассчитаем среднее арифметическое по формуле (1):

                                                                                            (1)

Затем рассчитаем среднее квадратичное отклонение по формуле (2):

                                                        (2)

и погрешность измерений по формуле (3):

                                                            (3)

где n – число измерений, ta(n-1) – доверительный коэффициент Стьюдента, равный 0.95, А – абсолютная погрешность прибора (в данном случае – электронного секундомера, равная 0.005). 

Итоговое время отклика находим по формуле (4):

                                                                     (4)

Результаты заносим в таблицу 3.3.

Таблица 3.3. Результаты нагрузочного тестирования 

Раздел 4. Экономическая часть 

4.1. Планирование и контроль выполнения работ

Проектная команда включает три сотрудника:

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

4.2. Расчет сметы затрат на разработку программного приложения

Затраты на разработку состоят из следующих статей расходов: 

• Заработная плата исполнителей.
• Страховые взносы с заработной платы.
• Материалы.
• Затраты на электроэнергию.
• Амортизация оборудования. 

Затраты на оплату труда включают основную заработную плату (З_осн) и дополнительную заработную плату (З_доп), формула (5). 

Ф_зп =  ЗП_осн + ЗП_доп,                                                              (5)

Основная заработная плата начисляется исходя из ставки сотрудника и времени, затрачиваемого на выполнение работ (таблица 4.1). 

Таблица 4.1. Затраты на заработную плату 

Расчеты в таблице 4.1 выполнены при условии восьмичасового рабочего дня. Расчет заработной платы проводится по формулам (6) и (7).

ЗП = t_час * Т_час,                                                                 (6)

где ЗП – заработная плата, t_час – часовая тарифная ставка, Т_час – фактически отработано часов.

ЗП_осн = ЗП_рук + ЗП_раз + ЗП_тест                                                  (7)

Дополнительная заработная плата составляет 15% от основной, тогда:

ЗП_доп = 0,15 * ЗП_осн.                                                               (8)

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

• Налог с доходов физических лиц НДФЛ (гл. 23 НК РФ).
• Страховые взносы:
  • На пенсионное страхование (гл. 34 НК РФ).
  • На медицинское страхование (гл. 34 НК РФ).
  • На социальное страхование (гл. 34 НК РФ).
  • На социальное страхование от несчастных случаев (закон № 125-ФЗ).

При этом НДФЛ удерживается из зарплаты сотрудника, а  страховые взносы начисляются за счет работодателя.

Таблица 4.2. Налоги и взносы

Таким образом, затраты на страховые взносы рассчитываются по формуле (9).

З_стр = Ф_зп * 0,302.                                                                   (9)

Далее произведем расчет материальных затрат. Материальные затраты часто занимают весьма значительную часть затрат в деятельности предприятия. На момент начала разработки системы имеется необходимая для работы компьютерная техника с программным обеспечением и собственное помещение, поэтому нет необходимости покупать оборудование, ПО и брать помещение в аренду. При выполнении работ по разработке автоматизированной информационной системы подбора материалов для изготовления медицинских инструментов к материальным затратам будут относиться только затраты на канцелярские товары (таблица 4.3).

Таблица 4.3. Затраты на канцелярские товары 

Затраты на электроэнергию зависят от стоимости машинного часа и времени работы оборудования и определяются по формуле (10).

                                   З_эл = Р ∗ Ц_эл ∗ Т_и ,                                                               (10)

где Р – потребляемая мощность оборудования, кВт/ч, Ц_эл – стоимость одного кВт/ч, руб., Т_и – время использования оборудования при проведении работ, ч. Расчёты затрат на электроэнергию представлены в таблице 4.4.

Таблица 4.4. Затраты на электроэнергию 

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

                                                                                   (11)

где Ф_перв – первоначальная стоимость оборудования и приборов, руб., Н_а – годовая норма амортизации, Т – время использования оборудования (дни), Ф_эф  – годовой эффективный фонд времени работы оборудования, для односменной работы он составляет 256 дней.

Таблица 4.5. Затраты на амортизацию оборудования 

Составим смету затрат на реализацию проекта (таблица 4.6).

Таблица 4.6. Смета затрат

4.2. Обоснование экономической целесообразности

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

Заключение

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

Были рассмотрены основы проектирования баз данных, описаны ключе-вые бизнес-процессы, построены концептуальная и реляционная модели. Биз-нес-процессы приёма, осмотра и постановки диагноза были представлены в моделях «AS-IS» и «TO-BE» в нотациях ARIS VACD для верхнеуровневого (1 уровень) и ARIS – eEPC для нижнеуровневого описания.

Разработка приложения осуществлялась в среде управления базами дан-ных MS Access: были рассмотрены основы работы с данной СУБД, в ходе проектирования были учтены собранные требования и исправлены недочёты. Также были рассмотрены основы программного языка Visual Basic for Applications, специально разработанного для работы с продуктами Microsoft и необходимого для реализации некоторых функций. По завершению проектирования было проведено тестирование функций приложения и нагрузочное тестирование, которые показали, что программа справляется со своими функциями. В работе произведены экономические расчёты и обоснование экономической целесообразности разработки приложения.

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

Приложение А

Рис. 1. 3 уровень AS-IS, «Собрать информацию о пациенте»

Рис. 2. 2 уровень AS-IS, «Провести диагностику»

Рис. 3. 2 уровень AS-IS, «Произвести контроль лечения»

Рис. 4. 3 уровень AS-IS, «Передать пациента на лечение»

Рис. 5. 3 уровень TO-BE, «Собрать информацию о пациенте»

Рис. 6. 2 уровень TO-BE, «Провести диагностику»

Рис. 7. 2 уровень TO-BE, «Произвести контроль лечения»

Рис. 8. 3 уровень TO-BE, «Передать пациента на лечение»

Приложение Б

 Рис. 9. Окно интерфейса «Найти пациента»

Рис. 10. Окно параметрического запроса «Введите фамилию пациента»

Рис. 11. Окно интерфейса «Офтальмологический осмотр», верхняя часть

Рис. 12. Окно интерфейса «Офтальмологический осмотр», нижняя часть

Рис. 13. Окно интерфейса «Данные пациента»

Рис. 14. Окно интерфейса «Приём»

Рис. 15. Окно интерфейса «Отчёт по диагнозам»

Рис. 16. Окно интерфейса «База диагнозов»

Рис. 17. Окно интерфейса «Врачи»

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

1. Тим Браун «Дизайн-мышление в бизнесе. От разработки новых продуктов до проектирования бизнес-моделей», 2012.
2. Остервальдер А. «Построение бизнес-моделей. Настольная книга стратега и новатора».
3. Сташенко М. «Мы ищем, что в мире можно улучшить», 2014 – URL: https://theoryandpractice.ru/posts/9238-dizayn-myshlenie.
4. Екатерина Храмкова «Что такое дизайн-мышление», 2011 – URL: http://www.lookatme.ru/flow/posts/books-radar/121179-chto-takoe-dizayn-myshlenie.
5. Изместьева Е. «Что такое дизайн-мышление», 2015 – URL: https://te-st.ru/2015/01/28/what-is-design-thinking/
6. Андронов Д., Карпушина О. Молчанова Ю. Хлопова А. «Руководство по дизайн-мышлению».
7. Требования. Анализ требований, виды требований – URL: https://intellect.ml/trebovaniya-analiz-trebovanij-vidy-trebovanij-5188.
8. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
9. Варзунов А. В., Торосян Е. К., Сажнева Л. П., Анализ и управление бизнеспроцессами // Учебное пособие. – СПб: Университет ИТМО, 2016. – 112 с.
10. И.В.Абрамов. Методические указания по дисциплине «Модели и методы информационно-управляющих систем». Ижевск, 2004 – 314 с.
11. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень процессов. – М., 2017.
12. Степанов Д.Ю. Информационные технологии в биотехнических системах: задания по практическим и лабораторным работам. – М.: 2017.
13. Институт типовых решений – производство, нотация описания бизнес-процессов ARIS eEPС, распространенные ошибки моделирования – URL: https://itrp.ru/questions/notatsiya-opisaniya-biznes-protsessov-aris-eepc/
14. Дейт К. Дж. Введение в системы баз данных / пер. с англ. и ред. К. А. Птицына – 8-е изд. – М.: Вильямс – 2016. – 327 с.
15. Владимир Репин, Виталий Елиферов. «Процессный подход к управлению». Моделирование бизнес-процессов. Издательство «Манн, Иванов и Фербер», Москва, 2013 – 215 с.
16. Уокенбах Дж. - Excel 2010. Профессиональное программирование на VBA – Киев: Изд-во «Диалектика», 2012. – 994 стр.
17. 17. Афанасьева Т.В. Основы визуальной алгоритмизации: Учебное пособие для студентов. – М.: Ульяновский государственный технический университет, 2012 – 64 с.
18. Культин Н. Б. Цой Л. Б. Visual Basic для студентов и школьников // Издательство «БХВ – Петербург», 2010 – 401 с.
19. Штенников Д.Г. Разработка информационных систем в образовании. Учебное пособие. – СПб: СПбГУ ИТМО, 2012. – 242 с.
20. Клебанов Б.И. Проектирование автоматизированных систем обработки информации и управления. Методические указания к выполнению курсового проекта М.: Уральский государственный технический университет, 2004. – Программы для стоматологий – URL: http://www.livemedical.ru/tools/dental/ (дата обращения 12.12.2018).

Выходные данные

Юмашева А.О. Дизайн-мышление в проектах внедрения медицинских информационных систем: диплом бакалавра / МИРЭА. – М., 2020. – 55 с. – URL: https://stepanovd.com/training/20-vkr/106-vkrb-2020-6-yumasheva.