|
ЗАЧЕМ И КАК |
|
Выпуск 297 4 сентября 2012 г. Заметки несостоявшегося постановщика задач. В жаркой пустыне негр нашёл старинный кувшин, потёр его, и явился джинн исполнить три желания. - Хочу быть белым. Хочу вдоволь воды. Хочу много женщин. И джинн превратил негра в унитаз. Белый. В женском туалете. Между негром и джинном не было постановщика задач. НОВАЯ РОЛЬ. Хочешь, чтобы было сделано хорошо, - сделай сам. Под этим девизом мне посчастливилось прожить жизнь, в том числе многие годы, отданные разработке, развитию и поддержке медицинских информационных систем (1973-2012). Однажды интуитивно сообразив, что именно нужно медицине от автоматизации, я затем осмыслил это теоретически, а уж тогда оказалось, что сделать систему самому куда проще, чем растолковывать программистам, что от них требуется. Самостоятельное воплощение методологических решений в компьютерных программах оказалось и захватывающе интересным, и экономичным, и эффективным. Но использованная техника, не в пример методологии, быстро отстаёт от потребностей и возможностей стремительного прогресса. Довольно долго удавалось мне модернизировать свои разработки, однако ныне, когда на информатизацию здравоохранения замахиваются в масштабах региона и страны, ограниченность личных ресурсов стала очевидной. А других, не личных, у одиночки нет по определению. И всё-таки сделанное упрямо живёт. Нет-нет да и становится это кому-то интересным, а у иных программистов вызывает желание повторить всё мною сделанное современными техническими средствами. Два года назад я решился содействовать такому повторению в новом и теперь единственно возможном для себя качестве - постановщика задач. Казалось бы, моя роль упростилась: всего-то и надо сообщить программистам то, что сам представляешь исчерпывающим образом: идею, функции, формы, алгоритмы. Не тут-то было. Совсем не легко добиться результата, когда знаешь, что именно должно получиться, а делают другие. Мне удалось это лишь частично, и даже то, что получилось, оставило чувство неловкости и досады: видишь, что можно лучше, а бессилен. Впрочем, интересны не мои трудности. В новом положении я ясно увидел проблемы своих партнёров - проектировщиков и программистов. Более того, понял, что им самим эти проблемы по-настоящему не видны, не осознаются ими. Вот об этом имеет смысл рассказать. ПРОТИВОРЕЧИВЫЕ ВПЕЧАТЛЕНИЯ ОТ ДОСТИЖЕНИЙ ТЕХНИКИ. Надо понять своеобразие обстановки, которую мы сами себе выбрали, принявшись создавать новый продукт не с нуля. За прототип была взята готовая система для стационара и поликлиники, давно удовлетворяющая врачей, вошедшая в их быт. В тех двух крупных учреждениях, где планировалась (и уже осуществлена) замена этой системы на новую, побудительным мотивом было не желание пользователей что-нибудь улучшить, а собственные представления разработчиков о назревающих требованиях к защите персональных данных и о перспективе единого информационного пространства здравоохранения. Такая ситуация, когда вполне приемлемое настоящее меняют на светлое будущее, вынуждала особенно тщательно сопоставлять старое и новое. Из старого (Visual FoxPro) надо было перенять всё эффективное, а новое (платформа Oracle и Web-технологии) предстояло использовать с учётом не сегодняшнего, а завтрашнего дня. Тут и обнаружилось, что новшества не только решают проблемы, но и создают их. Три группы радикальных перемен принёс переход от одной МИС к другой. Первая - это перемены, связанные с базой данных. СУБД в Oracle не только хорошо обеспечивает стабильность работы системы, но и позволяет уже на уровне базы осуществлять ряд функций. Это упрощает программный код. Если иметь в виду масштабы региона, немаловажно фактическое отсутствие ограничений на размеры дисковой памяти. Далее, здесь легко реализуются дифференцированные права доступа к данным и использование электронной цифровой подписи. Наконец, в сравнении с распределённой базой данных централизованная база и единая для всех врачей история болезни существенно упрощают программирование: не надо заботиться о дубликатах, о передаче истории из одного отделения в другое, о передаче информации из отделений в центральную базу и проч. Но есть оборотная сторона централизации. Во-первых, система всегда имеет дело со всеми историями болезни ЛПУ, а потому при работе врача с одним отделением или одним участком необходима постоянная фильтрация данных. Это - затраты времени, и в сравнении с тем, что было, они ощутиыы. Во-вторых, появилась новая задача: из единой истории болезни надо выделять работу разных отделений (в стационаре) и разных специалистов и участкового врача (в поликлинике). Конечно, это решаемые проблемы, но они требуют от программиста понимания и специальных усилий. Вторая группа перемен связана с применением Web-технологий. Интерфейс приближается к тому, что привычно для современного человека, уже не мыслящего себя без Интернета. Такие новшества, как удалённая связь через Интернет, использование планшетов и проч., привлекательны, а главное - открывают особые перспективы для эксплуатации системы в масштабе региона. Но в связи с новым интерфейсом можно указать и на некоторые потери для врача. Желание использовать сенсорный экран (планшеты, телефоны) приводит к увеличению межстрочных промежутков, а это уменьшает ёмкость экрана. Нагруженную экранную форму приходится разбивать на две, а то и на три. Сведена к минимуму возможность работать клавишами курсора, не используются "горячие" клавиши, функциональные клавиши и клавиша ESC, - практически всё заменено мышкой. Из-за этого ряд операций стал менее эргономичным. Там, например, где для выхода из нескольких последовательных экранных форм достаточно было, не отрывая пальца и не глядя, нажимать подряд ESC (а для целеустремлённого входа - ENTER), теперь надо при каждом щелчке позаботиться о нужном положении мышки. Вообще, там, где врач легко приобретал рефлексы и работал машинально, сейчас приходится вглядываться. Когда из таких действий состоит вся канва работы в системе, это далеко не пустяк. Наконец, третьея группа перемен касается взаимодействия пользователей с разработчиком. Одним из мотивов нашей затеи было желание покончить с зависимостью ЛПУ от одного человека. Ведь кажется бесспорным, что гарантировать сопровождение системы должна организация, а не одиночка. Но и здесь есть оборотная сторона: и одиночки имеют преимущества, и организации - не без принципиальных изъянов. Сравнивая с Visual FoxPro, я не мог не отметить ту простоту, с которой там осуществляются поддержка и развитие систем. Безупречная и чуть ли не круглосуточная связь системных администраторов и руководителей больниц с разработчиком по электронной почте, легкость внесения дополнений и в справочники, и в программный код, и даже в структуру базы данных, простота передачи и установки новых версий программы (устанавливает их системный администратор), - всё это позволяет решать текущие проблемы без проволочек. Справочники пополняются в день запроса или назавтра, добавление новых функций осуществляется в пределах 2-3 дней, редко больше. В новых условиях всё это не так. Запрос пользователя проходит через цепочку сотрудников компании: одни принимают, другие реализуют, третьи доводят результат до лечебного учреждения. Рассогласования и потери времени тут неизбежны. Тем более, что обновления должны подчиняться графику, то есть делаются не в любой момент. А есть ещё и спорные вопросы, которые пользователю приходится обсуждать с разработчиком, - так ведь надо ещё понять, какой вопрос с кем решать. Результат - отсроченная реакция на запросы пользователей, а это означает, что у них будет слабеть желание лишний раз сделать свои предложения. Между тем, совершенствование моей системы на протяжении многих лет было обязано именно активности пользователей, а она поддерживалась быстрой реакцией со стороны разработчика. Чтобы при переходе к новой системе зависимость от одного человека на сменилась зависимостью от нескольких человек, нужна чёткая организация работы компании-разработчика с взаимозаменяемостью сотрудников, нужны строгие формы запросов пользователя, система правил, наконец, специальные технические приёмы, в частности, для пополнения справочников. Если этого нет с самого начала, врачи привыкают к недостаткам и недостатки забываются. Но они не перестают существовать и, каждый понемногу, ухудшают систему. Кто-то скажет, что, приобретая, приходится и терять, с этим надо мириться. Не хочу. Давно живу с убеждением, что программист может всё, а если чего-то не может, то в союзе с ним успешно действует хорошая организация. Значит, нельзя мириться с тем, что какие-то "мелочи" стали для врача хуже, - надо выискивать их и находить на них управу. К сожалению, слишком часто программист считает избранную им платформу идеальной, "приятной во всех отношениях", а всё, что было до того - негодным. Этот снобизм вместе с отсутствием принципиальной критики со стороны опытных медиков, вместе с уверенностью, будто в медицине разобраться может каждый, мешает видеть то полезное, что уже было сделано другими, чего не следовало бы упустить, что надо перенять. Мешает преемственности. Мой общий вывод: нет прямолинейного, безоговорочного прогресса, новые достоинства сопряжены с теми или иными потерями. Их можно предотвратить, но для этого надо специально работать, причем часто "вручную", методами того самого "прошлого века". Этого-то увлечённые прогрессом программисты и не приемлют. Настолько, что не считают потери потерями, убеждая себя, будто в старой системе те или иные удобства для врача то ли вообще отсутствовали, то ли никому не были нужны. Разубеждать их почти никогда не удаётся. Тут собака зарыта. |