CC BY
145
Менеджмент в здравоохранении
А.В. Гусев,
к.т.н., заместитель директора по развитию, компания «Комплексные медицинские информационные системы», г. Петрозаводск
КРИТЕРИИ ВЫБОРА МЕДИЦИНСКОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Многолетний мониторинг автоматизации лечебных учреждений в России свидетельствует о постоянно усиливающейся динамике интереса и использования медицинских информационных систем [1]. Современное состояние здравоохранения все более и более усиливает востребованность этих технологий: число учетных и отчетных форм постоянно растет, нагрузка по обработке самой различной информации колоссальна, появляются различные новые методы обследования и лечения, увеличивается зависимость ЛПУ от рационального управления ресурсами и финансами. На фоне этого автоматизация выглядит чуть ли не как единственный способ эффективно управлять лечебным учреждением и хоть как-то высвободить врача и медицинскую сестру от рутины с бумажной обработкой информации.
В связи с этим все большее число руководителей задумывается о приобретении и внедрении современного программного обеспечения (ПО) для решения насущных проблем ЛПУ. Неизбежно возникает вопрос о выборе той или иной медицинской информационной системы (МИС), о выборе целей и задач автоматизации. В данной работе мы постараемся отразить основные критерии, которые в первую очередь рекомендуется рассмотреть при выборе МИС для ЛПУ.
Обзор рынка медицинских информационных систем
В данное время в России зарегистрированы сведения о 775 различных программных продуктах для здравоохранения (по данным АРМИТ, http://www.armit.ru). В это число входят самые разнообразные решения: от небольших программ для формирования статистических отчетов до мощных и современных комплексных медицинских информационных систем (КМИС).
В первую очередь необходимо отметить, что для эффективной автоматизации ЛПУ выбор нескольких программных продуктов различных поставщиков для автоматизации отдельных задач представляется крайне неразумным решением. Опыт автоматизации лечебных учреждений, накопленный за последние 20-30 лет, однозначно свидетельствует о том, что при внедрении нескольких разрозненных приложений неизбежно возникает проблема их совместимости, качественной технической поддержки и эффективного многолетнего использования. Исторически внедрение таких приложений стали называть «лоскутной автоматизацией», вероятно, в силу методов их разработки и внедрения. Такие прило-
© А.В. Гусев, 2010 г.
Менеджмент в здравоохранении
жения отчасти дают хороший эффект только в начале внедрения, когда руководителю ЛПУ нужно решить «горящие» задачи: формирование государственной отчетности, взаиморасчеты по ОМС, формирование плана по вакцинациям или выписку рецептов по ДЛО. Для внедрения таких приложений в ЛПУ создаются фрагменты информационной сети («лоскуты»), например, отдельная сеть у статистиков, отдельная — в бухгалтерии, и устанавливаются автономные рабочие места, чаще всего компьютер в регистратуре, у секретаря главного врача, в отделе кадров, в кабинете вакцинопрофилактики и т.д. Со временем персонал ЛПУ привыкает к компьютерной технике и усиливает требования к применяемому ПО: возникают задачи совместного использования реестра застрахованных, обмена внесенными данными между приложениями, консолидации отчетности в одном приложении и т.д. Пользователи начинают спрашивать: «А почему мы заколачиваем одни и те же данные в несколько программ?», «Почему отчеты от разных приложений дают разные результаты?», «Мы внесли все данные, но получаем 1-2 отчета, а почему нельзя добавить свои отчеты или изменить уже существующие»? и т.д. Чаще всего положительного ответа на задачи консолидации и масштабирования в «лоскутной» автоматизации просто не может быть. Нередко разработчиков отдельного приложения уже просто не найти, программная база других программ безнадежно устарела или производители требуют непомерную оплату за доработки или интеграцию с другим ПО. В результате «лоскутный» подход заставляет ЛПУ нести существенные издержки при эксплуатации такого «зоопарка», что так или иначе заставит руководство рассматривать вариант смены программного обеспечения на единую, комплексную медицинскую информационную систему, интегрирующую в себе все имеющиеся задачи и приложения.
В связи с этим первая рекомендация при выборе МИС выглядит следующим образом: нужно всячески избегать стремления к внедрению нескольких приложений разных разработчиков для отдельных задач. Предпочтение нужно отдавать комплексным медицинским информационным системам (КМИС), уже содержащим в себе не только все функции для сиюминутных задач и проблем ЛПУ, но и возможности, которые теоретически могут быть востребованны в будущем. Только в таком случае ЛПУ может обеспечить себе возможности масштабирования внедрения и постоянного повышения эффективности от автоматизации в будущем.
На сегодняшний день класс программного обеспечения, предназначенного для комплексной автоматизации лечебно-профилактических учреждений различного профиля, включает 63 системы (8,1% от количества всего медицинского ПО)1. В начале 2010 г. журнал «Врач и информационные технологии» опубликовал наше исследование рынка КМИС [1], в ходе которого выяснились достаточно любопытные подробности. В частности, в ходе изучения списка таких систем некоторые из них даже по своему назначению и описанию никак не соответствовали термину «комплексная». Поэтому мы выработали обязательный минимальный набор критериев, который позволяет отнести ту или иную разработку к классу КМИС:
• Наличие электронной медицинской карты (электронной истории болезни и/или амбулаторной карты). Возможность применения КМИС как в условиях поликлиники, так и в условиях стационара. Возможность ведения электронного медицинского документооборота.
• Наличие модуля статистической и финансовой отчетности.
• Наличие средств планирования ресурсов (календари, учет материальных ресурсов
1 По данным каталога АРМИТ
№5 Менеджер
2010 1
Менеджмент в здравоохранении
ЛПУ, автоматизация аптеки, учет нагрузки на персонал и т.д.)
• Наличие основных клинических подсистем, наиболее востребованных при комплексной автоматизации ЛПУ (диспансеризация, ДЛО, вакцинопрофилактика, профосмотры) или хотя бы некоторых из этих функций.
В результате анализа данных критериев и их наличия в задекларировавших себя «комплексными системами» продуктах было выявлено, что только 32 системы соответствуют понятию «комплексных медицинских информационных систем». И даже из этого числа только 10-15 разработок соответствуют минимальным требованиям с точки зрения рынка: обладают развитыми функциональными возможностями и многолетним опытом эксплуатации в реальных ЛПУ в достаточном количестве, предлагают услуги по внедрению и обучению пользователей, приемлемой технической поддержке и при этом, с точки зрения рынка, являются стабильными специализированными IT-компаниями.
Основной особенностью рынка КМИС, которую мы рекомендуем помнить руководителям ЛПУ при выборе систем, является то, что существующие сегодня КМИС очень слабо отличаются друг от друга по заявленным в прайсах и рекламных буклетах функциональным возможностям, но зато достаточно сильно могут отличаться по их эффективности для тех или иных задач и видов ЛПУ, а также глубине и качеству проработки этих функций. Так, еще в 2006 г., выполняя исследование функциональных возможностей 17 наиболее популярных в то время КМИС, мы выяснили, что [2]:
1. Наиболее достоверным показателем, свидетельствующим о действительно комплексном характере системы, является среднее число автоматизируемых рабочих мест за 1 внедрение. В настоящее время мы рекомендуем обращать внимание на те продукты, которые за всю историю своей эксплуатации имеюи среднее количество автоматизированных рабочих мест в одном ЛПУ не менее 50.
2. Декларируемые сегодня функциональные возможности существующих КМИС разительно друг от друга не отличаются. Поэтому строить свой выбор только на списке возможностей системы, изучении рекламных материалов или списка заявленных функций не рекомендуется: слишком велика
опасность приобретения системы, не отвечающей поставленным целям, и, как следствие, потеря денег и дискредитация самой идеи автоматизации ЛПУ.
За прошедшие 3 года ситуация мало в чем изменилась. Например, практически все разработчики декларируют наличие «Электронной истории болезни». Но по факту это может означать как действительно наличие всех необходимых учетных и отчетных форм, официально подтвержденное соответствием ГОСТу «Электронная история болезни. Общие положения», возможностью быстро и эффективно заполнять различные документы и разделы электронной истории болезни, так и понимание под этим термином возможности внести данные и распечатать лишь обложку данного документа (форму 003/у), карту выбывшего из стационара (форму 066/у), данные об операциях и выполненных услугах. Другими словами, разница в системах кроется не в списке функций (они примерно у всех одинаковы), а в глубине, качестве и полноте их проработки.
Еще одной важной особенностью существующих КМИС является наличие опыта в крупных проектах автоматизации ЛПУ. У некоторых разработчиков среднее число рабочих мест, автоматизируемых за 1 внедрение, составляет 10-15 пользователей, что для среднего ЛПУ составляет менее 10% всех рабочих мест. При этом данные системы действительно содержат достаточный набор функций, но вот реальных многолетних проектов, в которых бы они обеспечивали хотя бы 60-80% автоматизированных рабочих мест, такие КМИС продемонстрировать не могут. Другая особенность — это специализация по видам ЛПУ. Сегодня на рынке есть
1енеджер №5
здравоохранения ЗОЮ
Менеджмент в здравоохранении
системы, которые большую часть своего жизненного цикла занимались автоматизацией определенных видов ЛПУ, например, только стационаров или только частных клиник. Постепенное развитие рынка заставляет разработчиков стараться «захватывать» как можно большее число сегментов, поэтому нередко системы, которые разработаны, например, для частных клиник, пытаются активно предлагать муниципальным поликлиникам. При этом главный врач такой поликлиники должен четко понимать, что те функции, архитектура системы, приемы работы в МИС и отчетность, которыя годами разрабатывались и отлаживались для частных ЛПУ, могут быть неэффективны или вообще бесполезны для муниципального ЛПУ по сравнению с системами, изначально разрабатываемыми именно для поликлиник.
Учитывая лишь эти отдельные особенности рынка КМИС, мы рекомендуем четко формировать цель и задачи автоматизации, обращать внимание на реальные проекты внедрения предлагаемых КМИС в очень похожих на Ваше ЛПУ учреждениях, а в идеале — самим непосредственно посетить 1—2 таких учреждения, но работающих с системой хотя бы несколько лет, пообщаться с персоналом и руководством ЛПУ и принимать во внимание в первую очередь их отзывы о системе, а не рекламные буклеты или заверения разработчиков.
Следующее, на что мы бы хотели обратить внимание руководителя ЛПУ, это технические вопросы разработки рассматриваемой системы. Исторически чаще всего создание любой системы шло по принципу: «кто платит, тот и заказывает музыку». Согласно нашим исследованиям, средний возраст существующих сегодня систем составляет 8-10 летЮ и это еще достаточно «молодые» КМИС. Поэтому те принципы, которые были заложены при разработке любой системы, за столь длительный срок достаточно сильно закрепились и обросли
различными надстройками, подсистемами, службами, формами отчетности и т.д. В связи с этим очень важно понимать, что если система изначально разрабатывалась под какие-то определенные задачи, то, чем больше она присутствует на рынке и чем больше у нее проектов внедрения, тем сильнее особенности этой изначальной задачи сказываются в ней. Тем слабее и слабее становится возможность диверсификации такой системы под другой род задач, например, для других целей или других видов ЛПУ.
Для примера, одним из самых частых требований к КМИС на этапе их разработки было формирование статистической отчетности, взаиморасчеты по ОМС и учет услуг в ЛПУ. Поэтому данные системы проектировались и разрабатывались в первую очередь именно для решения данных задач. Для этого они изначально создавались как средство внесения и обработки вторичной документации ЛПУ — карт выбывшего из стационара и статистических талонов. Затем, по мере развития, в систему добавлялся блок формирования отчетности, модули для создания реестров на оплату по ОМС, учета платных услуг и т.д. Постепенно система дополнялась функциями учета ресурсов и трудозатрат ЛПУ и т.д. Другими словами, исторически в такой системе развивались в первую очередь статистические и финансовые возможности, так как ради решения именно этих задач администрация ЛПУ готова была тратить финансовые и людские ресурсы. И лишь по мере развития отдельных проектов автоматизации и изменения ситуации на рынке возникали задачи добавления клинический функций — например, внесения осмотров врачей или протоколов обследования. В результате разработанные таким образом системы очень хорошо подходят для формирования статистики и финансовых расчетов, но слабы в клиническом плане.
Напротив, на рынке есть системы, которые изначально разрабатывались в первую очередь как инструмент для врача и меди-
№5
2010
Менедже1
Менеджмент в здравоохранении
цинской сестры, в них очень сильно развиты элементы медицинского электронного документооборота, поддержки принятия решений и т.д. Нередко такие системы разрабатывались в академической среде или коллективах, вышедших непосредственно из науки. Задачи статистического или финансового плана в таких продуктах нередко ставились на второй план, поэтому их реализация более слаба, чем у продуктов первой группы. С исторической точки зрения, системы первой группы мы называем «административными» (так как они решали в первую очередь задачи для администрации ЛПУ, к которым чаще всего и относятся статистика и финансы), а системы второй группы — «клиническими» (так как они в первую очередь обращены к медицинскому персоналу, непосредственно работающему с пациентами).
Анализируя различные проекты, мы рекомендуем руководителям ЛПУ отдавать предпочтение второму классу продуктов для комплексной автоматизации — клинически ориентированным системам. Объяснение этой рекомендации достаточно простое: административные системы, с точки зрения информационных потоков, протекающих в ЛПУ, начинали свое существование с «конца» процесса — с проектирования и ввода вторичных документов, которыми собственно заканчивается работа любого ЛПУ. Это все равно, что строить дом с крыши. Клинические системы, напротив, разрабатываются, с точки зрения информационных потоков, корректно: они в первую очередь предназначены для эффективного внесения и обработки первичных медицинских документов (осмотров врачей, протоколов операций и обследования), а уже затем как надстройку получали функции статистической обработки и формирования финансовой отчетности. Все эти особенности не могли не сказаться на архитектурных решениях внутри КМИС, их способности и удобстве в плане внесения учетной документации, открытости и т.д. Таким образом, с точки зрения эффек-
тивности автоматизации работы непосредственно врачей и медицинских сестер, «клинические» системы имеют больше преимуществ: их легче внедрить, нужно прикладывать меньше «административного ресурса», интерес и востребованность у медицинского персонала ЛПУ таких продуктов выше, чем у статистически или финансово ориентированных решений.
Еще одной важной технической особенностью системы, на которую следует обратить внимание, является ее открытость. Под этим термином многие разработчики и заказчики понимают разные вещи, но мы рекомендуем под открытостью системы воспринимать ее следующие свойства:
1. Формат базы данных (БД) должен быть открыт, должен быть построен на базе современных «клиент-серверных» СУБД и четко документирован. Сотрудники ЛПУ должны иметь возможность при необходимости самостоятельно либо с помощью 3-х фирм экспортировать или импортировать информацию в БД МИС.
2. КМИС должна все свои основные параметры хранить в централизованных, открытых (согласно п. 1) справочниках. Желательно, чтобы в этих справочниках были не только значения полей в учетных документах (предприятия, компании ОМС, виды медицинской помощи, услуги, персонал и т.д.), но и формы самих документов КМИС, формируемые ею отчеты и т.д. В составе КМИС должны быть встроенные инструменты для настройки этих справочников, в том числе для создания собственных учетных и отчетных форм.
3. Идеально, если КМИС поставляется с полностью открытым исходным кодом, подразумевающим одновременную возможность вносить самостоятельные изменения в процедуры работы КМИС и вместе с этим штатную возможность установки обновлений для КМИС, выпущенных разработчиками. Обязательно открытый код системы должен сопровождаться подробной документацией, кото-
1енеджер №5
здравоохранения ЗОЮ
Менеджмент в здравоохранении
рая должна позволить независимым разработчикам самостоятельно вносить изменения в программное обеспечение КМИС и компилировать новые версии системы.
Наконец, важнейшим критерием выбора КМИС является цена. В нашей статье «Из чего складывается стоимость МИС» [3] мы уже разбирали более подробно вопрос ценообразования общей стоимости проекта внедрения КМИС. Напомним, что в общем смысле стоимость владения КМИС состоит из следующих статей затрат:
• затраты на инфраструктуру, включая приобретение персональных компьютеров и серверов, монтаж ЛВС, бесперебойное электропитание и т.д.;
• затраты на программное обеспечение, включая затраты на общесистемное ПО (операционные системы ПК и серверов, СУБД, антивирусная защита и т.д.) и затраты на КМИС;
• затраты на услуги по внедрению, обучению и технической поддержке.
В среднем общая стоимость проекта автоматизации 1 ЛПУ на 50 рабочих мест будет составлять 2,5 млн. рублей или 51 тыс. рублей за 1 рабочее место. При этом средневзвешенная стоимость лицензий КМИС из расчета за 1 рабочее место составила на начало 2010 г. 28 тыс. рублей, минимальная — 6,9 тыс. рублей, максимальная — 60 тыс. рублей [1].
Рассчитывая стоимость проекта автоматизации ЛПУ, мы бы хотели обратить внимание руководителей ЛПУ на несколько важных моментов. Во-первых, затраты на инфраструктуру (ПК, сервера, ЛВС) вряд ли будут сильно отличатся в зависимости от выбранной МИС. Сегодня какую бы КМИС не выбрало ЛПУ, эта система обязана работать на типовых конфигурациях персональных компьютеров и серверов и стандартных ЛВС. К системам, предъявляющим особые или тем более эксклюзивные требования к инфраструктуре, следует относиться с крайней настороженностью. А это значит, что затра-
ты на инфраструктуру руководителю ЛПУ в любом случае следует планировать, и эти затраты никак не должны зависеть или влиять на выбор КМИС.
Вследствие этого вся разница в стоимости проекта между КМИС будет находиться в 2-х показателях — это стоимость общесистемного ПО и стоимость услуг по внедрению.
В большинстве случаев в стоимость лицензий КМИС не включается цена на общесистемное ПО и услуги. Более того, нередко в коммерческих приложениях разработчики вообще не требуют приобретение лицензионного общесистемного ПО, а лишь рекомендуют его. Вследствие этого руководство ЛПУ может ошибочно сравнить только 2 стоимости — на саму КМИС. Но при этом не обратить внимание, что одна система может быть дешевле другой, например, на 20-30%, но требовать общесистемное ПО, стоимость которого по сравнению с конкурентным решением будет на 50-80% дороже. При этом нужно обязательно понимать, что ответственность за использование нелицензионного ПО (и, как следствие, высокая вероятность обязательного его приобретения) лежит исключительно на руководителе ЛПУ, но никак не на разработчиках. В связи с этим, с точки зрения стоимости ПО, нужно всегда анализировать обе цифры — и стоимость самой КМИС, и стоимость общесистемного ПО на 100% оборудования (ПК и серверов), которое для данной системы необходимо. В среднем стоимость лицензирования общесистемного ПО на 1 рабочее место к началу 2010 г. составила 13,2 тыс. рублей [1].
Еще одним и нередко решающим фактором является стоимость услуг по внедрению и техническому сопровождению. В данном вопросе на рынке имеются колоссальные различия. В среднем стоимость услуг по внедрению из расчета за 1 рабочее место в среднем составляет 7,7 тыс. рублей, а средняя стоимость технической поддержки и сопровождения составляет 100 тыс. рублей в квартал на ЛПУ, но она у различных КМИС
№5 Менеджер
2010 1
Менеджмент в здравоохранении
колеблется в настоящее время от 40 тыс. руб. за ЛПУ до 300-500 тыс. руб.
Также важно отметить, что чаще всего в эту стоимость входит техническая поддержка по электронной почте или телефону. При необходимости выезда специалистов на место стоимость таких услуг увеличивается с учетом командировочных затрат.
Наконец, мы особо хотим обратить внимание, что одной из последних модных тенденций на рынке КМИС у некоторых новых разработок является декларация о якобы бесплатной КМИС, которая отдается ЛПУ совершенно безвозмездно и не требует коммерческого общесистемного ПО. Некоторые руководители ЛПУ, увидев слово «бесплатная поставка КМИС» в рекламе таких систем, тут же начинают отдавать таким предложениям высокий приоритет. Но любой руководитель ЛПУ должен понимать, что совершенно бесплатного проекта автоматизации не может быть по определению, так как любой разработчик должен как-то обеспечивать коммерческую оправданность своего существования, платить заработную плату профессиональным программистам и гарантировать развитие и сопровождение своего продукта в будущем. А это можно сделать только на основе коммерческих отношений между ЛПУ и разработчиком. Решается данная проблема у «бесплатных МИС» достаточно просто: саму систему ЛПУ можно получить бесплатно, но за услуги по внедрению и сопровождению ЛПУ нужно будет заплатить, причем, как правило, сумму, в итоге сопоставимую, если не большую, по сравнению с коммерческим МИС. Примером такого подхода является аукцион, объявленный 11 ноября 2009 г. Администрацией Саратовской области на поставку и внедрение МИС для нужд ГУЗ «Саратовская областная детская клиническая больница»2. Согласно условиям аукциона, поставка КМИС для нужд данного ЛПУ «бесплатной
МИС» с оказанием услуг по опытной эксплуатации в течение 1 месяца и технической поддержке в течение 1 года на 80 рабочих мест оценивалась в 3,8 млн. рублей или 47,5 тыс. рублей за 1 рабочее место. Так что назвать такие проекты «бесплатными» никак нельзя, так как затраты для ЛПУ просто перемещаются из статьи «за лицензии» в статью «услуги». Более того, хотелось бы обратить внимание на еще одну особенность такого подхода. Она заключается в том, что разработчики, отдавая МИС в ЛПУ бесплатно, полностью зависят от услуг, которые ЛПУ должно будет заказать (иначе на чем разработчик будет зарабатывать деньги?). В подавляющем большинстве случаев эти услуги представлены технической поддержкой и доработкой системы под нужды ЛПУ. А значит, разработчик должен предлагать такую КМИС, которая бы гарантированно нуждалась в технической поддержке и доработке с его стороны, иначе ЛПУ просто откажется от этих услуг. Очевидно, что такую задачу можно решить только путем усложнения процедуры установки, настройки, эксплуатации и доработки такой системы. А это в свою очередь делает ЛПУ заложником таких разработок, что в дальнесрочной перспективе выглядит слабо привлекательным.
Поэтому главному врачу ЛПУ при решении вопроса о выборе конкретной МИС следует не просто анализировать показатель «стоимость КМИС», но и всю группу показателей затрат на владение системой, включая общесистемное ПО и услуги по внедрению и сопровождению программного продукта, особенно в течение всего срока его эксплуатации. Не следует анализировать только начальные затраты, нужно тщательно изучить и затраты на поддержание и эксплуатацию системы в будущем, стоимость ее сопровождения и обновления со стороны разработчиков.
2 По данным сайта http://www.goszakaz.saratov.gov.ru
А44
1енеджер №5
здравоохранения ЗОЮ
Менеджмент в здравоохранении
Выводы
Итак, подытожив все вышесказанное, мы сформулировали следующие рекомендации при выборе МИС:
1. Не следует рассматривать вариант «лоскутной автоматизации». Выбор ПО нужно осуществлять из комплексных медицинских информационных систем (КМИС).
2. При выборе КМИС четко сформулируйте цель и задачи автоматизации. При общении с разработчиками обратите внимание на наличие реальных проектов внедрения предлагаемой системы в похожих на Ваше ЛПУ учреждениях. При возможности сами непосредственно посетите 1-2 таких учреждения, работающих с системой хотя бы несколько лет, и постарайтесь пообщаться с персоналом и руководством ЛПУ. При формировании решения принимайте во внимание в первую очередь их отзывы о системе, а не рекламные буклеты или заверения разработчиков.
3. Выбирая КМИС, следует рассмотреть возможность отдать предпочтение клинически ориентированным решениям.
4. КМИС должна быть открытой, то есть она должна предоставлять возможности свободной обработки информации в БД, настройки справочников, изменению и добавлению учетных и отчетных форм. В идеале КМИС должна поставляться в открытом исходном коде и с подробной технической документацией.
5. При рассмотрении стоимости владения конкретной МИС следует анализировать всю группу показателей затрат на владение системой, включая общесистемное ПО, стоимость КМИС и услуги по внедрению и сопровождению программного продукта. Особо обратите внимание на затраты по эксплуатации и сопровождению системы со стороны разработчиков после этапа внедрения.
1. Гусев А.В. Обзор рынка комплексных медицинских информационных систем// Врач и информационные технологии. — 2009. — №6. — С. 4-17.
2. Гусев А.В. Обзор функциональных возможностей российских медицинских информационных систем//Менеджер здравоохранения. — 2006. — № 12. — С. 22-30.
3. Гусев А.В. Из чего складывается стоимость МИС//РС Week/RE. — 2006. — № 28-29 (538-539)//http://www.pcweek.ru/themes/detail.php?ID=72944.
№5 Менеджер
2010 1 2 3
