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

Выпуск 153 18 декабря 2007 г. Наблюдения. Заметки. Реплики. КТО ТАКОЙ РАЗРАБОТЧИК? На 152-й выпуск этой рассылки читатель, представившийся Андреем, прислал очень содержательный отклик (см. форум http://ldp.mybb2.ru). В мою задачу не входит его комментировать, тем более, что многое я разделяю, а о том, что хотел бы оспорить или уточнить, уже не раз писал. Но одно суждение, высказанное Андреем, представляется мне многозначительным и побуждает высказаться. Речь об отношении разработчика медицинской информационной системы к своему детищу, уже внедрённому в практику. Я выразился в том смысле, что поддержка и развитие медицинской системы, включая пополнение её новым медицинским содержанием, должны осуществляться профессионально и что это способен делать исключительно разработчик, а никак не пользователь. Здесь-то Андрей мне и возразил: "Абсолютно правильно, но при чем здесь разработчик? Он, как правило, не является специалистом в узкой предметной области, а в 90-95% вообще не медик.... ". Вот-вот, вопрос в том, кто такой разработчик. Точнее, кем и каким он должен быть. Вариантов немного: либо это программист, познакомившийся с практической медициной, либо врач, научившийся программировать, либо коллектив, в котором сотрудничают врачи и программисты. Начнём с последнего. Но сначала подчеркнём, что при любом варианте важнейшая забота разработчика - определить назначение программного продукта, его место в жизни медицинского учреждения, его функции, принципы его развития, - всё то, что относится к идеологии и методологии автоматизации медицинской деятельности. Это - основа, от неё зависят особенности программного обеспечения и правила работы с ним. В коллективе, разрабатывающем медицинскую систему, роль постановщика задач играет врач (при нескольких врачах - один ведущий), программисты эти задачи реализуют. Постановщик - миссия не для каждого. Я не о том, что ни один врач не знает всей медицины, - это восполняется консультациями со специалистами. Есть другие проблемы. Постановщик должен понимать, на что способен программист, что вообще может автоматизация. Иначе он не сумеет точно формулировать задачи, общаться с программистом на понятном ему языке логики, решать трудные вопросы совместно с ним. Иными словами, чтобы поручить сотруднику запрограммировать те или иные функции лечебно-диагностического процесса, медик должен иметь хотя бы начальное представление о программировании. Это, конечно, вполне достижимо. Сегодня многие врачи свободно обращаются с компьютером, пользуются Интернетом и даже делают для себя те или иные программы. Чаще - молодые, но не только. Есть и более сложные требования к врачу - постановщику задач. Ему необходим некоторый специфический опыт в медицине, позволяющий компетентно и предметно судить о технологии той работы, которую предстоит автоматизировать: о работе врача стационара и врача поликлиники, об их информационных связях, о функциях заведующего отделением, медсестры, старшей медсестры, главного врача и его заместителей, приёмного покоя, медстатистика. Тут уж не молодость ценится, а зрелость. Ещё важнее, что постановщик должен обладать определённым складом ума, склонностью к последовательным логическим умозаключениям, к анализу и обобщениям, к выявлению единых закономерностей в разных медицинских областях. Между тем, медики - это чаще люди с художественным типом мышления, схватывающие "картину в целом", с её индивидуальными оттенками. Им важны именно оттенки, индивидуальность, а не общность с чем-то ещё. Недаром же любой специалист убеждён, что его специальность - особая, не такая, как другие, что автоматизировать его работу с историей болезни надо вовсе не так, как у других. Психиатр не может сходу согласиться, что вся его специфика вполне укладывается в ту историю болезни, которая разработана для хирурга, кардиолога или офтальмолога. И наоборот, конечно. Конкретное и специфичное у врача на первом плане - общность, единые закономерности ему не нужны, он их и не замечает. Потому-то сплошь и рядом врачи не могут объяснить программисту, что тот должен сделать, чтобы программа удовлетворяла не только конкретной сегодняшней ситуации, но и всем ситуациям, в основе которых - та же логика, тот же алгоритм. Программисту необходима чётко изложенная закономерность, строгие правила, исключения из которых делаются тоже по правилам. Запрограммировать можно всё, для чего сформулированы правила. Постановка задач как раз и сводится к формулировке множества детальных правил. Их, эти правила, постановщик, хорошо понимающий особенности врачебного мышления, но сам склонный к предельно логичному изложению, должен извлекать из того, что врачи описывают живо, эмоционально, бессистемно и чаще всего аморфно: либо слишком общо, либо со множеством деталей, не относящихся к задаче программирования. Когда разработчик - это содружество врачей и программистов и основная очень кропотливая работа компетентного в медицине постановщика задач выполнена, то все последующие поправки, все добавления должны каждый раз тщательно выверяться на соответствие тому, что уже сделано, на их непротиворечивость, на возможность их расширенного или необходимость ограниченного, локального использования. Разве не ясно, что только разработчик, определивший идеологию и содержательную структуру системы, сможет это сделать, что в противном случае неизбежны диссонансы, повторы, снижение культуры текстов, не говоря уже о том, что разные пользователи постепенно окажутся с разными вариантами системы? Когда разработчик - врач, который сам пишет программы, положение упрощается: он ставит задачи самому себе. Если он обладает перечисленными выше качествами и занимается автоматизацией учреждения, а не только рабочего места того или иного специалиста, система в содержательном отношении будет полноценной. Но и ответственность тут велика: автоматизация целого учреждения - это вмешательство в способы получения клинических и экономических результатов. Кроме того, что годится для одного учреждения, то легко переносится и на другое. Как же можно развитие такой системы, её пополнение содержанием отдать на волю множества пользователей? Другое дело, если создаётся изолированный АРМ, "для себя", для узкого круга лиц, например для одного отделения в стационаре. Такой программный продукт преследует лишь некоторую сумму удобств для отдельного пользователя (печатать, запоминать, подсчитывать). Окружающих он не затрагивает. Его можно предложить и другим, желающим. Готов согласиться, что при таком варианте пользователям можно позволить вносить (опять-таки только для себя) дополнения в системные справочники и шаблоны, а то и пристраивать сюда собственные программы. Как говорится, хозяин - барин. При третьем варианте, когда разработчик - это программист, а врачи лишь отвечают на его вопросы, я и подавно согласен: пусть пользователи добавляют всё, что им нужно. Здесь это вынуждено. При таком способе создания системы её медицинское содержание будет заведомо несовершенным. Программист ничего с этим поделать не может. На его вопросы разные врачи отвечают по-разному и не так, как ему нужно. Его познания в медицине не позволяют относиться к этим ответам критично, не дают возможности ставить уточняющие вопросы. У него один выход - додумывать самостоятельно, в меру собственных житейских представлений о враче и медицинском учреждении. В техническом отношении программный продукт может быть блестящим, в содержательном - неизбежно ущербным. Раз это неизбежно, то ничего другого не остаётся, как сделать для пользователей подходящий инструментарий и пусть уж они сами дополняют систему всем, что сочтут нужным. Между прочим, случается и четвёртый вариант: разработчик коллективный, солидная фирма, но лидера-медика нет или он, не имея упомянутого выше специфического опыта, диктует системе лишь самые общие требования. Тщательная детализация, настоящая постановка задач поручается помощникам, а то и самим программистам. Тогда единой идеологии нет или её волей-неволей начинает формировать ведущий программист. Системы при этом задумываются и создаются глобальные, но с недостаточным учётом тонкостей лечебно-диагностического процесса. Недостаток пытаются компенсировать тем, что для дополнений, которые непременно понадобятся в будущем, набор инструментов дают пользователю. Предполагается, что о дальнейшем врачи позаботятся сами. Я в этом очень сомневаюсь, а сам подход считаю некорректным по отношению к тем, для кого всё делается. Итак, по моим представлениям, разработчик системы, предназаченной не для отдельного кабинета, а для автоматизации лечебно-диагностического процесса в учреждении, должен оставлять только за собой возможность (и обязанность) поддерживать и сопровождать своё произведение. Вы скажете, что и для больницы, и для разработчика это новая зависимость, с которой придётся считаться, которую надо обеспечивать организационно? Да, конечно. Но такая зависимость необходима для прогресса, для того, чтобы поддерживать соответствие программного продукта развивающейся медицине. Альтернатива - вольная воля, когда каждый может оставлять в системе свои следы, - разрушительна.