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

Выпуск 67 17 января 2006 г. КАК РАЗРАБАТЫВАЮТСЯ ЧАСТНЫЕ АЛГОРИТМЫ ДЕЙСТВИЙ ВРАЧА Естественно, что врач хочет убедиться в добротности алгоритма с самого начала, ещё до его применения. Демонстрация на конкретных примерах, казалось бы, самый убедительный аргумент. Но не для всех. "Кто это сделал?" и "Как это сделано?" - обычные первоначальные вопросы. Правда, спрашивающий предполагает, что ответом будет ссылка на столичное или заграничное клиническое учреждение либо важную инстанцию, - ему нужны не аргументы, а монументы. Монументов не имеется, и автору остаётся гнуть своё: утверждать, что и мы не лыком шиты, аппелировать к логике, здравому смыслу и демонстрировать, демонстрировать. Тем не менее, резон в вопросе есть. Чтобы понять и оценить нечто, надо узнать, как это нечто создаётся. Это тем более важно, что любой алгоритм действий врача должен развиваться вместе с медициной. Методика его создания и развития должна быть известной и понятной. Разработчик алгоритма и эксперты Частный алгоритм действий врача - экспертная система. Он создаётся в диалоге разработчика с врачами-экспертами. Занятие это своеобразное и предъявляет к обеим сторонам некоторые непременные и необычные требования. И понятно: разработчику нельзя упустить ни одной существенной детали в той предметной области, где он не вполне сведущ или не сведущ вообще, а от специалиста требуется такое целостное и структурное описание его деятельности, к которому он совершенно не готов, которым никогда не занимался. Разработчику необходима способность критически воспринимать суждения эксперта, для этого надо иметь собственный опыт лечебной работы, собственное представление о реальной обстановке, в которой врачи принимают решения: о зависимостях и ограничениях, о давлении со стороны пациента и его близких, о риске, ответственности и врачебном долге. Значит, разработчиком может быть только врач. При этом он должен обладать выраженным аналитическим, а не художественным складом ума, способностью разъять конкретную ситуацию на детали и сложить из них картину заново, уметь вести целеустремлённый диалог, отличать в рассказе специалиста сведения, которые могут служить веским аргументом для принятия очередного решения, от необязательных, хотя и красочных описаний. Но и последние ему нельзя отметать - надо уяснять их роль, находить для них соответствующее место. Сверх того, разработчику должны быть близки такие программистские понятия, как условный и безусловный переход, циклы, процедура, подпрограмма. Лучший вариант, когда он сам имеет опыт программирования на языке высокого уровня. Изложенное ранее понятие "элементарная клиническая ситуация" - его основной методический приём, им надо владеть. Выслушивая собседника, разработчик сам должен решать, где завершается каждая такая ситуация, где она переходит в другие. Наконец, в ходе разработки он должен подчёркнуто занимать позицию пациента, то есть во что бы то ни стало находить чёткие решения в его пользу, не останавливаясь на суждениях типа "неизвестно", "невозможно", "не наша функция", "надо консультироваться" и т.п. Итак, врачебный опыт, аналитический тип мышления, знакомство с программированием, знание структуры алгоритма и максимализм позиции, - вот совокупность свойств, необходимых разработчику. Не всякий может быть разработчиком алгоритма. Но и не со всяким специалистом можно его разрабатывать. Здесь мало хорошего знакомства с соответствующей медицинской специальностью. Экспертом может быть только практикующий врач и притом работающий в учреждении, где алгоритм будет применяться или уже применяется: он должен понимать, что участвует в создании инструмента для себя. Чаще всего экспертами становятся заведующие отделениями, начмеды, профессора и доценты клинических кафедр. Аналитичность ума, умение строго изложить свои представления здесь тоже желательны. Однако для очень многих врачей характерен художественный тип мышления: они описывают ситуацию ярко, красочно, со множеством подробностей, а на вопрос о том, что же в этой картине главное, отвечают что важно "всё в комплексе". Это могут быть прекрасные врачи, но своё умение они не способны выразить в правилах, а потому не могут, не умеют учить других, передавать свой опыт словами, а не только личным примером. Опытный разработчик и из них вытянет эти правила, однако в моей практике пару раз пришлось отказаться от сотрудничества только из-за полной неспособности партнёра конкретно отвечать на прямые вопросы. Из сказанного следует, что при разработке алгоритма могут возникать острые ситуации: разработчик задаёт вопросы, которые специалисту подчас кажутся неуместными, либо он не знает, как на них ответить. Причина таких коллизий - в противоречии между аморфностью привычных врачебных рассуждений и строгостью создаваемой логической структуры. Специалист должен это хорошо понимать. Понимать, что его собственные знания излагаются с большей, чем он привык, чёткостью, что создаётся не шпаргалка для неучей и дураков, а точный инструмент для всех, включая его самого. Этапы разработки Понятно, что "квалификация" алгоритма не будет ниже квалификации экспертов и разработчика. Но она не может быть и выше. Кроме того, при первоначальной разработке многое можно просто упустить. Всё это не страшно: упущения быстро обнаружатся при пробной, опытной эксплуатации алгоритма, а врачи, знающие в той или иной области больше экспертов, предложат свои дополнения и исправления. Внести изменения несложно, благодаря модульной стрктуре всего сочинения. Соответственно, работа над алгоритмом осуществляется в три этапа. Первый из них - разработка первоначального варианта, который можно испытать на практике. Второй - дополнения и исправления по ходу опытной эксплуатации. Наконец, третий - это совершенствование алгоритма в соответствии с развитием медицинской науки и практики. На первом этапе, самом интенсивном и трудоёмком, действуют только разработчик и эксперт. Работа состоит из серии 1.5-2-часовых бесед. Задача разработчика - терпеливо выслушать эксперта, после чего на основе полученной информации формулировать вопросы и подбирать к ним полное множество ответов. Задача эксперта - корригировать эти формулировки, указывать на упущения, предлагать дополнительные вопросы и, главное, излагать врачебные действия, соответствующие каждому из ответов. Логичность и целеустремлённость - дело первого из них, полнота и правильность медицинских решений - забота второго. В трудных или спорных случаях привлекается ещё один эксперт или литература. Во всех случаях, когда действия врача регламентируются официально утверждёнными инструкциями, разработчик лично знакомится с этими последними. После такой встречи у разработчика остаётся стопка исписанной бумаги: номер ситуации - вопрос, ответы - вопрос, ответы - рекомендация - опять вопрос и ответы - переходы в другие ситуации, на другие листы. До завтрашней беседы ему надо с этим хорошо поработать: уточнить распределение материала по элементарным ситуациям, выбрать наиболее рациональную последовательность вопросов, проверить всё на непротиворечивость и полноту, убедиться, что в текстах нигде нет неопределённости, что фраза и каждый термин могут быть восприняты врачом только однозначно. Случается, что и эксперту приходится выполнять "домашнее задание": несмотря на всю свою компетентность, он не всегда может дать исчерпывающий ответ на тот или иной в упор заданный вопрос. Тогда возникает необходимость поработать с литературой или посоветоваться с коллегами. Таким образом, в следующей беседе сначала надо будет завершить вчерашнюю работу. Только потом можно браться за следующий фрагмент. Когда очередной фрагмент лечебно-диагностического процесса описан алгоритмически, разработчик просит эксперта задумать клинический пример и назвать ведущий симптом. Затем, руководствуясь описанием, он задаёт вопросы о состоянии пациента, на основе ответов эксперта выдаёт предлагаемые алгоритмом рекомендации. Если эксперт считает их правильными для задуманного примера, то задаются предусмотренные алгоритмом вопросы о результатах этих рекомендаций, соответственно ответам делаютсят следующие рекомендации и и.д. Когда эксперт выражает несогласие с тем или иным выводом, сделанным по алгоритму, разработчик, расспрашивая эксперта о том, как следует поступать в этом пункте, вносит исправления, и процедура проверки повторяется. Наконец, когда очередной фрагмент отлажен, разработчику предстоит ещё расположить его удобным для врача образом на перфокартах или включить в компьютерную программу. На втором этапе алгоритм вводится как обязательный способ принятия решений врачами всех рангов (крайне желательно, чтобы это относилось и к экспертам). Теперь каждый врач вправе ставить вопрос об исправлениях и дополнениях, но только на основе возникших в ходе его работы конкретных примеров, когда алгоритм не соответстует реально возникшей ситуации. Каждый такой случай обязывает разработчика внести в алгоритм изменения, учитывающие критику и предложения врачей. Изменения должны вноситься немедленно и сразу же проверяться практикой на их адекватность. С другой стороны, критика вообще, без конкретных примеров, только на основе ссылок на литературу, привычки, опыт, чужой или свой собственный, не принимается во внимание. Исключение - обнаружение бесспорных ошибок и опечаток. Поскольку у врача всегда есть право отклониться от алгоритма, надо признать, что он может это делать и не вызывая разработчика. Достаточно, чтобы в истории болезни была оставлена пометка об отклонении. Выбрать такие пометки для совершенствования алгоритма - дело техники. Но тогда уже сам разработчик должен расспрашивать лечащих врачей о причинах и последствиях отклонений. В любом случае, на этом этапе должна быть организована эффективная связь между лечащими врачами и разработчиком. Не менее важно поддерживать связь разработчика с экспертами. На втором этапе их может быть несколько, но всегда важно, чтобы среди них были и те, кто участвовал в первоначальном варианте. Разработчику надо зорко следить, чтобы исправления не перечёркивали, не заменяли, а развивали и углубляли ту врачебную мысль, которая была вложена в алгоритм первоначально. Третий этап - это вся последующая эксплуатация алгоритма. Каждый врач вправе ставить вопрос об использовании новых средств, методик и приёмов, предложенных в данном учреждении, в других учреждениях, известных из литературы. Однако каждое такое предложение должно делаться не вообще, а адресоваться к определённым ситуациям алгоритма, причем к таким, где новые приёмы и методы обещают дать дополнительный клинический, организационный или экономический эффект. Предварительное решение о внесении усовершенствований в алгоритм принимают сообща руководитель учреждения (распорядитель ресурсов), эксперт (опытный клиницист) и специалист по разработке алгоритма. Внося изменения, они должны приблизительно спрогнозировать ожидаемый эффект и сроки его появления. Улучшение результатов в эти сроки делает изменения окончательными, обычный результат позволяет включить новый метод наравне с прежними, отрицательный эффект означает необходимость возврата к прежнему варианту алгоритма. Таким образом, на третьем этапе чисто экспертный метод составления алгоритма вытесняется исследовательским процессом, поиском решений, обоснованных фактическим материалом. В этом его принципиальное отличие. Кроме того, он открыт в будущее. В идеале третий этап предполагает существование постоянного органа (медицинского совета, совета редакторов и т.п.), который играл бы роль связующего звена между наукой и практикой, с одной стороны, и алгоритмом - с другой. Правила решения споров На втором и третьем этапах разработки алгоритма, когда в дело включаются лечащие врачи и привлекаются новые эксперты, неизбежны споры. Удивительно, но факт: даже в пределах одного маленького клинического коллектива разные врачи в сходных ситуациях поступают по-разному. Когда вводится работа по алгоритму, эти различия обнаруживаются со всей неожиданностью и остротой. Теперь они становятся нетерпимыми, и надо позаботиться, чтобы споры не заводили в тупик. Чтобы тупиковых положений не возникало, надо соблюдать следующие шесть правил. Правило первое: из двух возможных способов лечения, диагностики, профилактики, тактики предпочтение отдаётся тому, который в данный момент более обоснован опубликованными данными практики и науки. Правило второе: при одинаковой обоснованности двух возможных способов, выбирается тот, который отличается меньшим риском для пациента. Правило третье: при одинаковой обоснованности и равной безопасности выбирается тот метод, который на момент разработки принят в учреждении, где алгоритм будет внедряться. Правило четвёртое: если оба обоснованных и равно безопасных метода употребляются в учреждении наравне, выбирается более доступный из них с точки зрения технической простоты, дешевизны и дефицитности. Правило пятое: если два метода равноценны, а ситуация не экстренная, то в алгоритме фиксируется возможность выбора по желанию врача. В экстренных ситуациях всегда предлагается только один метод, а другой может быть внесен в запасной вариант, который вводится руководителем при затруднениях с ресурсами. Под "методом" здесь имеются в виду и способ рассуждения, и выбор действий. Правило шестое: в спорах при разработке алгоритма не применяются термины "интуиция", "индивидуальный подход", "по показаниям", "надо взвесить", "можно думать" и т.п.; они признаются бессодержательными. Как обеспечить жизнеспособность частного алгоритма Частный алгоритм - конструкция модульная. Каждая ситуация, каждый модуль связывается с другими своими входами и выходами. Её можно заменить на аналог, имеющий тот же вход, но другую логику и другие рекомендации. Выходы из этого аналога могут быть теми же или другими. Они могут вести в иные ситуации, уже разработанные или ещё не разработанные. В последнем случае и эти новые надо будет сделать. Следовательно, алгоритм можно легко пополнять новыми знаниями. Надо лишь своевременно выявлять устаревающие или изначально несовершенные модули. Здесь надо ещё раз подчеркнуть принципиально важную деталь: привлечение даже самых квалифицированных специалистов для экспертизы уже разработанного алгоритма неэффективно, если под экспертизой понимается простое чтение. Дело в том, что каждая точка алгоритма соответствует конкретной, реальной ситуации лечебно-диагностического процесса с известной предысторией. Только поэтому рекомендации алгоритма и могут быть категоричными. Обычная же экспертиза любого медицинского текста исходит из абстракций, из общих правил, которые на деле соблюдаются вовсе не буквально, а со оговорками вроде "по показаниям", "при необходимости", "с осторожностью" и т.п. Оценивать алгоритм с таких позиций - то же, что проверять невооружённым глазом результат, обнаруженный под большим увеличением. Иначе говоря, судить о правильности алгоритма можно только в приложении к конкретному пациенту. Это важно ещё и потому, что мало получить от эксперта заключение "Так поступать нельзя!" - он должен сказать, как в точно такой ситуации надо поступать. По сути, экспертом становится каждый лечащий врач в тот момент, когда рекомендации алгоритма противоречат его представлениям о том, как поступить с пациентом. Врач должен привлечь к этому руководителя, а тот - разработчиков. Вот здесь обращение к высококвалифицированным специалистам вполне уместно, если, конечно, речь идёт о спорных поправках. Частный алгоритм живёт тогда, когда действует. Как всякая живая мысль, он проходит вполне определённые этапы существования: рождается по произволу разработчиков, проверяется, растёт и крепнет во взаимодействии с реальностью, входит в силу и долгое время работает безотказно, иногда отстаёт и, подгоняемый реальностью, подправляется. Наконец, когда в соответствующей медицинской области происходят революционные изменения, алгоритм устаревает. Но никакие изменения в науке не разрешают всё до основания - из устаревшего алгоритма рождается новый вариант, и ему предстоит такая же жизнь. Два условия необходимы для этого процесса: обязательное постоянное использование алгоритма в качестве модели, которая не описывает, а предписывает поведение врача, и периодическое взаимодействие практиков с разработчиком. Последнее требует дополнительного обсуждения. Почему нельзя обойтись без разработчиков? Почему врачи не могут совершенствовать алгоритм без посредников? Ответ прост: потому что совершенствование алгоритма, как и его первоначальная разработка, - это специфическая работа и специфическая ответственность. Для совершенствования той или иной части алгоритма надо не только уметь выстраивать дерево решений, иной раз буквально вытягивая из специалиста его знания и логику. Надо ещё хорошо представлять себе всю конструкцию алгоритма, чтобы при разработке каждой частности знать, в какое место общей структуры эту частность поместить. Надо помнить и структуру других алгоритмов, откуда можно многое заимствовать. Лечащий врач, предлагая изменения, отталкивается от конкретной ситуации (что от него и требуется). Но он не заботится и не должен заботиться о том, как эти изменения скажутся в других случаях. Это - функция разработчика. Только он может и должен проследить влияние поправки на всё множество входов и выходов исправляемого модуля, разрешить возникшие вопросы опять-таки с практиками, иногда запросить у них литературу, официальные приказы, инструкции и т.п. Наконец, именно разработчик должен соблюсти непременное правило: привлекать к поправкам тех консультантов, с которыми разрабатывался первоначальный вариант, чтобы каждый, чьи советы и знания вводятся в алгоритм, был уверен, что без его ведома его рекомендации пересматриваться не будут. Это важно не только этически, это ещё важнее по существу: нельзя заменять одну мысль другой без их столкновения, взаимодействия. Спор здесь всегда так заземлён, что в нём действительно рождается истина, а не испорченные отношения. Именно так алгоритм и становится полноценной моделью живой, многообразной, сложной врачебной практики. Итак, периодическое взаимодействие пользователей и разработчиков алгоритма необходимо. Какими узами их связать - вопрос организации. Он решится, если здравоохранение будет понимать главное: частный алгоритм - это канал для эффективной передачи достижений медицинской науки и любых официальных инструкций непосредственно на рабочее место лечащего врача, это непосредственное их воздействие на врачебную деятельность. От опосредованного - через литературу, приказы, циркуляры - оно отличается точно так, как призывы к делу от самого дела.