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

Подробности

Опубликовано: 14.07.2020 10:24

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

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

Аннотация: в статье рассматривается автоматизация процесса первичного приёма врача-офтальмолога. Рассматривается методология дизайн-мышления, применяемая для проектирования бизнес-процессов, формирования и нормализации структуры баз данных, моделирования и разработки удобного и простого интерфейса, нацеленная на автоматизацию работы врача-офтальмолога.
Скачать: PDF (статья), PDF (выпуск №11).
Ключевые слова: АРМ офтальмолога, кабинет врача офтальмолога, АРМ для офтальмологов, программы для офтальмологической клиники, база данных для офтальмологии, CRM для клиники, программа для телемедицины, медицинские информационные системы, программы для клиник и медицинских центров, автоматизация врача офтальмолога в поликлинике.

Введение

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

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

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

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

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

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

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

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

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

2. Эмпатия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1. Проектирование процессов

Для наглядного моделирования бизнес-процессов воспользуемся нотацией 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].  При рассмотрении процессов на первом уровне выделяются 4 основных процесса: приём пациента, проверка зрения, диагностика, контроль лечения (рис. 1).

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

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

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

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

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

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

Литература 

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).

Выходные данные статьи

Юмашева А.О. Дизайн-мышление в проектах внедрения информационных систем (часть 1) // Корпоративные информационные системы. – 2020. – №3(11). – С. 38-48. – URL: https://corpinfosys.ru/archive/issue-11/101-2020-11-designthinkingis.

Об авторе

Юмашева Анастасия Олеговна – студентка 4-го курса кафедры оптических и биотехнических систем и технологий физико-технологического института РТУ МИРЭА. Тема выпускной квалификационной работы бакалавра «Дизайн-мышление в проектах внедрения медицинских информационных систем». Электронная почта: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №11

1. Новое в порядке проведения, оформления и учета консервации объектов;
2. Автоматизация бухгалтерского учета спецодежды (часть 1);
3. Дизайн-мышление в проектах внедрения информационных систем (часть 1);
4. Agile Scrum для реализации автоматизированного рабочего места врача (часть 2);
5. Закупки в системе SAP ERP (часть 1).