|
ЗАЧЕМ И КАК |
|
Выпуск 114 13 марта 2007 г. Советы непрофессионала
МИНИМУМ НАЧАЛЬНЫХ ТРЕБОВАНИЙ Поначалу надо ограничиться минимальными, абсолютно обязательными требованиями - только это хотел я сказать в выпуске от 6 марта (кстати, извиняюсь за свою оплошность: конечно же, это был 113-й выпуск, а не 112-й). Совет кажется мне настолько важным, что не грех к нему вернуться для уточнений, тем более, что я получил несколько критических замечаний от двух читателей. Один - разработчик медицинских систем из Саратова, Андрей Геннадьевич Коршунов, другой - клинический ординатор из Санкт-Петербурга, попросивший его не называть, так что обозначу его как NN. Присланные замечания нельзя оставить без обсуждения хотя бы потому, что формулировать требования к медицинским системам надо с большой ответственностью. И затрагивающие эту тему специалисты, и неспециалисты (а они высказываются особенно охотно и категорично) располагают разным опытом, разными знаниями, имеют разные убеждения, а то и предубеждения. Между тем, их дискуссии наблюдает аудитория, состоящая из потенциальных пользователей, большинство которых пока ещё самостоятельно разобраться в проблеме не может. Такую аудиторию надо правильно ориентировать. Её можно и дезориентировать.
Итак, обращусь к тем проблемам, которые затронули мои корреспонденты. Буду цитировать их суждения и высказывать свои. Вполне допускаю, что смогу убедить далеко не всех. Это не так уж существенно. Главное - ясно изложить свою позицию.
О тщательной разработке электронной истории болезни.
А.Г.Коршунов.
"На этом этапе должна быть спроектирована максимальная гибкость системы".
Тут надо уточнить, что понимается под гибкостью. Я ведь утверждал, что история болезни - фундамент всей системы, нулевой цикл, а "фундамент" и "гибкость" не созвучны.
На мой взгляд, обязательна такая конструкция истории болезни, которая наперёд обеспечивает весь спектр возможных запросов пользователя в любой специальности. Нужны изначально полнота деталей и тщательная их формализация, чтобы они были доступны и порознь, и в любых комбинациях при формировании списков и таблиц. Но это не гибкость, а, наоборот, жёсткость, строгая и раз навсегда установленная структура. Именно она позволяет всей системе быть готовой к решению любых задач, включая задачи разработчика - добавление новых функций.
Если Андрей Геннадьевич имеет в виду то же самое, то надо бы отказаться от термина "гибкость". Если же под гибкостью понимается возможность для пользователя что-то менять в самой истории, изгибать её тем или иным манером, то с этим согласиться невозможно. Перестраивать фундамент нельзя.
Кто-нибудь скажет, что всё предусмотреть невозможно. Почему же? История болезни - это набор социальных и медицинских сведений о пациенте и набор типов врачебных действий (поступление, описание, лечение, операции, дневники и проч.). То и другое не беспредельно. Всё можно перечислить исчерпывающим образом. Значит, в электронной истории болезни можно для всего заране приготовить место.
О развитии программ.
А.Г.Коршунов: "Чаще возникает необходимость дополнительных выходных форм, дополнительных полей в справочниках и таблицах. Надо, чтобы квалифицированный(!!!) пользователь (он может быть один на всю больницу) мог бы без помощи программиста решать эти проблемы сам. Если такого пользователя нет, то необходима поддержка программного обеспечения. По крайней мере, наличие такого инструментария в системе всячесски приветствуется".
Такой инструментарий - да. А против остального возражаю. Никакой пользователь не должен иметь возможности менять структуру справочников и таблиц. Никакой пользователь не должен иметь возможности делать дополнительные выходные формы.
Сам Андрей Геннадьевич подчёркивает, что дополнения можно разрешить только квалифицированному пользователю. Но кто и как установит его квалификацию? И если он - один на всю больницу, то кто и как сможет его поправить, удержать, умерить избыточный пыл? Кто докажет ему, что новую потребность удовлетворить можно, если он будет утверждать обратное? Что всё можно сделать быстро, если он будет тянуть канитель?
Ещё важнее другое: если каждое учреждение будет дополнять систему по-своему, то некоторое время спустя возникнут существенные различия между учреждениями, использующими одну и ту же разработку. Вместо необходимого информационного единства появятся разночтения. Куда же это годится?
Нет уж, дополнения - это исключительно функция поддержки со стороны разработчика. А инструментарий для этого пусть у него будет, это важно. Вы скажете, что пользователя тяготит зависимость от разработчика? Так ведь зависимость от технических усовершенствований - непременная плата за прогресс. Разумеется, надо постараться её уменьшить, это уж дело программиста. Пусть он с самого начала оснащает программу достаточным набором выходных форм, чтобы добавлять к нему приходилось лишь те новшества, которые время от времени вводят официальные инстанции.
О штатных технических службах в медицинских учреждениях.
Врач NN: "Считаю необходимым создание штатных технических служб в медицинских учреждениях. Эти службы могут быть представлены как одним специалистом, так и целым отделом... Деятельность этих служб должны координировать специальные представители головной медицинской организации... и главный координатор в высших эшелонах власти"
Вот уж нет! Не только такой необходимости нет, но зачастую и возможности: речь ведь о штатах и целой новой службе. Из того, что в отдельных больницах есть вычислительные центры, вовсе не следует, будто это необходимо всегда и везде. И уж совсем неуместно поручать "высшим эшелонам власти" координацию того, чего ещё нет, что ещё надо создавать методом проб и ошибок.
За техническим состоянием компьютеров надо следить - для этого есть специалисты. Программы время от времени надо совершенствовать - для этого нужно сохранять связь с разработчиком. Вот и всё, что обязательно.
О том, что программа должна работать и без сети.
А.Г.Коршунов: "Категорически не согласен. Обмен и синхронизация через дискеты - это риск разрыва данных. Далее, само проектирование такой возможности стоит приблизительно столько, сколько сама система. Кроме того, организационно гораздо проще сразу проложить сеть и работать с сервером БД, не нужно отслеживать актуальность данных (а ведь кто-то должен это делать)".
Врач NN: "Наличие сети в любом учреждении в скором времени станет необходимостью. Передача через сеть даст возможность мгновенно получать необходимую информацию. Для небольшой сельской поликлиники сеть кажется абсурдом, но, если поликлиника связана с районной больницей и может моментально сообщить об экстренной ситуации, то сеть оправдывает свое существование и здесь. Серьезно ускорится статистическая обработка данных в регионе, стране".
Не могу согласиться ни с одним из суждений моих корреспондентов. Много лет имею дело и с сетью, и с передачей данных через дискеты (причём в крупных больницах и очень больших поликлиниках). И данные сохраняются, и никаких особых затрат не требовалось, чтобы обмениваться информацией с помощью дискет. А о том, проще ли "сразу проложить сеть", надо спросить у главных врачей. Догадайтесь, что они ответят...
Скорость передачи данных, конечно, разная. Но когда же обязательна упомянутая "мгновенная" передача?
Обычно сведения о больном передаются вместе с передачей больного с участка на участок или из отделения в отделение. Вот тогда же и сведения о нём передаются на дискете. Если это срочно, то с дискетой поработают немедленно, точно так, как в обычных условиях переносят "бумажную" историю болезни. Если же информацию надо передать только завтра, то сработает установленный в учреждении регламент работы медицинских статистиков: освобождённые от всяких подсчётов, они успевают раз в день обойти с дискетой все АРМы. Мгновения тут не существенны. Так же, как и для получения списков и отчётов.
Конечно, сеть открывает новые возможности. Самая малая из них - красота, демонстративность. Более существенная - уменьшение роли человеческого фактора в документообороте. Самая значительная - новый уровень осведомлённости главного врача о положении дел в каждый данный момент. Но тут другая проблема: с автоматизацией информированность главного врача резко возрастает и без сети, а он ещё не умеет этим пользоваться. Поэтому те дополнительные возможности, которые даёт сеть (а она даёт их прежде всего именно руководителям), ещё долго остаются без должного употребления. Руководителям, чтобы освоить новые информационные ресурсы, предстоит вообще изменить стиль управления больницей. Это не просто и не быстро, для большинства руководителей, воспитанных в традиционной системе, мучительно. И потому настоящий эффект сеть даёт далеко не сразу.
Повторюсь: стоит взглянуть на ситуацию глазами главного врача. Вот он решился на автоматизацию. Одно дело, если для этого надо приобрести компьютеры и программы, - ничего особенного тут нет, приобрёл - и в работу. Но если в дополнение к этому необходимо с самого начала смонитровать сеть, положение на старте резко усложняется. Объявлять такое усложнение обязательным грешно. Кроме того, надо бы учесть, что сеть, как и всё на свете, может давать сбои. Что тогда? На этот случай должен быть резервный вариант.
Я не против сети. Я за сеть. Я против того, чтобы объявлять её обязательным начальным условием. А отсюда следует, что обязательным условием разработанной системы должна быть возможность информационного обмена с помощью дискет.
О пополнении справочников.
А.Г.Коршунов: "Нужно четко различать способы обработки справочников и их ведение. Это совершенно разные вещи. Если не планируется вертикальная система (больница - раймедздрав - и т.д), можно дать какой-то набор справочников, но поддерживать и дополнять его должны привилегированные пользователи. Без этого система не жизнеспособна. Уровень, на котором находится такой пользователь должен регулироваться набором прав."
Опять нужны уточнения. Кто такой "привилегированный" пользователь? В медицинском учреждении это, по-моему, медицинский статистик. Поддержка местных справочников - это его функция. Она должна быть программно разрешена только на его компьютере.
Но какие справочники имеются в виду? Прежде всего, это справочники врачей и подразделений учреждения. Они могут быть исключительно "местными", нет нужды делать их едиными для целой территории. Затем, если учреждение автоматизировано изолированно, к ним причисляются справочники улиц, медучреждений, страховых компаний и т.п. Когда автоматизация распространится на несколько учреждений района или города, функцию их пополнения надо передать соответствующему органу здравоохранения или закрепить её за одним учреждением, которое будет признано лидером.
Но системные справочники - "Диагнозы", "Осложнения", "Медикаменты", "Лабораторные анализы", "Консультанты", "Операции" и т.д. - должны пополняться только разработчиком. Иначе - беда. Справочники начнут "обогащаться" ошибками, несуразицами, станут различаться в разных учреждениях. Понятно: чем беднее системные справочники вначале, тем чаще придётся обращаться к разработчику. Значит, они должны быть с самого начала как можно более полными. Но отдавать функцию пополнения пользователям нельзя.
Дело в том, что такие справочники - не просто перечни, а важные элементы программ. Пополняя, например, справочник медикаментов, надо (в моём варианте) дать русское наименование (для поиска), латинское наименование (для ввода в историю болезни), лекарственную форму (для связи со справочником сигнатур), дозировку (для ввода в историю и для указания стоимости). Надо по определённым правилам присвоить новой записи код.
Этого мало. Надо ещё убедиться, что запрошенный медикамент действительно отсутствует в справочнике, а сам запрос сверить с официальными источниками и именно из них переносить в систему наименования, дозировки, показания и проч. Нельзя, опасно всё это возлагать на пользователя. Да и разработчик, чтобы ничего не упустить, должен пополнять такие справочники не "вручную", а с помощью того самого инструментария, о котором упомянул Андрей Геннадьевич, то есть с помощью специальных программ, не позволяющих ни забыть, ни ошибиться.
Об этапе внедрения и затратах времени пользователем.
Врач NN: "Полностью за этапность автоматизации, которой будет заниматься не только руководитель учреждения (будто ему делать больше нечего), но и представители технической службы(я думаю, они более компетентны)".
А.Г.Коршунов: "По моему опыту, затраты времени на первоначальном этапе внедрения увеличиваются в разы. Тут самое важное, чтобы пользователь сразу понял, что это даст в дальнейшем. Иначе - саботаж в той или иной форме."
Уточним, что такое первоначальный этап. По моему опыту, это 2-4 недели. И даже в эти сроки затраты времени увеличиваются отнюдь не в разы. Вначале они вообще связаны с необходимостью внести в АРМ старую информацию, например, в стационаре заполнить электронные истории болезни на тех больных, которые в данный момент находятся в отделении, а на участке - завести истории на пациентов всех диспансерных групп. Самое важное - с самого начала не допустить дублирования, отменить "бумажную историю" и ручное составление выходных документов, включить все средства интерфейса, позволяющие экономить время на текущей работе. Иначе, действительно, будут проблемы с временем.
Что касается участия руководителя во внедрении, то как раз он-то и должен его возглавлять. Для себя ведь автоматизирует - не для дяди. Иначе он разберётся в новшествах последним. Это очень неблагоприятно отражается на всей работе.
И при чём тут технические службы? Не надо создавать ложное представление, будто необходимо специальное техническое образование, чтобы заполнить или напечатать электронную историю болезни. "Представители технической службы" легко и свободно работают в АРМе только потому, что они лишены подобных предубеждений, а вовсе не вследствие своих специальных знаний. После того, как компьютеры приготовлены к работе, эти знания нужны лишь тогда, когда возникают поломки.
О компьютерной грамотности врачей.
Врач NN: "И руководителю и рядовому врачу все чаще нужны элементарные знания в области компьютерных технологий".
Не согласен так ставить вопрос. Врачу нужно работать с историей болезни. Делать это с помощью клавиатуры и мышки - не проблема. Главному врачу надо разумно использовать появившуюся в его распоряжении новую информацию. Это сложно только потому, что в ней надо ещё сориентироваться, а заодно отказаться от волюнтаристских привычек. Но ничего больше от пользователей не требуется. Никаких специальных знаний в какой-то новой для них области им не нужно. Не надо их этим пугать. А то ведь, бывает, выдвигают условия: "сначала надо всех обучить, организовать курсы". Чему обучить? Пользоваться клавиатурой? Читать по-русски?
Грамотность надо приветствовать. Но не следует объявлять её обязательным условиям. Не надо обязывать врача учиться компьютерной грамоте. Достаточно, чтобы он был образованным врачом и культурным человеком.
О конкуренции программ.
Врач NN: "При дальнейшем развитии автоматизации возможна война электронных стандартов, что нанесет ущерб здоровью больных и пострадавших".
Вот уж нет! Конкуренция всегда на пользу потребителям. До стандартов нам ещё далеко, до войны, надеюсь, тоже.А вот различия в представлениях о том, как автоматизировать лечебно-диагностический процесс, уже есть. Это естественно и ценно. Пусть разные решения сопоставляются на глазах у тех, кто подумывает об автоматизации. Кстати, потенциальные пользователи - разные. То, что для одних хорошо и приемлемо, для других избыточно или недостаточно, а то и вообще не годится. Автоматизация нужна (будет нужна) всем. Но по-разному. Так что пусть создаётся возможность выбора. Мы же должны постараться, чтобы выбор делался осознанно, чтобы те, кто выбирают, слышали не только мнения, но и аргументы.
О компьютерах и операционной системе.
Врач NN: "Я согласен, что компьютер должен быть недорогим. Но комплектация не самая дешевая, а средняя. Например, P-III, жесткий диск не менее 50 Гбайт, хороший монитор(нужно заботится о здоровье медицинского работника!).
К сожалению, большинство фирм-производителей медицинского оборудования поддерживают компанию Майкрософт... Эта компания произвела на свет белый серию операционных систем (ОС) под названием Виндос... К её достоинствам отнесу только легкость в освоении.
Сейчас я пытаюсь освоить работу в ОС Линюкс... Система... распространяется бесплатно или за мизерную плату,... хорошо объединяется в сети, имеет надежную защиту информации и еще много различных достоинств".
Пусть у пользователя будет самый замечательный компьютер и всё остальное тоже замечательное. Но я говорю только о том, что является обязательным. И о том, что обязательным считать не надо, потому что это дезориентирует потенциального пользователя. Зачем Pentium-3, когда достаточно Pentium-2? Зачем 50 гигабайт, когда хватает трёх? Какие это сегодня мониторы угрожают здоровью? Уместно ли внушать сомнения в Windows, рассказывать о Linux, да ещё и аргументировать её бесплатностью (самое чувствительное место любого, кто хочет что-нибудь приобрести)? Что, кроме растерянности, вызовут у главных врачей эти рассуждения? Они вполне уместны среди специалистов, в дискуссиях, отрешённых от практики, но вовсе не там, где надо принимать решение о внедрении.
*
В заключение, мне остаётся выразить признательность Андрею Геннадьевичу и доктору NN. Активное отношение к проблемам, которые возникают и будут возникать в новой и важной сфере деятельности, их детальное обсуждение, устранение мнимых противоречий и чёткая формулировка действительных различий во взглядах, - всё это важно и полезно. И я благодарю своих корреспондентов за их суждения, которые, сверх всего, дали мне дополнительный повод уточнить собственные позиции.
|