ЗАЧЕМ И КАК автоматизировать лечебно-диагностический процесс

Выпуск 21 1 марта 2005 г. Рассуждение восемнадцатое ОСТАНОВИТЬСЯ, ОГЛЯНУТЬСЯ… Принципы автоматизации. Что надо знать разработчику. Что надо знать программисту. Что надо знать главному врачу. Об этапности внедрения. О новом стиле работы. Не останавливаться на достигнутом. Нужны ли стандарты автоматизации? О деталях и принципах На примере стационара я старался рассказать, как автоматизировать лечебно-диагностический процесс. Оговорюсь: речь шла не о том, как надо, а о том, как можно. Я не настаиваю на деталях, на том, что годятся именно такие, а не иные решения. Это в первых выпусках на вопрос «зачем автоматизировать» можно было отвечать категорично и даже прибегать к интонации памфлета. Там обосновывалось отрицание существующего, всем знакомого, никого не удовлетворяющего положения вещей. Не так уж это и сложно, не так ответственно: ломать – не строить. Другое дело – доказывать разумность и полезность новых, не общепринятых, а то и вовсе неизвестных способов, средств и правил. Здесь категоричность уместна лишь тогда, когда формулируешь принципы. Воплощаться же эти принципы могут по-разному. Нельзя однажды избранный способ их реализации объявлять ни единственным, ни наилучшим. Но представить широкой аудитории хотя бы один такой способ необходимо. Как иначе убедить слушателей в жизненности выдвинутых постулатов? Для практиков убедительно только воплощение идеи, только то, что можно пощупать. Без этого идея для них – пустой звук. Стало быть, всё уже изложенное – частный пример того, как можно автоматизировать лечебно-диагностический процесс. Я опирался на системы, уже созданные, функционирующие в обычных больницах. Раз они действуют, значит можно. Именно факт их функционирования позволял мне настаивать на нескольких базовых положениях. Оглянемся на них ещё раз. За основу автоматизации надо брать электронную историю болезни. Она должна вытеснить обычную историю, но при этом перенять всю её суть: описание пациента, суждений и действий врача, результатов обследования и лечения, возникающих организационных проблем, вмешательств руководителей. Бережное сохранение этого содержания, уточнение понятий и формализация подавляющего большинства сведений должны вернуть истории болезни её изначальную роль полноценного первичного носителя информации. Это не революция. Здесь нет разрушений «до основанья», здесь не отрицается содержание. Наоборот, именно для него создаются новые формы, соответствующие современному объёму медицинских знаний и усложнившейся структуре современного лечебного учреждения. Когда форма приводится в соответствие с содержанием, радикально меняется использование истории болезни. Она становится системообразующим элементом. На ней и только на ней можно теперь строить всё информационное обеспечение участников лечебно-диагностического процесса. Это напрашивается само собой. Средства автоматизации должны сделать такое обеспечение надёжным, полным, своевременным и нетрудоёмким. Cледовательно, из автоматизации ведения истории болезни вытекает необходимость автоматизации способов хранения, обработки и передачи информации, создание информационной системы, охватывающей всё учреждение. Когда звенья одной цепи – врач с его больными, заведующий отделением с его опытом и знаниями, главный врач с его ресурсами и правами, медсёстры, медицинские статистики, вспомогательные подразделения, эксперты – связываются регулярными потоками полноценной информации, вся информационная система приобретает черты технологического процесса. В нём каждая операция всегда выполняется одним и тем же способом, в нём чётко распределены функции и ответственность людей, в нём явно заданы или подразумеваются сроки каждого действия, и они не могут не соблюдаться ввиду взаимозависимости участников. В условиях чёткой технологии резко возрастает информированность лиц, принимающих решения, – лечащих врачей и руководителей. Тем обоснованнее, тем эффективнее могут быть эти решения. Тем выше ответственность тех, кто их принимает или не принимает. Чтобы успешно использовать непрерывные потоки ценнейшей информации, тоже нужны новые средства. Эти средства – целенаправленная автоматизированная обработка данных и специальные организационные приёмы, часть которых – это аналоги прежних способов управления, а часть отличается полной новизной. Обоснованность и предметность управления, в свою очередь, позволяют следить за самим управлением, за эффективностью принятых решений. Для этого тоже надо создать и специальные технические средства, и, сверх того, методологию управления в условиях автоматизации. Так программное обеспечение лечебно-диагностического процесса вызывает к жизни изменения в его организации, делает необходимым обновить его организационное обеспечение. Всё это означает, что на основе электронной истории болезни логично возникает не просто информационная система, а система управления лечебно-диагностическим процессом. Именно это, в конечном счёте, должны обнаружить в автоматизации врач, заведующий отделением и главный врач. Разработчик же изначально должен ставить себе именно такую конечную цель. О разработчике и программисте Остановимся на последнем утверждении. Разработчик должен всю полноту задачи видеть с самого начала. Тогда каждая готовая к эксплуатации программа станет фрагментом будущей единой системы, ещё одним шагом к полноте всей конструкции. Ключ к этому – электронная история, формализация её содержания. Надо всё время иметь в виду, что любой реквизит истории болезни надобен не только для фиксации и воспроизведения сведений о пациенте и враче. Он используется для обмена информацией между многими пользователями. Он потребуется для систематизации сведений о больных, для сопоставления с другими данными, для обобщений, для поиска причин и следствий, для нынешних и будущих официальных отчётов. Ничего не значит, что он не используется так сегодня. Он понадобится завтра, когда с новыми возможностями обработки данных возникнут и новые потребности. Эти потребности разработчику надо предвидеть. Я всё время сознательно заменяю «программиста» «разработчиком». Разработчик – архитектор. Он обязан видеть всё строение, все его будущие функции. А уж если речь идёт, как в нашем случае, не о новом здании, а о перестройке старого, да ещё о такой, при которой назначение здания остаётся прежним, разработчик должен хорошо представлять себе жизнь обитателей, которую он хочет улучшить. Мало того, здание надо строить с учётом, что эта жизнь меняется и через некоторое время потребуются пристройки и надстройки. Надо прогнозировать, где именно возникнет такая необходимость. Значит, разработчиком может быть опытный медик. Но тогда он должен понимать, что такое автоматизация, что может программирование, как с его помощью решаются конкретные задачи. Без этого он не сможет ставить задачи программисту, не будет ему собеседником, не сможет оценить, насколько хорошо выполнена каждая поставленная им задача. Конечно, и программисту не возбраняется стать разработчиком, но тогда уже ему необходим достаточный опыт общения с медиками, опыт наблюдения за их работой: в ординаторской, на обходе, на посту у медсестры, в кабинете главного врача, в кабинете медицинской статистики. В чистом же виде программист – строитель. Если он берёт на себя функции архитектора, здание окажется неудобным для его жителей, недостаточно функциональным. Но и при хорошем архитекторе программист должен понимать, на кого работает. Программы здесь предназначены для массового пользователя. Этот пользователь может быть вообще не знаком с компьютером. Ему часто свойствен не строго логичный, а художественный способ мышления, не порядок, а полёт воображения. Наконец, работа за компьютером для врача вовсе не главная деятельность. Главная – пациенты. Это надо безусловно уважать и брать в расчёт. Для врача компьютер - только один из инструментов. И не самый важный. Интересоваться им надо ничуть не больше, чем устройством авторучки (тоже, между прочим, хитрая штука!). Набираться для работы с ним дополнительных знаний – извините. Программы должны работать, и всё. Как бы с ними ни обращались. Совершенно бесполезно призывать врачей соблюдать те или иные специальные правила – надо защититься от нарушения таких правил программно. Лишь одно можно требовать безусловно: читать то, что написано на экране по-русски. Не более. Но даже этого добиться не так-то просто. Отсюда запросы к интерфейсу. Он должен быть простым, «интуитивно понятным», дружественным, без отвлекающих от дела излишеств. Отсюда требования к надёжности программ, к их самовосстановлению при возможных неприятностях. Отсюда особая забота о сохранности данных, об их защите от несанкционированных действий пользователя. Строитель должен предусмотреть, что в его здании будут жить не абсолютно дисциплинированные и всё знающие космонавты, а самые обычные и очень разные люди: не всегда аккуратные, не всегда осторожные, и даже не всегда разумные. Конечно, хороший вариант – разработчик и программист в одном лице. Но для этого надо, чтобы жизнь толкнула бывалого врача в дебри программирования. Бывает, но редко. Конечно, два образования в наше время – явление обычное. Но загвоздка не только в образовании – надо иметь в обеих областях достаточный практический опыт. А вот это - поискать. О руководителях Нужно ли руководителям, подумывающим об автоматизации, заранее представлять себе всю глубину и масштабность задачи? Сомневаюсь. Может быть, это полезно: ученье – свет. Но жизнь руководителей больниц и отделений так сложна, что в начале пути им свойственно естественное желание, прежде всего, удовлетворить сиюминутные потребности, а не осознавать все будущие перемены, которые последуют за первыми шагами. Избавиться бы от писанины, от отчётов и расчётов, использовать бы компьютеры («как у людей»). А там будет видно. Пусть так. Вряд ли тут уместно навязчивое просветительство, вряд ли оно будет успешным, если почва для него не подготовлена. С другой стороны, ведь именно здесь – лазейка для внесистемных, фрагментарных программистских решений, упрощённых поделок, а то и совсем уж странных вариантов вроде предложения приспособить для врача пакеты бухгалтерских программ. Надо же предостерегать главных врачей от такого пути, ведущего в тупик. Выходит, уклоняться от разговоров о системности нельзя. Но если уж объяснять главному врачу необходимость системной автоматизации, то тут же надо подчёркивать возможность поэтапного решения задачи, иначе она покажется ему просто неподъёмной. А этапность возможна. Можно вначале ввести электронную историю не во всех отделениях, а только в некоторых из них, добавив к этому сбор информации из этих отделений на компьютере медстатистиков и компьютере главного врача. Можно отложить на потом установку сети, можно постепенно включать в сеть отделение за отделением. Точно так же на последующие этапы можно отнести автоматизацию приёмного покоя, лабораторий и диагностических кабинетов, регистрации и обработки больничных листов. Даже при наличии всех материальных ресурсов такая этапность всё равно необходима по организационным и психологическим соображениям. Весь вопрос в величине интервалов между этапами. Когда речь об отделениях, интервалы, конечно, не должны вырастать до многих месяцев, а в остальных случаях они могут быть любыми. Руководитель должен знать, что системность автоматизации – это не одномоментность, не одновременность ввода программ в эксплуатацию, что многое можно разумно спланировать, распределить во времени, а кое-что вообще отложить до лучших времён. Всё это не сложно объяснить. Всё это вполне нормально воспринимается. Сложности в другом. Они в том, что с вводом в практику электронной истории болезни руководители должны изменить свои привычки. Те самые люди, которые волевым решением ввели автоматизацию, теперь должны запретить себе волевые решения. Им предстоит научиться управлять на основе информации, а не интуиции. Запретят, научатся – откроют для себя новые возможности улучшения медицинской помощи и экономических результатов. Не научатся - будут управлять в прежнем стиле, и правило «Кто владеет информацией, тот владеет ситуацией» останется пустой фразой. О новом стиле работы Не так-то просто заведующему отделением и особенно главному врачу осознать, что автоматизация, основанная на электронной истории болезни, требует нового стиля управления, создаёт его. Новый стиль – это уверенность, что ничто не будет забыто. Не надо спрашивать – обо всём уже есть информация. Не надо вмешиваться, если нет тревожных сигналов. Новый стиль – это автоматическая сортировка ежедневных проблем по их важности и безотлагательное решение самых важных из них. Это отсеивание случайностей и воздействие только на закономерности. Это слежение за проблемами в динамике, сравнительная оценка врачей, обоснованный статистикой выбор объекта управления и момента, когда надо вмешаться. Это персонификация результатов и оценка эффективности самих управляющих воздействий. Это спокойная, методичная, аналитическая работа. При управлении на основе информации, при управлении по отклонениям от должного теряют смысл многие совещания, комиссии, общие объявления, наставления и напоминания. Их место занимают обоснованные точные указания руководителя конкретным работникам, а когда конкретных причин для таких указаний нет, то и замечательно: пусть люди спокойно работают, пусть забудут о руководителе. Нелегко перейти на такой стиль. Помимо силы привычек, руководитель – всегда немного актёр. Он работает на свою публику. А тут обедняется его репертуар, изменяются условия самовыражения. Надо наступать на горло собственной песне. То обстоятельство, что пусть редкие, но всегда точные и обоснованные вмешательства на самом деле повышают авторитет руководителя, осознаётся не сразу. Это одна из причин, по которым руководители, внедрившие у себя автоматизированную систему, сами могут долго оставаться вне её, работать не по её законам, а по своим прежним привычкам. Есть и другие причины. Дело в том, что автоматизация положительно сказывается на результатах работы учреждения очень рано, ещё до того, как главный врач возьмёт в свои руки новые рули управления. Эти первые эффекты обеспечены лечащими врачами, их работой с электронной историей болезни. Врачи работают, компьютеры действуют, результаты видны, в других учреждениях этого нет – чего же боле? И руководитель нередко готов этим удовлетвориться. Я наблюдал и такую ситуацию, когда главной заботой руководства было составление реестров для ТФОМС, выявление больных, за которых больнице должны платить не так, а иначе, выявление участников войны в преддверии 60-летия Победы и т.п. Обнаружив, что это возможно, начальник уже радовался и не очень-то заботился об остальном, о главном, о полном вытеснении обычной истории болезни электронной. Нет ничего зазорного в том, чтобы радоваться внешним эффектам. Тем более, когда эти эффекты – требование дня. Лишь бы не ограничиваться ими, не удовлетворяться первыми шагами на новой стезе, не останавливаться. Впрочем, рано или поздно руководители начинают понимать, как много ещё не использовано ими в новом инструментарии. Чтобы это было рано, а не поздно, требуется только одно – изучать систему, искать в ней способы решения проблем учреждения. Эти способы там есть. Нужны ли сегодня указания сверху? Если от главного врача нельзя требовать, чтобы он непременно осознавал все перспективы предстоящей автоматизации, то от руководителей органов здравоохранения – от горздрава до министерства – этого надо бы ждать. Кто, если не они, должен смотреть вперёд? И видеть будущее? Не уверен, что смотрят и видят. Вроде бы, ни в чём это не проявляется. А без этого другие сильные мира сего уже навязывают больницам автоматизацию для решения своих локальных задач. Сегодня это фонды обязательного медицинского страхования – им нужны реестры, каждому – свои, на свой манер. В самые последние недели заговорили об автоматизации выдачи рецептов льготникам. Будет, конечно, и ещё что-нибудь. Будут писаться программы для решения частных вопросов, ответы на которые надо бы брать из истории болезни, а не из дополнительных карт и талонов. Будут для этих программ поставляться компьютеры… Неразумно? Так ведь и альтернативы не существует. Да и кто её ищет, альтернативу? На этом фоне нет-нет, да и раздаются голоса то программистов, то врачей: пусть, мол, Министерство установит стандарты для автоматизации, для электронной истории, а мы уж тогда и программы писать будем, и внедрять их. Думаю, напрасно это. Не потому, что не установит Министерство стандарты, - очень даже может установить. А потому, что в качестве стандарта надо выбирать лучший вариант из многих успешно апробированных. Нет пока этих многих. Нет ни общепринятых, ни конкурирующих развёрнутых, детальных представлений об объектах и целях автоматизации. Какие стандарты, на какой основе могут быть сегодня предложены? А ведь когда они будут введены, то будут использованы, чтобы тащить и не пущать все другие разработки, со стандартом не совпадающие. Конечно, строгость российских законов умеряется вольностями в их исполнении, поиски всё равно будут продолжаться. Но ещё один способ торможения будет использован. Не время сейчас указывать бумагой сверху, как нам ходить по нашим оврагам. Сейчас время поисков, предложений, апробации их на практике, время обсуждения принципов, деталей, приёмов и – главное – практических результатов. Стоит, очень стоит практикам принять это во внимание. Не думаю, что будущее автоматизации в медицине, в первую очередь, зависит от верхов. Верхи волей-неволей питаются соками, идущими снизу, от почвы. Дело в значительно большей степени зависит от врачей и от главных врачей,от того, как формируются их собственные представления, их понимание ситуации. Именно они, в конечном счёте, будут решать, что брать на вооружение. А их убеждать можно только демонстрацией действующих объектов и подробным рассказом о том, как можно получать искомые клинические, экономические и организационные эффекты. Сегодня здесь пока целина. Надо пытаться её поднять.