Электронная история болезни НИИ Нейрохирургии им. акад. Н.Н. Бурденко РАМН:
концепция, разработка, внедрение

Доклад на конференции
ПРОБЛЕМЫ РАЗРАБОТКИ И ВНЕДРЕНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ В ЗДРАВООХРАНЕНИИ И ОМС,
Красноярск, 19-21 декабря 2000 г.

Введение

Разработка электронной истории болезни (ЭИБ) в НИИ Нейрохирургии - один из проектов, осуществляемых в рамках технологии MEDSET на платформе MML*Web. В данном сообщении речь пойдет об особенностях этой конкретной разработки и о проблемах, с которыми столкнулись авторы в процессе внедрения системы. Цели создания электронной истории болезни (ЭИБ) в НИИ Нейрохирургии определяются, как и в любом медицинском учреждении, необходимостью информационного сопровождения процесса лечения пациентов, а кроме того, необходимостью информационной поддержки большого объема проводимой в институте научной работы.

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

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

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

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


"Административный цикл"

В процессе разработки ЭИБ возникает естественное желание как можно быстрее предоставить пользователям максимум содержательной медицинской информации. К этому же активно подталкивают разработчиков и сами пользователи.

Однако такой подход неизбежно вступает в противоречие с основным требованием, предъявляемым к информационной системе: нужная информация в нужное время в нужном месте. Это требование влечет за собой необходимость полной идентифицируемости информации, которая невозможна без регистрации информации, относящейся к более высоким уровням дерева бизнес-процессов (пациент, посещение пациентом клиники). Регистрация этой информации требует полной реализации в системе "административного цикла": регистрация пациентов, госпитализация и выписка, движение между отделениями. Эта информация не только требуется для идентификации содержательных медицинских данных, но и используется администрацией клиники в ходе анализа ее деятельности. Таким образом, медицинские администраторы становятся одними из первых пользователей системы и начинают выдвигать свои требования к ней.

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

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


Обучение пользователей и администрирование данных

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

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

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

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

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


Импорт в систему ранее накопленных данных

В настоящее время в большинстве клиник, так или иначе, используются компьютеры. При этом хранящаяся в них информация может представлять ценность не только для человека, который ее собирал, но и для многих других. Практически при любой технологии хранения эта информация может быть импортирована в систему. Однако задача эта крайне трудоемка и ответственна. Самой главной при этом оказывается проблема идентификации пациентов. С одной стороны, во многих случаях (и, в частности, в системе регистрации поступающих пациентов, которая функционировала в НИИ Нейрохирургии с 1994 г.) данные о разных посещениях клиники одним и тем же пациентом хранятся в системе независимо друг от друга, а при импорте их необходимо связать. С другой стороны, в идентификационных данных встречаются самые разнообразные ошибки. К сожалению, никаких строгих алгоритмов решения такой задачи нам до сих пор придумать не удалось, хотя в ЭИБ НИИ Нейрохирургии уже импортированы данные о поступлениях стационарных пациентов с 1994 года (более 12000 пациентов), поликлинических пациентов - с 1997 года (более 25000 посещений) и более 1000 протоколов операций.


Заключение

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

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

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

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

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

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

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

125047, Москва, 4-я Тверская-Ямская ул., д.16.     Тел./факс: +7 (095) 250-9350.     E-Mail: info@mml.ru