{"id":13595,"url":"\/distributions\/13595\/click?bit=1&hash=0578f662a4e99e0a477083ff538dcc87ef422d22dc979e88ddacc35e13f6995c","title":"\u041b\u044e\u0431\u0438\u0442\u0435 \u0441\u0430\u043b\u0430\u0442\u0438\u043a? \u0415\u0433\u043e \u0434\u043b\u044f \u0432\u0430\u0441 \u0441\u043e\u0431\u0440\u0430\u043b \u0432\u043e\u0442 \u044d\u0442\u043e\u0442 \u043c\u0438\u043b\u044b\u0439 \u0440\u043e\u0431\u043e\u0442","buttonText":"\u041f\u043e\u043a\u0430\u0436\u0438\u0442\u0435","imageUuid":"f0cac355-ac0f-5d0f-a8ce-eb75ae2b39ea","isPaidAndBannersEnabled":false}
Дизайн
JetStyle

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

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

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

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

С чего начинать?

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

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

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

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

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

Часть 1. Как от общей абстрактной постановки перейти к фокусировке на главных проблемах и путях их решений

Шаг 1. Выделяем область работы

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

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

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

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

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

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

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

Шаг 2. Формулируем цели и задачи

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

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

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

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

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

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

Шаг 3. Интервью с пользователями

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

  1. Понять повседневный алгоритм действий врача терапевта, частотность операций.
  2. Выявить инсайты и нюансы отношений врача с пациентами: как между ними формируются доверительные отношения.
  3. Определить личные KPI врача.
  4. Кроме того узнать:
  • выраженные желания и мотивации,
  • убеждения, установки, ценности, нормы,
  • восприятие процесса,
  • скрытые потребности.

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

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

  • В частных клиниках врачу важнее всего получить полную информацию о пациенте, чтобы за первые три минуты понять, профильный это случай или нет. Также врачу важно управлять очередью — понимать, кто к нему записан на сегодня, и, по возможности, разбивать их на группы по типам запросов.
  • В государственных клиниках есть бумажные журналы отчетности перед Министерством здравоохранения. По ним формируется эффективность поликлиники. Заполнение журнала — важная часть работы врача, если клиника не автоматизирована.
  • Специфика работы врача сельской клиники — много выездов. Первичным фильтром перед приемом у врача выступает фельдшер. Прием в поликлинике в большом проценте случаев происходит по вызову, инициированному врачом.
  • При диагностике врачу не так важны результаты анализов ребенка (в сравнении с взрослым), потому что у детей меньше хронических заболеваний.
  • Видеоконференции проводятся с профильными специалистами при уточнении и постановке сложных диагнозов и могут быть прямо во время приема.
  • 10–15% времени отнимают здоровые пациенты, которые вынуждены идти ко врачам, например за справками для работодателя.
  • Для уточнения дозировок лекарств и минимизации риска ошибок врачи регулярно обращаются к медицинским справочникам и базам.

Шаг 4. Количественные исследования

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

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

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

Шаг 5. Бенчмаркинг

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

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

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

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

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

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

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

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

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

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

Шаг 6. Экспертное мнение

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

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

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

Клиника УГМК-Здоровье

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

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

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

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

1. Общая гипотеза

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

  1. Внимательнее относиться к своим пациентам. В перспективе это повысит степень доверия пациентов и поспособствует устранению психологических барьеров по ходу лечения.
  2. Достигать KPI без ущерба качеству ведения приема и обследований.
  3. Увеличивать скорость и точность диагноза за счет более релевантного и наглядного контекста по клинической картине пациента.

2. Фокусировка на конкретных идеях

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

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

3. Валидация и приоритизация идей

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

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

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

  • Reach — охват,
  • Impact — влияние,
  • Confidence — уверенность,
  • Effort — усилия.

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

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

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

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

  1. Выбрать достаточно гибкую общую форму.
  2. Выработать словарь основных «интерфейсных слов» — так, чтобы малым количеством сущностей можно было закрыть нужное нам разнообразие кейсов.
  3. Сформулировать для себя основную работу, которую делает интерфейс, и сопоставить результат с гипотезой.

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

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

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

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

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

Часть 3. Создание концепции медкарты на основе вышесказанного

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

Лэйаут

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

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

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

Сквозной дашборд со сниппетами

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

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

Свободная форма заполнения документов

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

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

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

Примеры механик взаимодействия

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

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

Дистанционная работа с пациентом

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

Подводим итоги

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

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

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

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

арт-директор в JetStyle
0
9 комментариев
Написать комментарий...
Михаил Лебедев

Проблема в том, что все это надо внедрять разом и на государственном уровне.

Я сейчас лежу в больнице в СПб. Перед госпитализацией побывал в 5 разных больницах, поликлиниках, мед. центрах (частных и государственных).

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

Вел в Трелло и гуглдок свою историю. + Распечатанные копии. И у каждого доктора (их уже более 15) я вынужден был начинать рассказ сначала с поэтапным выкладыванием всех данных.

Ответить
Развернуть ветку
Maksim V.

Вот из-за таких малограмотных у нас и пытаются все "внедрить разом и на государственном уровне". В итоге получается - неработающее говно. Задача государства (профильных министерств) - это разрабатывать стандарты на передачу и на представление медицинской информации и т.д.. Для этого у государства есть профильные институты и научные мощности. А интерфейсы, приложения и т.д. для КОНКРЕТНОЙ клиники, со всеми ее нюансами, должны рождаться в нормальной коммерческой конкурентной  среде).

Ответить
Развернуть ветку
Михаил Лебедев

Гос. услуги тоже неработающее г?)
Местами да, но для простых людей во многих сферах упростило жизнь.
Проще говоря с ними проще чем без них.

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

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

Ответить
Развернуть ветку
Konstantin Chelovechkov

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

Ответить
Развернуть ветку
JetStyle
Автор

Спасибо!

Ответить
Развернуть ветку
Михаил Миняев

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

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

Ответить
Развернуть ветку
Victoria Ryndina

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

Ответить
Развернуть ветку
Ivan Marka

А какой сервис используете для видеосвязи с клиентами.
Я так понимаю он интегрирован на сайт?

Ответить
Развернуть ветку
Slava Yanko

Лейаут должен быть на стороне клинта, в данном случаее - практикующих врачей и их коллегий

Ответить
Развернуть ветку
Читать все 9 комментариев
null