|
ЗАЧЕМ И КАК |
|
Выпуск 115 20 марта 2007 г. Советы непрофессионала
ЕСЛИ ИСКОМЫЙ РЕЗУЛЬТАТ ДОСТИГНУТ ДРУГИМ ПУТЁМ... ...не тем, который признан профессионалами, плохо ли это? Даже если профессионалы такой путь забраковали? По-моему, это означает одно: к результату можно придти разными путями. Пусть все они будут в нашем путеводителе. Между тем, своими рассуждениями о требованиях к автоматизации в предыдущем выпуске я опять вызвал энергичные отклики. "Не могу не прокомментировать", - говорит участвовавший в дискуссии в прошлый раз Андрей Геннадьвич Коршунов из Саратова. "Задели за живое", - вторит ему Михаил Владимирович Прокошин из Барнаула, тоже располагающий большим опытом в разработке, в аналитике, а также в руководстве ИТ-подразделением, эксплуатирующим разнообразные программные средства. Привожу их суждения (и свои комментарии - как же без них!). Ещё о гибкости системы. Андрей Геннадьевич, полемизируя со мною, рассказал, как в их системе эта гибкость, возможность приспосабливаться к меняющимся условиям закладывается в самой электронной истории болезни, в фундаменте (против чего я выступал). Цитирую. "Формирование списков и таблиц возможно как на этапе проектирования, так и на этапе внедрения и сопровождения. А вот реализация передачи объектов - основа системы. У нас все справочники ссылаются на общую таблицу объектов. Там хранятся объекты разных типов (Сотрудники, Контрагенты, Пациенты и т.д.). Каждому типу сопоставлена дополнительная таблица с данными, специфичными для объекта. Но используется идентификатор из основной таблицы. В результате все многообразие бизнес-процессов описывается набором простых действий, с помощью разработанной нами модели простого документа. В этих простых действиях указывается, кто, через кого, кому и что передал, оказал услугу и т.п. Цепочка последовательно сформированных простых документов позволяет анализировать бизнес-процесс в любом разрезе. Вот реализация этой базы и должна быть максимально гибкой. За этим стоит опыт более 10 внедрений на различных предприятиях - от бухгалтерии до крупных сельскохозяйственных производств и большого мукомольного завода, а также проработка ТЗ для медицинского НИИ". Вполне логично и доказательно. Может быть, наши позиции вовсе не так уж и различаются? Не обнаружится ли при продолжении разбора, что речь идёт лишь о разной степени развития одних и тех же принципов? Но и без продолжения почему бы не удовлетвориться тем, что результат-то в любом случае достигнут? Правда, на мой тезис, что количество сведений, которые надо заносить в истории болезни, - величина конечная и надо заранее приготовить место для всего, Андрей Геннадьевич возражает жёстко. "Категорически не согласен. Под всё мест не предусмотришь. Как только начинается сопровождение нескольких систем с немного различающимися структурами данных, возникает дикая головная боль. Здесь так, тут - чуть по-другому. Выход - единообразная структура данных у всех и возможность легкого дополнения справочников с динамической настройкой". Опять-таки дьявол в деталях. Я не имел дела с сопровождением разнородных систем, на разнородных производствах. Мой опыт скромнее - только лечебно-диагностический процесс. Вот в этой области есть и возможность, и необходимость запастись заранее всем, до чего можно додуматься по сегодняшним представлениям, чтобы потом дополнений требовалось мало и можно было бы их закрепить за разработчиком, за функцией сопровождения. Интересно, что дальше Андрей Геннадьевич соглашается, что пользователь не должен иметь возможности менять структуру таблиц, но потом уточняет свою позицию следующим образом. "А вот возможность завести новый тип объекта, сделать дополнительную ветку в классификаторе - это всегда пожалуйста. Не вижу проблем. Если структура документооборота продумана, дополнительные формы и не нужны. Получаем сначала расход с врача (в терминах нашей системы) - видим, что и кому делал врач. Получаем приход на пациента - смотрим, что и кто ему делал. Таким образом, комбинировать параметры выходных форм может любой пользователь, получая то, что ему необходимо. Специализированные формы - отчеты о деятельности ЛПУ - да, это может только разработчик. А вот повертеть данные так и сяк - это нужно и для врачей, и для экономистов, и для управленцев. Причем, чтобы могли сами. А они додумаются приблизительно через 6-7 месяцев после внедрения. Проверено на опыте. Главное, чтобы была заинтересованность)". Согласен. Любознательность пользователя надо удовлетворить, более того - её надо возбуждать. У меня для этого сделан огромный набор таблиц и списков с содержательными названиями, а кроме того - функция произвольной выборки историй болезни по задаваемым параметрам. Не говорим ли мы об одном и том же? А вот на ту же тему обстоятельное рассуждение Михаила Владимировича. "Медицинские сведения о пациенте действительно могут и должны быть четко формализованы с самого начала. Тут я поддерживаю автора рассылки. Здесь желание сделать все максимально гибко говорит о нежелании вдумываться в медицинские механизмы в надежде, что пользователи сами все под себя оптимизируют. С другой стороны, социально-экономические показатели практически не поддаются формализации без наличия гибкости. Как разработчик учтет, что в законодательстве конкретной области предусмотрена специфическая отчетность? Или горздрав запросит какую-нибудь экономическую эффективность по какому-нибудь показателю срочненько? Кроме того, разработчику самому необходимо иметь инструмент для быстрого реагирования на изменения всевозможных финансовых моментов, которые могут быть перетасованы, как и когда угодно. Вообще, подобные споры отталкиваются от методики автоматизации. А методика включает все аспекты ИТ - от первоначального желания руководителя (специалиста) что-то автоматизировать, улучшить с помощью ИНФОРМАЦИОННЫХ технологий (не обязательно компьютерных), через процесс разработки программы, ввода в нее данных, через текущую работу - до анализа сводной отчетности. Здесь взаимодействуют и противоборствуют два подхода, два участника. Первый участник - программист (в этой роли может выступать и большая компания), который недавно в медицине и не имеет особого желания глубоко вникать в предметную кухню. Его полностью ведет за собой пользователь. Таких сейчас абсолютное большинство. Это диктуется засильем "итеративных" методологий разработки программ: сделал - подумал - переделал - еще подумал - еще переделал, но первый результат должен быть как можно быстрее. Именно эта категория разработчиков ратует за абсолютную гибкость программы, когда можно все атрибуты, документы, алгоритмы переделывать на ходу. Сам выступал в подобной ипостаси, ничего не имею против во множестве случаев, но вменяемый человек понимает, что гибкость необходима чаще всего от бессилия аналитиков, которые просто не могут сразу полноценно описать всю предметную область, подлежащащую автоматизации. Кроме того, большинство автоматизируемых нынче предметных областей, по определению, требует быстро изменяемых программ, т.к., к примеру, законодательство наше может меняться каждый месяц от штрафов до поощрений за одно и то же деяние! Но базовая медицинская деятельность менее прочих областей подвержена революционным изменениям - последствия чересчур критичны. Гибкими же остаются области, которые лежат в стороне от базовых алгоритмов медицины, относятся к политико-экономической сфере. Поэтому БАЗОВУЮ медицинскую деятельность можно и даже, по моему мнению, желательно автоматизировать с помощью второго участника разработки. Этот второй - предметный аналитик (медик) с большим опытом работы в предметной области. Он ведет за собой программистов. Большинство возможных медицинских потребностей предусматривается заранее. Инструментарий, который даётся пользователям, предусматривает и то, до чего эти пользователи сами еще не добрались. Как раз этот случай относится к В.М.Тавровскому. При разработке системы упор делается на предварительное всестороннее продумывание. При компетентном подходе такой процесс дает наилучший результат, однако в нынешних технологических и экономических условиях производства программ это почти утопия. Подойти к аналогичному результату можно либо в процессе длительного кропотливого совершенствования продукта предыдущим "итеративным" путем, либо в случае, когда есть ресурсы для создания СРАЗУ ВСЕЙ системы, а это в наших реалиях проблематично, т.к. правительству не до подобных заказов. Им бы хоть с лекарствами разобраться... И вот на этих двух неумолимых борцов задумчиво смотрит пользователь-предметник, непрофессионал в ИТ. Он пытается понять, о чем же спор, и периодически примыкает то к одной, то к другой стороне, когда услышит доступные его пониманию доводы в области методологии разработок, которая касается его лишь косвенно". Ещё о квалифицированном пользователе и ИТ-персонале. Ответ Андрея Геннадьевич на эту тему меня не удовлетворил. Вот как он звучит. "Что такое квалифицированный пользователь в моём понимании? Это пользователь, которого разработчик обучил, как администрировать и настраивать систему. Кроме того, ему даны соответствующие права. При установке системы мы советуем администрации заказчика, кто из пользователей может иметь такие права, обучаем его, готовим". Такой путь, конечно, поначалу облегчает жизнь разработчику, но допускает любой произвол со стороны пользователя. Мне это кажется опасной выгодой. К суждениям же Михаила Владимировича о штатных технических службах в медицинских учреждениях мне добавть нечего. Вот они. "Часто практикуется работа по контракту: есть проблема - вызвали спеца, пришел, сделал. Конечно, при больших объемах автоматизации выгоднее иметь специалистов в штате. Но тут уже вопрос решается так, как удобнее руководителю оформлять трудовые отношения. А вот "координатор ИТ в высших эшелонах власти" (это в прошлый раз предлагад врач NN.- В.Т.) звучит непонятно. Должен ли быть человек с достаточными полномочиями, чтобы проводить в жизнь политику автоматизации? Безусловно. Это может быть главврач либо начмед. Должен ли это быть зам. по ИТ, тем более, отдельный ВЦ? Совершенно необязательно. Технические проблемы внедрения должна брать на себя компания-разработчик, организационные - основное руководство (замы и т.д.). А к "руководителям от ИТ" надо относиться осторожно: зачастую таких людей интересуют сначала политика и собственное положение, а уже потом автоматизация и медицина." Ещё о сети На мои пассажи о том, что система должны быть готова к работе и без сети, и при частичном наличии сети, последовали такие замечания. Андрей Геннадьевич. "Это проблема реализации. Как только справочники разрастутся, обязательно потребуется централизация базы данных (переход на SQL сервер). Тогда - только использование сети. Поэтому лучше сразу ее планировать. Затраты на прокладку минимальны, если не возводить Вавилонскую башню. Метр провода - 30-40 рублей, хаб на 12 пользователей - около 1000. Сетка на 10 пользователей обходится в 15-20 тыс. рублей максимум. Не те затраты, на которых нужно экономить." Опять надо уточнять детали. Что значит, "справочники разрастутся"? МКБ - 15 тыс. наименований (и уже не растёт), медикаменты - 5 тысяч (растёт на несколько десятков в год), операции - полторы-две тысячи, лабораторные анализы - 200 вариантов. Ничего особого мне не потребовалось в связи с этим ни в сетевом варианте, ни без сети. Так что здесь мой аргумент - Его величество факт: справочники к сети не вынуждают. Соответственно, я не согласен со следующим утверждением Андрея Геннадьевича: "Справочники медикаментов, лабораторных анализов, консультантов и операций - прерогатива самого ЛПУ. И обработка их должна не зашиваться на конкретные позиции справочника, а использовать параметры настройки, которые, во-первых, может менять сам пользователь (привилегированный!), а, во-вторых, сама система должна проверить правильность ввода параметров, т.е. обладать знаниями о предметной области (это задача программиста)." В моей системе эти справочники - исключительная прерогатива разработчика, сопровождающего систему. Но и самого разработчика, как справедливо требует Андрей Геннадьевич, система проверяет на правильность ввода новой информации. Однако вернёмся к сети. Вот суждение Михаила Владимировича. "Смонтировать сеть нетрудно даже в сельской больнице. Люди есть, деньги смешные, надо лишь главврачу захотеть, а не оправдывать нежелание тем, что это "дорого и сложно". На три компьютера в трех кабинетах ориентировочно надо 3-5 тыс.руб. вместе с хабом, проводами и работой (конечно, зависит от региона, но не сильно). Так что вопрос, делать или нет ПО, которое работает только в сети, принципиален лишь в отошении затрат разработчика. Для него дополнительный канал передачи данных (дискеты, флешки и т.д.) - это приличное избыточное удорожание разработки." Ни с чем не спорю. Но вижу факт: крупные поликлиники, областная клиническая больница, областная инфекционная больница - солидные учреждения, солидные главные врачи. А до сети руки не доходят годами (или только частично доходят). Если бы не дискеты и флешки, не эксплуатировали бы они мою систему. Не могу не считаться с реальностью. И потом: раз это уже сделано, надо ли это осуждать? Ещё о компьютерах и операционных системах Андрей Геннадьевич. "Windows, Linux, Pentium-2 или 3 - ненужный спор. Главное, чтобы система откликалась на действия пользователя в пределах секунд, лучше - миллисекунд. И выдавала всё необходимое. Остальное - от лукавого (или от жира)." Михаил Владимирович. "Это вопрос лишь дополнительных конкурентных качеств программного обеспечения. При использовании нестандартных систем (Linux), несмотря на их бесплатность, именно поставщик программного обеспечения будет вынужден нести расходы по установке и настройке, а потом и по поддержке системы. Если же свалить эту заботу на главврачей, то кому же такой софт нужен будет? Пока Линукс не получит достаточно широкое распространение в качестве рабочих станций, пока не появятся дистрибутивы с полноценной поддержкой русского языка, пока достаточное количество офисных пользователей не будет спокойно работать на нем, переходить на него в промышленном масштабе проблематично. Вот если в связи с очередной кампанией по борьбе с пиратством все перейдут на Линукс, тогда и вернемся к этому вопросу. Но почему-то мне кажется, что все предпочтут поделиться российским бюджетом с Микрософтом." К этим высказываниям моих собеседников нечего добавить. Мотаю на ус. * В заключение, мне кажется уместным заметить, что разговор перешёл в другое качество. Детализация снизила остроту суждений, убрала мнимые противоречия, высветила истинные возможности.Разумеется, так бывает только тогда, когда диспутанты сами делают то дело, о котором говорят. На поверку оказывается, что мы одинаково видим цели и немного по-разному - пути. Но что ж нам, работающим и уже кое-что сделавшим, спорить о выборе пути, который пройден? Мы уже можем сопоставлять результаты, беря в судьи реальных пользователей. Если у каждого из нас есть пользователи, надо признать достижение искомого результата каждым и успешность каждого из выбранных способов действий. Те же, кому путь только предстоит выбирать, пусть знают. что к цели можно придти разными дорогами. Это обогащает возможности. Только теоретизирующие дилетанты могут отрицать уже сделанное и работающее лишь потому, что оно сделано не по канонам, о которых они что-то слыхали. К сожалению, совсем не обращать на них внимания нельзя - они дезориентируют тех. кто хочет работать. |