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

Выпуск 143 2 октября 2007 г. Как оценивать автоматизацию. КАК ПОДДЕРЖИВАЕТСЯ СООТВЕТСТВИЕ СИСТЕМЫ РАЗВИВАЮЩЕЙСЯ МЕДИЦИНЕ? Медицинская информационная система не может быть сделана раз навсегда. Пользователи, осваиваясь с ней, входят во вкус и требуют добавок и поправок, о которых раньше никто не помышлял. Но даже если разработчик предусмотрел почти всё, учреждение развивается и у него появляются новые запросы. Их, правда, ещё можно предугадать. Но прогрессирует сама медицина, меняется организация здравоохранения, а тут уж прогнозы невозможны. Тут никто не знает будущих потребностей. Значит, автоматизированная медицинская система должна быть способной к развитию. Впрочем, если вам скажут, что модифицировать и развивать систему по своему усмотрению может пользователь, это скверно. Ничего гибельнее нельзя придумать в отношении программного продукта, предназначенного для коллективного использования с разнообразным, но вполне определённым набором целей. Вмешательство активных умельцев приведёт и к дезориентации системы, и к тому, что разные учреждения, освоившие, казалось бы, один и тот же продукт, очень скоро перестанут понимать друг друга. Запрет на вмешательство со стороны пользователя в программный код и системные справочники, - первое и непременное условие нормального развития медицинской информационной системы. Развивать систему должен сам разработчик. Только он может и должен проверять новые запросы пользователя на обоснованность, качество, непротиворечивость и на соответствие тому, что уже сделано. В ходе таких проверок ему приходится обращаться и к нормативным медицинским документам, и к специалистам-медикам, и к постановщикам прежних задач. Это очень ответственная миссия, и пользователь должен быть уверен не только в готовности разработчика развивать систему, но и в том, что всё будет делаться последовательно, осторожно, что при этом не пострадает уже накопленный информационный капитал. Чтобы составить об этом достаточное представление, надо различать несколько сосуществующих путей развития системы. Их, по крайней мере, пять: пополнение системных справочников и шаблонов, формирование новых выходных форм, создание новых функций, изменения, связанные с новой входной информацией, и, наконец, автоматизация принятия врачебных решений. Они требуют разных приёмов, разных затрат труда, разных сроков для осуществления, разной степени участия пользователя в реализации новшества. Разумеется, они могут комбинироваться друг с другом, существенно усложняя задачу. Пополнение справочников и шаблонов - дело, казалось бы, простое. Что за сложность - добавить строчки в справочник? Сложности нет - есть ответственность. Надо избежать дублирования и учесть особенности справочника - не забыть, что новый элемент следует снабдить всеми реквизитами, которые в этом справочнике предусмотрены (например, для медикамента надо указать лекарственную форму, фармакологическую группу, дозировку). Хорошо, правильно, если разработчик полагается в этом деле не на свою аккуратность, а на специальную программку, страхующую и от дублирования, и от забывчивости. Тогда сложность и ответственность сведётся к правильности наименования. Её при сомнениях надо проверять по нормативным документам, не доверяя тому, что наспех сообщил пользователь. Всё это не трудно, а потому пополнение справочников можно осуществлять немедленно. Следовательно, пользователь должен получать желаемое не позднее завтрашнего дня. Что касается шаблонных текстов, то дополнить их набор новым шаблоном тоже просто. Но новые тексты всегда нуждаются в тщательном редактировании. Их авторы склонны использовать сокращения слов, произвольную последовательность изложения, родовые окончания, которые потом врачу придётся исправлять. Шаблон должен быть составлен так, чтобы его превращение в реальный текст истории болезни достигалось преимущественно не дописыванием, а удалением лишнего. И уж конечно, надо быть начеку в отношении орфографии и пунктуации. Нельзя пускать в автоматизированную систему бескультурье - ведь оно будет тиражироваться. В целом же, это - работа простая. Новая заявка всегда может быть удовлетворена назавтра. Формирование новых выходных форм - дело посложнее. Такие формы время от времени вводит Минздрав (как правило, только ему они и нужны), но и у самих пользователей возникают новые потребности, тем более, когда они видят, с какой лёгкостью можно обрабатывать огромные массивы данных. Здесь разработчик должен получить и изображение этой формы, и недвусмысленную инструкцию о её наполнении, алгоритм обработки данных. В развитой системе запрограммировать новую таблицу или новый список - дело не долгое: всегда есть уже что-то очень похожее, такое, которое надо лишь слегка модифицировать, чтобы получить новый результат. Однако новые выходные формы требуют отладки, а это процесс не быстрый, требующий педантичности. Старое правило программистов - "один к шести" - означает, что программа, написанная за час, отлаживается за 6 часов. Так что для получения новой формы пользователю придётся подождать пару дней. Потом он ещё поглядит, что получилось, сообразит, что кое-что можно добавить или изменить, скажет об этом разработчику, и процесс повторится, потребуются следующие 2-3 дня... Ещё больше забот связано со встраиванием в систему новых функций. Здесь разработчик до того, как засесть за программирование, должен тщательно осмыслить новую функцию, понять, кому она может понадобиться ещё, а кому совсем не нужна. Недавно меня попросили лист врачебных назначений сделать так, чтобы можно было отдельно, для специального кабинета, печатать только психотропные препараты. Такой кабинет есть в составе психиатрической больницы, там и нужна подобная функция. Но сделать надо так, чтобы в отделениях другого профиля она даже не предлагалась. Другой пример: главный врач справедливо пожелал получать фамилии тех пациентов, которые находятся в больнице уже очень долго, а заодно и фамилии их врачей. Однако логика разумного управления говорит, что такая функция должна быть не только в распоряжении главного врача, но одновременно и у заведующего отделением, и у лечащих врачей, чтобы они первыми видели свои огрехи. Иными словами, создание новых функций требует от разработчика проникновения в замысел пользователя, понимания места новой функции во всей системе управления, а также известного воображения. Нередко пользователь увидев вополощение того, о чём он попросил, делает уточнения, дополнения, всё повторяется. Поэтому новая функция рождается и отлаживается в итеративном процессе, в неоднократном обмене информацией между постановщиком, который сначала не очень глубоко продумал задачу, поставил её сугубо конкретно, и разработчиком, который старается распространить полезное добавление на все сходные ситуации. Всё это обычно требует нескольких дней, а иногда даже недель. Изменения, связанные с дополнениями во входной информации, означают переделки в структуре базы данных и всегда порождают проблемы. Одно дело - то так, то иначе использовать уже имеющуюся информацию, совсем другое - находить место для новой, создавать способы её ввода и продумывать, где и как эта новая информация будет использоваться, зачем и как сопоставлять её с тем, что было до неё. Кроме того, каждое изменение во вводе данных бросается в глаза пользователям, вызывает вопросы, требует пояснений. Эти изменения могут изменять работу программы в разных её местах, они требуют отладки, длительного наблюдения, дополнительной коррекции. Тем обоснованнее должны быть соответствующие запросы. Но ещё важнее предупредить сколько-нибудь значительную потребность в них. Если необходимость дополнять структуру данных и ввод информации возникает неоднократно, это означает, что электронная история болезни и справочники системы продуманы недостаточно, информация недостаточно формализована, многое оставлено для ввода в виде произвольных текстов или вообще не учтено. Такая система и от "писанины" не очень-то избавит, и аналитическими функциями будет бедна, и к запросам на новые официальные отчётные формы будет болезненно чувствительна. Что касется сроков, которые требуются при обогащении ввода данных, то это - многие дни, потому что не только ввод надо здесь отладить. Придётся ещё модифицировать или создавать с нуля выходные формы, для которых этот ввод предназначен, а потом отлаживать каждую из них. Наконец, автоматизация принятия решений. Это ещё почти не тронутое, но самое перспективное направление в развитии медицинской системы. В работе врача можно выделить такие ситуации, которые ведут к однозначному выводу. Определённые сочетания возраста, роста, веса и пола позволяют установить степень ожирения и необходимое обследование для выявления стоящих за ожирением заболеваний. Аналогичным образом, по сочетанию введенных в историю болезни признаков определяется склонность к сосудистым тромбозам. Достаточно задать "здоровому" человеку серию определённых вопросов, чтобы установить для него степень риска ишемической болезни сердца. Если лечение пневмонии в течение недели не приводит к улучшению, надо пересмотреть и лечение, и сам диагноз. Всё это - правила, всё можно программировать, нанизывать их одно на другое, создавая тем самым алгоритмы действий врача. Сходным манером можно программировать и простейшие (но важные!) решения руководителей. Основой развития в этом направлении служат диалоговые процедуры, когда пользователю на экране задаётся вопрос и предлагаются варианты возможных ответов, а за каждым вариантом следует свой очередной вопрос со своими возможными ответами и так далее до получения логического вывода. Этим выводом может быть и диагностическое предположение, и рекомендация об определённых действиях, и автоматическое назначение дополнительных лечебных или диагностических мер. Если в системе уже есть подобные процедуры, значит программист располагает инструментами, необходимыми для автоматизации принятия решений. Тогда дело "только" за творческим сотрудничеством разработчика и пользователя. Первому предстоит хорошо усвоить, что программируется всё, что выражается чёткими правилами реакции на информацию. Второму остаётся превратить эти правила в программы и предложить их для использования. Развитие системы по этому пути означает её обогащение конкретным практическим опытом. Впитывая опыт, добытый самыми квалифицированными и толковыми врачами, автоматизированная система будет в нужный момент передавать его всем и каждому. Развитие системы предполагает, что между пользователем и разработчиком поддерживается связь. Стоит оценить особенности этой связи: что и как часто можно отправлять по электронной почте, чтобы разработчик вникал в возникшие проблемы и передавал результаты их решения. Это, конечно, обычные письма, обновлённые версии программ и средства их установки. Но желательно иметь и специальные средства обеспечения разработчика полной и точной информацией. В описаниях систем этот вопрос никак не затрагивается, поэтому обращусь к собственному опыту. Я предлагаю пользователю специальные формы запросов на пополнение справочников, возможность записать любую выходную форму в текстовый файл, который потом пересылается по почте, формирование и пересылку файлов, содержащих только одну конкретную историю болезни. Далее, можно переслать архивированную базу данных любого АРМа и весь комплект местных справочников. Наконец, в сложной развивающейся системе не удаётся совсем избежать аварийных завершений - просто потому, что тестирование никогда не охватывает всех вариантов работы программы и всех нарушений, на которые способен пользователь. Поэтому информация о причине аварийного завершения и её локализации автоматически записывается в известный пользователю файл ошибок. Он и отсылается разработчику. * О способности системы к развитию могут свидетельствовать три признака: высокая степень формализации данных, которые образуют историю болезни, тщательная разработка системных справочников и наличие хотя бы единичных диалоговых процедур. Но в дополнение к этому хорошо бы понять, как к этой задаче относится сам разработчик, настроен ли он на неё. Хорошо бы узнать, насколько он знаком с работой врача и с функционированием лечебного учреждения, какова его способность отсеивать неразумные предложения и доводить до необходимой полноты и чёткости постановку задачи, его умение представить роль нового элемента во всей уже работающей конструкции. Конечно, чужая душа - потёмки. Но кое-что о душе разработчика можно узнать, поинтересовавшись сроками и условиями, которыми он оговаривает удовлетворение типичных дополнителных запросов пользователя, а также средствами связи, которые он для этого предлагает.