Цифровизация медицинской карты пациента: как провести исследование и создать осмысленный концепт

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

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

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

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

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

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

Чтобы ответить на эти вопросы в этом материале мы разберем:

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

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

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

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

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

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

Вот для какого контекста мы разрабатывали интерфейс:
Врач/Пациент → Врач → Врач общей практики → Контекст/Прием

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

Нашей целью было построить новую модель опыта взаимодействия с медицинской картой так, чтобы она стала лучше предыдущей. Модель должна опираться на надежное знание и содержать способ проверки на соответствие запросам пользователя. Поэтому первым делом мы сформировали целостную картину рабочего дня врача. Для этого выбрали методы и провели исследования, после чего отфильтровали и объединили полученную информацию в Customer Journey Map.

Ниже представлено сравнение методов, их плюсы и минусы.

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

Затем мы определили задачи. В реальной жизни мы двигаемся по следующему плану — нам нужно:

На данном этапе нам было важно:

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

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

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

Их преимущество в том, что они позволяют не только сразу увидеть результаты опроса, но и выявить динамику изменения. Основной недостаток — в невозможности обнаружить зависимость между ответами и основными характеристиками респондентов.

Например, мы обратились к ежегодному исследованию поведения врачей в интернете Doctor Index 2019. С его помощью мы убедились, что медицинские работники активно используют электронные устройства, в том числе смартфоны, на работе и даже во время приема. Из этого же источника мы узнали о коммуникации между пациентами и врачами вне клиники.

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

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

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

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

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

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

Дания — одна из первых стран Европы, где провели цифровизацию медицинской отрасли.

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

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

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

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

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

Также мы создали портал для дистанционного обучения врачей и CRM для стоматологий.

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

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

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

За счет сокращения времени на работу с документами и появления новых инструментов врачи смогут:

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

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

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

Как в таком случае понять, какую функциональность предлагать в своем решении?

Мы взяли за основу методику приоритизации RICE, где каждая идея или функциональность оценивается по четырем параметрам и в итоге получает определенное количество баллов.

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

Очевидно также, что мы не можем на старте говорить и об охвате. Поэтому данные параметры мы дополнили еще одним, более важным на этом этапе — степенью влияния на прочие фичи (Network Effect).

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

На практике обычно это значит:

Фичи с высокой степенью Network Effect (NE) должны стать основой концепции. Их можно назвать магистральными. С развитием сервиса и его масштабированием степень NE станет менее значительной для определения приоритетов фич, но по-прежнему полноценной среди прочих показателей RICE.

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

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

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

Подробнее о методе RICE и Network Effect можно почитать в статье Антона Иокова из Targetprocess — Enhancing prioritization with networks.

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

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

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

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

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

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

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

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

Подсказки по ходу заполнения документов контекстные в зависимости от специализации врача.

В своем интерфейсе врач может:

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

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

Можно придумывать собственные методики определения потребностей пользователей или модернизировать текущие — всё зависит от контекста не только внутри задачи, но и в той области, из которой она возникла.

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

P.S. В следующей статье мы выберем других участников процесса — врач/клиника — и покажем, как масштабируются принципы и правила из данной статьи. А пока с радостью обсудим эту!

#медицина #ux #интерфейс #проектирование_интерфейсов #дизайн #концепт