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

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

Обычно требуется от 4 недель до 3 месяцев, чтобы основная волна проблем, связанных с вводом медицинской информационной системы (МИС), схлынула. Однако на этапе внедрения выявляются не все недостатки. Если к функциям прибегают редко, ошибки могут скрываться годами.

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

Причины запросов к разработчику и их значение

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

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

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

Организация запросов

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

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

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

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

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

Следует утвердить формат предоставления информации.

Виды и формы запросов

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

Об аварийных завершениях и зависаниях программы

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

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

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

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

О нелогичных действиях программы или неверном расчете

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

Об ошибках в текстах

Разработчику надо сообщить, о каком именно объекте идет речь, указать на ошибку, привести правильное написание и приложить скриншот, на котором видна ошибка. Системный администратор должен понимать, когда речь идет о системном справочнике, за который в ответе именно разработчик, а когда о местном, который составляется и корректируется в ЛПУ.

Пополнение справочников

Такие справочники, как «Сотрудники», «Подразделения», «Медицинские учреждения» и т. п., являются локальными. Остальные унифицированы, то есть являются системными. Обязанность разработчика — сделать локальные справочники удобным инструментом, а системные справочники нуждаются в постоянной поддержке.

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

Примечание. Системные справочники нуждаются в постоянной поддержке.

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

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

Так, например, эндокринологов не удовлетворяет только общая формулировка «Е23.33. Синдром пустого турецкого седла», так как этот диагноз в истории болезни надо характеризовать наличием тех или иных важных проявлений: ожирением, гиперпролактинемией и т. д. Общее число таких синдромов плюс вариант, когда у пациента есть их комбинация, десять. Отражение имеющегося состояния с помощью текстовой записи означает лишний труд и невозможность последующих выборок по важным признакам. Между тем ничто не мешает к коду E23.33 добавить десять подрубрик от E23.330 до E23.339 и пользоваться всеми преимуществами формализованной информации. Причем все эти диагнозы в официальном отчете попадут в более общую рубрику E23.33.

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

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

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

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

Справочник сигнатур. Предполагается, что ритм применения лечебного средства врач назначает с помощью отдельного справочника сигнатур. Назначение путем дописывания с клавиатуры лишает возможности программно подсчитывать количество принятых медикаментов и стоимость лечения. В этот справочник также придется вносить добавления, например «по 1/4 таблетки», «внутривенно 40 ампул в день» и т. д.

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

Справочник лабораторных и других специальных методов обследования. Требования к дополнениям тут наиболее сложны. Помимо наименования исследования, в котором не должно быть сокращений и аббревиатур (кроме общеупотребительных — ЭКГ, МРТ, УЗИ и т. п.), надо указывать группу, к которой относится исследование (клинические анализы, биохимические и т. п.). Это необходимо для удобного поиска анализа в справочнике, для различных вариантов обработки массива историй болезни: для передачи назначения врача в лабораторию или кабинет, для составления отчетов о работе лабораторий, для анализа лабораторного обеспечения лечебно-диагностического процесса.

Следует сообщить, как описывать результаты исследования в истории болезни и в лабораторном журнале — задать формат описания. Для некоторых исследований кроме полей для текстового протокола и заключения надо указывать номер по журналам лаборатории (таковы, например, анализы на реакцию Вассермана или ВИЧ). Есть исследования, результат которых выражается указанием на наличие или отсутствие факта, например «обнаружено — не обнаружено». Результаты многих серологических анализов оцениваются «крестами» или таблицей с перечнем титров, где указывается, с какого титра лабораторная реакция становится положительной. Эти условия надо учесть, задать, продемонстрировать.

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

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

Совершенствование функций, новые функции, изменения в структуре

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

Стартовые условия для эксплуатации МИС различны, а возникающие потребности зависят от субъективных устремлений и активности пользователей. Но есть категория запросов, которая определяется общими для всех внешними обстоятельствами. Например, 20 лет назад появились запросы на АРМ врачей общего профиля («семейных врачей»), после 2000 года потребовался автоматизированный учет стоимости лечения и составление реестров по ОМС и ДМС, затем — льготные рецепты, талоны дополнительной информации в поликлинике, усложнились требования к вакцинациям, ужесточился учет ВИЧ-инфицированных. Перечень можно продолжить. И конечно, менялись статистические отчеты ЛПУ. Для всего этого требовались и потребуются новые функции МИС.

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

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

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

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

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

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

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

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

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

Замечания о дизайне и интерфейсе

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

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

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

Внимания заслуживают и претензии к инструкциям, пояснениям и подсказкам на экране. Информация должна быть понятна всем, кто работает в системе: врачам, медсестрам, статистикам, администратору МИС.

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

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

Основания для отклонения запроса

Существует несколько групп ситуаций отклонения запроса пользователя.

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

Отклоняются предложения удалить что-то лишнее из системы. За такими просьбами почти всегда стоят либо старые привычки, либо отсутствие системного взгляда на ситуацию. Например, лишним могут посчитать то, что просто редко встречается.

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

Часто за замечаниями стоят старые привычки, утратившие значение в условиях автоматизации. Особенно это касается форм документов и шаблонов. Часто просят, например, заканчивать описание статуса пациента диагнозом и планом лечения, хотя это бессмысленно и даже вредно, потому что и диагнозы, и назначения врача вводятся в специальные бланки истории болезни, откуда и выводятся потом в экранные и печатные формы. Разработчику надо либо убедиться, что новые предложения обогащают содержание или совершенствуют его форму, либо их отклонить. В большинстве случаев он сам может оценить содержательность добавлений и поправок, но при необходимости может обратиться к эксперту. Решающим будет голос специалиста, который одновременно является руководителем, то есть несет ответственность за качество лечебно-диагностического процесса, включая культуру документации: заведующего отделением, заместителя главного врача по данному разделу медицины, главного врача, главного специалиста города, руководителя клинической кафедры на базе данного ЛПУ. Этим специалистам необходимо понять серьезность заботы разработчика о поддержке качества МИС.

Запрос пользователя надо удовлетворять, если он делает вклад в содержание МИС, в культуру записей, в удобство работы, в управление деятельностью учреждения, участвует в совершенствовании медпомощи. Казалось бы, верно и обратное: если ничего перечисленного в запросе нет, его надо отклонить. Но существуют ситуации, когда разработчикам приходится вносить в МИС и то, что заведомо не идет на пользу ни врачам, ни их руководителям, ни статистике. Это результат неравномерности информатизации здравоохранения. Ушедшие вперед ЛПУ уже решают информационные задачи без старых средств, а органы здравоохранения требуют предъявлять им эти средства по привычке. И разработчику приходится формировать ненужные больнице талоны амбулаторного пациента, карты, журналы учета, чтобы медикам не пришлось делать это вручную. Но следует помнить, что с течением времени такие функции станут балластом. Определим их:

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

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

Передача запросов разработчику

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

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