|
ЗАЧЕМ И КАК |
|
Выпуск 299 18 сентября 2012 г. Заметки несостоявшегося постановщика задач. НА ЧТО ОПЕРЕТЬСЯ РАЗРАБОТЧИКУ МИС? В самом деле, на что ему опереться? Обычное предпроектное обследование даст представление о структуре лечебного учреждения, об используемых документах, отчётах, но не о сути информационных процессов, не о задачах, целях, способах их достижения, не о препятствиях и путях их преодоления. Самое, казалось бы, простое - вглядеться и расспросить. Но это не даёт результата. В медицинской практике действуют традиции, неписаные правила. Основанные на научном знании, здравом смысле и практическом опыте, они всё же остаются неформализованными, они как бы сами собой разумеются. Для врачей, но не для разработчика МИС. Накапливается медицинская информация, принимаются решения, корригируется их выполнение, отслеживаются результаты, врачи взаимодействуют между собою по горизонтали и вертикали, выявляются, анализируются и мотаются на ус промахи, возникают и расшиваются "узкие места", противоречия, несогласованности, - для стороннего наблюдателя весь этот производственный процесс проявляется только всплесками на поверхности. Ими и остаётся руководствоваться разработчику. * Что же там, на поверхности? Что видно любому? Перегруженность врача бумагами. Документооборот. Очереди в поликлиниках. Удалённость множества поселений от медицинских центров. Созданное сегодняшними СМИ отрицательное общественное мнение о врачах, об их недобросовестности. Всё. Значит, разработчик по этим направлениям и действует, а между тем, ни одно из них не обещает успеха в главном - в улучшении медицинской помощи населению. Кто спорит, хорошо отдать бумажные дела технике, однако совсем не очевидно, что тогда работа врача улучшится: бумаги - вовсе не единственная его беда. Да и чиновники, обнаруживая, что часть бумаг можно получать автоматически, тут же наращивают число отчётных и учётных форм. Не очень-то получается разгрузка. Документооборот в медицинском учреждении так бросается в глаза, что за основу иных МИС взяты бухгалтерские программы. Наверное, с документооборотом там полный порядок, но откуда в этих системах взяться медицине? С электронной регистратурой и телемедициной всё ясно, эти новшества сродни телемостам и заказам билетов через Интернет. Они потому и понятны, что не медицина это, а околомедицинский сервис, типовой по сути, специализированный только по форме. Не проблема для программиста и требования чиновников. Но какая же это основа для системы, если требования меняются вместе с министрами и начальниками департаментов министерства, а те и другие в своих креслах не засиживаются? Кроме того, это, главным образом, требования примитивного и формального контроля. За частотой дневниковых записей, за соответствием диагноза профилю госпитального отделения, за длительностью лечения, количеством приёмов в поликлинике, финансовыми затратами. За выполнением стандартов обследования и лечения, неведомо кем составленных, спорных, легко устаревающих, предложенных пока для ничтожно малого числа ситуаций. Всё поверхностно и зыбко, а иного нет. Оттого и не ставит себе разработчик задачу повлиять на результаты медицинской помощи, совершенствовать её своими средствами. В лучшем случае, передаст компьютеру рутинные подсчёты, сформирует документы, откроет чиновникам новые возможности формального, без знания медицины, вмешательства в работу врачей Он ведь и видит в лечебном учреждении не больше, чем пациент, журналист и чиновник: только врача над бумагами. Между тем, для разработки МИС надо понимать, что медицинская практика - это система сложного информационного взаимодействия врачей, заведующих отделениями, главного врача и его заместителей, лабораторно-диагностической службы, консультантов. Именно в этом взаимодействии осуществляются диагностика, лечение, диспансерное обслуживание населения, квалифицированный контроль, воспитание врачей. От этого взаимодействия зависит эффективность использования медицинских ресурсов: средств диагностики, способов лечения, организационных мероприятий, кадров, денег. И инициатива врача, его творческий поиск, его способность вводить в практику то новое, что даёт медицинская наука, тоже реализуются в рамках этого взаимодействия. Если производственные процессы разработчику МИС не видны, не понятны, то он и не заботится об их информационном обеспечении. Он не осознаёт, что ЛПУ - это система управления (не администрирования, а управления в кибернетическом смысле слова). Не прилагая к своему детищу это понятие, он не ставит во главу угла интеллектуальную поддержку врача и не уделяет должного внимания руководителям лечебно-диагностического процесса. Разработчик не виноват в таком положении. Самому не увидеть, а врач и главный врач не могут рассказать, что надо сделать. Они не рассматривают свою деятельность в таком аспекте, у них не было повода и нет привычки к системному взгляду на самих себя, да и настоящих возможностей автоматизации применительно к себе они не представляют. Потому-то и нужен постановщик задач, промежуточная фигура. * Отсутствие описания лечебно-диагностического процесса легко принимается за его простоту. Вакуум заполняют личные впечатления, услышанные на ходу реплики врачей, воображение. Этим разработчик МИС и питается. "С поликлиникой будет труднее, - услышал я от программиста. - В стационаре-то я лежал, а с поликлиникой не сталкивался". При этой простодушной уверенности, что для создания МИС хватит того же, чего детям - дли игры в Айболита, стоит ли удивляться системам, в которых нет оценки результатов врачебной деятельности, их анализа, выявления проблем, где нет функций, рассчитанных на повседневные заботы заведующего отделением и главного врача? Зато может оказаться, что система способна регистрировать одежду, которую больной сдал при поступлении в стационар. Или вычисляет содержание витаминов в 100 граммах моркови. Или программист бьётся над тем, как отображать температурную кривую, хотя всё равно ничего удобнее старинного температурного листа не придумает. А то вдруг задаётся вопросом, как быть, если больному что-то нужно срочно. Да как всегда: сделать срочно и всё. Эту трогательную заботу о ненужных деталях чудесно изображает милая миниатюра Феликса Кривина "Хлястик": "Замерзнет, небось, человек, - беспокоился Хлястик. - Руки, ноги, плечи поотмораживает. За поясницу-то я спокоен, здесь я лично присутствую. А как на других участках?" * Для меня толчком к занятию информационной системой стала собственная досадная оплошность: необходимая информация о пациенте дошла до меня, руководителя клиники, с огромным (слава Богу, не фатальным) опозданием. При этом документы свидетельствовали, что все вели себя правильно, никто не был виноват, причина заключалась в несовершенстве движения и подачи информации. Именно из-за этого несовершенства, от которого зависят результаты, стал я искать, как сделать, чтобы однажды высказанная информация не пропадала, не заслонялась, а оказывалась на виду в нужном месте и в нужное время. От этого пошли мои системы, а по мере их развития - и моё понимание лечебно-диагностического процесса. То, что получилось, можно определить как имитационные модели лечебно-диагностического процесса (в трёх вариантах: для поликлиники, стационара и станции скорой медицинской помощи). Детально проработанные модели рационального поведения. Будучи инструментом повседневной работы с информацией, имитационная модель подтягивает действия врачей на тот уровень полноты, обоснованности и своевременности, который в неё вложен. А врачи, время от времени обнаруживая, что появляются новые, ещё не учтённые в системе обстоятельства, побуждают разработчика к необходимым дополнениям, к развитию модели по мере изменений в медицине и организации здравоохранения. Образуется человеко-модельный комплекс, способный к самосовершенствованию. Я уже говорил: в этом комплексе не подвергается постоянному совершенствованию только одно - техническая основа. Но разве нельзя со временем перенести тот же проект на другую платформу? Казалось бы, чего проще? Структура базы данных, все справочники, шаблоны, все экранные формы, все меню, все выходные документы, все алгоритмы, все функции лечебно-диагностического процесса, - абсолютно всё уже есть, надо только перевести это на другой язык. Техническая, переводческая задача. А вот на деле такая попытка не получилась. * Фокус в том, что действующая модель - это, по определению, целостность, единство структуры, функций и способа подачи пользователю. Технические средства поменять можно, а это отшлифованное единство затрагивать нельзя. Слишком много там взаимосвязей, отражающих жизнь. Значит, программист должен довериться тому, что уже сделано, и ограничить себя копированием. Весомым аргументом для доверия должно бы служить многолетнее функционирование системы, ну и сам автор, буквально подносящий на блюдечке все детали работающего механизма. Сделать под его присмотром новоё воплощение продукта, убедиться, что оно заработает не хуже прототипа, а затем уж развивать его, пользуясь более совершенными техническими средствами, - вот логичный порядок действий. А получилось иначе. Оказалось, когда медицинская практика уже представлена в виде совокупности структурных элементов, непреодолимо искушение добавить сюда нечто от себя. Не просто повторить всё на новой платформе, а проверить каждую деталь на необходимость, на совершенство и сразу, тут же, сделать её лучше, на свой манер.. И уже не берётся в расчёт, что все детали - рабочие, что они пригнаны друг к другу, что для усовершенствований на ходу мало мастерства программиста - нужны серьёзные поводы, понимание всей системы, знание условий её эксплуатации.. Нельзя во главу угла ставить свою "точку зрения математика" на медицинские дела или желание сделать интерфейс для врача по последнему слову общей моды, И случайными мнениями руководствоваться нельзя, даже если их обронили врачи. Творческие экспромты на этом этапе преждевременны. Они неизбежно сводятся к обеднению: то, что не понято или непривычно, принимают за лишнее и отбрасывают. А что значит убрать непонятное? Ограничить систему своим уровнем понимания, только и всего. Что значит, отказаться от непривычного? Обрубить новое, точки роста, развития, ничего более. "Но ведь всё главное сохранено", - удивляется партнёр. В том-то и дело, что разные у нас песни о главном. Не решился руководитель новой разработки взять за неизменяемую опору всю модель целиком. Не отважился признать, что и его математическому уму что-то может оказаться не сразу доступным и должно быть принято на веру. Не согласился строитель с необходимостью дисциплинированно следовать архитектурному проекту, однажды уже реализованному. Вот и всё. Что-то, конечно, получится, будет служить, будет "как у людей". Но далеко не то, на что можно было рассчитывать. * Есть три состояния деятеля: самоуверенность незнающего - убеждённость познающего - сомнения познавшего. Пока что разработчики МИС в большинстве своём находятся либо на первой ступени, либо где-то между первой и второй. Понимание медицины поверхностное, а уверенности не занимать. Этот уровень профессиональной культуры подкрепляется легкостью, с которой медицинскую систему можно сделать (и продать), не заботясь о её эффективности. При таких обстоятельствах искать и использовать настоящие точки опоры утомительно и не выгодно. |