Проблемы разработки пользовательского интерфейса медицинских систем

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

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

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

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

С некоторых пор в Москве стало неприличным выглядеть непонимающим в компьютерах, поэтому никто из персонала клиники не признается, что ему что-то непонятно, а просто ответит: «Мне сейчас некогда этим заниматься». Если с первого взгляда что-нибудь непонятно, второго, скорее всего, просто не будет. Зато если сразу все понятно, то все радуются и хвалят: «Какая хорошая, замечательная программа!»

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

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

Формально стандартизированность пользовательского интерфейса уместно связать с другими инфраструктурными характеристиками качества программного продукта, такими, как соответствие ( conformance ), в том числе и соответствие стандартам, и взаимозаменяемость ( replaceability ). При комплексной оценке показателей качества программного продукта качество пользовательского интерфейса вносит определяющий вклад в такую субхарактеристику качества, как практичность ( usability ) [1].

В пользовательском интерфейсе можно условно выделить декоративную и активную составляющие. К первой относятся элементы, отвечающие за эстетическую привлекательность программного изделия. Управляющие (активные) средства различных классов программных изделий могут значительно различаться. Правильность управля- ющих средств пользовательского интерфейса конкретного приложения - это соответствие управляющих средств синтаксису интерфейсов соответствующего типа.

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

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

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

Для заказчика программный продукт и его интерфейс совершенно тождественны. Следовательно, показав заказчику интерфейс на стадии подготовки ТЗ, можно снизить количество и объем переделок, потребность в которых возникает из-за расхождений ожиданий заказчика с запланированной в ТЗ функциональностью системы. Таким образом, есть объективная польза в том, чтобы рассматривать проектирование интерфейса не как стадию разработки, а как стадию создания ТЗ. При этом практика показывает, что промежуточные наглядные результаты работы над системой, а именно прототипы интерфейса, продемонстрированные уже на второй день работы, а не через несколько недель, приводят клиента к удовлетворению [2]. В отличие от обычного ТЗ, работа над которым заказчику реально не видна, прототипы ин- терфейса легко понятны и прогресс в работе явно заметен.

Техническая проблема связана с трудностями прототипирования. В обычном режиме работы интерфейс создается уже в средстве разработки, создавать же прототип таким образом нерентабельно. Интерфейс создается через множество итераций, а переделывать уже сделанное достаточно дорого. Сравнительно недавно появились специальные средства для прототипирования интерфейса (например, Norpath Studio ), но пока они довольно сырые. Выход - в использовании неспециализированных графических редакторов. Еще несколько лет назад основным таким редактором являлся MS PowerPoint, сейчас же наиболее удобным следует признать MS Visio . Сложные экранные формы, впрочем, до сих пор удобнее просто рисовать на бумаге, собственно согласование интерфейсных форм с врачами-заказчиками происходит именно на бумаге, причем рисунок желаемых документов выглядит слишком уж абстрактно. Поэтому согласование, как и сама разработка интерфейса, тоже носит итерационный характер.

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

• 1.    Какая информация необходима пользователю для решения задачи?

• 2.    Какую информацию пользователь может игнорировать (не учитывать)?

• 3.    Совместно с пользователем разделить всю информацию на сигнальную, отображаемую, редактируемую, поисковую и результирующую.

• 4.    Какие решения пользователю необходимо принимать в процессе работы с программой?

• 5.    Может ли пользователь совершать несколько различных действий (решать несколько задач) одновременно?

• 6.    Какие типовые операции использует пользователь при решении задачи?

• 7.    Что произойдет, если пользователь будет действовать не по предписанному алгоритму, пропуская те или иные шаги или обходя их?

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

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

• •    ясности и четкости понимания пользовате-

• лем текстов и значения икон. В программе должны быть те слова и графические образы, которые пользователь знает или обязан знать по характеру его работы или занимаемой должности. (Ни в коем случае нельзя употреблять компьютерный жаргон. Любые незнакомые слова, непонятные надписи воспринимаются просто как пустое место. Язык интефейса - русский. Даже врачи с большим неудовольствием воспринимают, пусть минимальные, вставки на любых других языках, кроме родного. Средний медперсонал - сестры, лаборанты - воспринимают все только на русском языке. Исключение составляют термины и обозначения - аббревиатуры и медтермины - на латыни. Врачи их понимают свободно, но средний персонал в них путается;

• •    быстроты обучения при работе с программой, для чего необходимо использовать преимущественно стандартные элементы взаимодействия, их традиционное или общепринятое их расположение. (Есть большие трудности с освоением многооконных окружений. Если окно попало за край экрана, или свернуто, или перекрыто другим окном, то ситуация для многих медиков становится тупиковой. Идеальная среда - как можно ближе к экрану телевизора: одна «картинка» на весь экран, плюс справа (слева, снизу, сверху) - один (и только один) ряд кнопок - переключателей каналов. Очень плохо воспринимаются любые надписи в заголовках окон. Информация в них практически всегда игнорируется. Общая тенденция: то, чего не видно на экране, не существует);

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

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

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

• 1.    Учет особенностей устройств ввода/выво-да информации, используемых пользователем, например:

• •    размер экрана монитора;

• •    разрешение экрана;

• •    цветовая палитра;

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

• •    вид мыши (с роликом или без);

• •    тип клавиатуры (прямая, косая);

• •    необходимость дополнительного оборудования (штрих-декодера, светового пера сенсорного экрана и др.).

• 2.    Разработка средств ориентации и навигации:

• •    легкость определения своего местонахождения и указание направления следования;

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

• •    быстрый поиск в списке или таблице;

• •    указание на дополнительно существующую информацию и способ ее получения;

• •    использование средств листания и прокрутки.

• 3.    Создание форм для ввода данных:

• •    использование одного или нескольких механизмов ввода в рамках режима (клавиатура, мышь, штрих-декодер, световое перо и др.);

• •    определение способов ввода данных (таблицы, списки, простая форма, меню и пр.);

• •    минимизация объема ввода;

• •    выделение редактируемых обязательных и необязательных, а также нередактируемых полей;

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

• •    выделение введенной или отредактированной информации.

Принципы реализации пользовательского интерфейса должны учитывать нижеследующие свойства [4].

• 1.    Стилевая гибкость:

  – возможность использовать различные интерфейсы с одним и тем же приложением, на практике реализуется в виде набора “skins”, для web-интерфейсов – с помощью таблицы стилей, в том числе возможность в выборе пользователем собственных установок (цвет, иконы, подсказки и пр.).

• 2.    Совместное наращивание функциональности:

  – возможность развивать приложение в рамках существующего интерфейса.

• 3.    Масштабируемость:

  – возможность легко настраивать и расширять как интерфейс, так и само приложение при увели-

• чении числа пользователей, рабочих мест, объема и характеристик данных.

• 4.    Адаптивность к действиям пользователя:

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

• 5.    Независимость в ресурсах:

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

• 6.    Переносимость:

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

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

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

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

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

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

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

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

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

С другой стороны, подавляющее большинство государственных медучреждений либо не автоматизировано совсем, либо они практикуют частичную автоматизацию, хотя в России каталогизировано 700 с лишним разработок и информационных ресурсов медицинского назначения 280-ти российских организаций-разработчиков (программные средства, аппаратно-программные комплексы, базы данных), публикуемых в «Медицинских информационных технологиях» (МИТ) [5].