Обзор функциональных возможностей Российских медицинских информационных систем (А.В. Гусев, "Менеджер здравоохранения", N 12, декабрь 2006 г.)

Обзор функциональных возможностей Российских медицинских
информационных систем

Введение.

В настоящее время в России, по данным каталога Эльянова М.М., имеется 78 медицинских информационных систем, которые могут быть использованы для решения задачи комплексной автоматизации ЛПУ [4], максимальной формой которой является полный электронный документооборот внутри лечебно-профилактического учреждения (ЛПУ) и вымещение бумажных носителей информации. Выбрать наиболее приемлемую для ЛПУ систему сегодняшним руководителям не так то просто. Причем это зависит не столько от разнообразия присутствующих на рынке МИС, сколько от тех целей, которые ставит перед собой главный врач больницы или поликлиники. Привести в соответствие функциональные возможности (ФВ) существующих МИС с целями автоматизации ЛПУ достаточно сложно. Кроме этого, вопрос выбора, безусловно, в значительной степени усложнен как вообще непосильной многим ЛПУ стоимостью комплексной автоматизации ЛПУ, так и широким разбросом цен на лицензии собственно комплексных МИС и услуги по их внедрению. В связи с этим проблема выбора системы состоит не только в поиске программных решений с необходимым спектром функциональных возможностей, удовлетворяющем поставленной цели, но и в том, что этот выбор должен, безусловно, как-то оправдать потраченные деньги, а это возможно только при действительно комплексном характере автоматизации всех бизнес-процессов внутри ЛПУ [1, 2].

Целью этой обзорной статьи является представить укрупненное описание ФВ существующих МИС, выделив наиболее ценные программные решения.

На сегодня существует 3 принципиально различных подхода к автоматизации ЛПУ:

1. Автоматизация административной работы, заключающаяся чаще всего в автоматизации бухгалтерии, отдела статистики, отдела кадров, хозяйственного блока и т.д.;

2. Автоматизация клинической работы;

3. Комплексная автоматизация ЛПУ, подразумевающая работу всех сотрудников и служб ЛПУ в единой комплексной МИС.

Первых подход является наиболее распространенным. Это вызвано, главным образом, значительными финансовыми ограничениями - когда денег на компьютеры и ПО больница может выделить мало, то в первую очередь решаются "горящие" вопросы, без решения которых у главного врача могут наступить необратимые проблемы. К сожалению, к их числу не относятся задачи обеспечения качества лечебно-профилактического процесса. В подавляющей своей массе - это задачи взаимодействия с ОМС или ДМС (без своевременного выставления счетов ЛПУ может попросту остаться банкротом), задача расчета заработной платы сотрудникам (задержки или неверные расчеты зарплаты грозят серьезным кадровым кризисом), сбор и формирование статистической отчетности (несвоевременная подача стат. отчетов грозит главному врачу серьезными проблемами со стороны Минздравсоцразвития и подчиненных ему служб) и т.д. Этот спектр вопросов очень характерен сегодня для государственных ЛПУ. В ведомственных и даже частных больницах ситуация ничуть не лучше. Как правило, в ведомственных больницах существует еще большее количество стат. отчетов, а в частных ЛПУ остро стоит вопрос финансирования и окупаемости, поэтому все вычислительные ресурсы направляются в первую очередь на обеспечение именно задач бухгалтерии и строгого учета выполненных услуг и потраченных расходных материалов.

Указанные проблемы являются основной причиной низкой распространенности систем, ориентированных на автоматизацию именно клинической работы ЛПУ. Известно, что 80% разработчиков существующих МИС являются частные компании [1]. Понятно, что они производят именно те программные продукты, которые востребованы рынком, т.е. разрабатывают системы именно для решения в первую очередь административных проблем - ведь окупить немалые затраты на разработку МИС можно только при определенном и немало объеме продаж. И этот объем проще всего реализовать на решении проблем именно администрации ЛПУ, коль именно она, прямо или косвенно, но является непосредственным заказчиком системы. В большинстве существующих МИС задачи формирования статистики, взаимодействия с ОМС и ДМС, учета платных услуг, а также приложения для хозяйственного блока (аптека, например) проработаны достаточно хорошо. Чего не скажешь о чисто клинических задачах, например - организация и проведение диспансерного наблюдения или подробные и продуманные протоколы осмотра специалистов. Эти направления работы начали приобретать свою актуальность лишь в последний год, с началом конкретных акций в рамках реализации национального проекта "Здоровье". Возможно, в ближайшее время ЛПУ начнут все-таки проявлять интерес и к таким направлениям использования информационных технологий, как автоматизация планирования и проведения профосмотра или повышение эффективности диспансерного наблюдения, ведь по показателям этих видов деятельности уже выплачиваются вполне "живые" и ощутимые для ЛПУ денежные суммы.

Все это сделало 3-е направление автоматизации - комплексные МИС (КМИС) - достаточно редким явлением. При этом редки не только системы, позволяющие автоматизировать весь спектр задач ЛПУ, но и их внедрения. В особенности редки случаи полного электронного документооборота, который бы вытеснил привычные всем бумажные истории болезни или амбулаторные карты, которые являются на сегодня главным фактором, тормозящим повышение качества и оперативности оказания лечебно-профилактической помощи.

В связи со всем вышесказанным мы провели исследования существующих систем, декларирующих возможности комплексной автоматизации ЛПУ с целью выявления тех возможностей, которые на сегодня представлены и распространены в большинстве случаев.

Описание рассмотренных МИС (материал исследования).

В данном обзоре мы рассмотрели основные КМИС, имеющиеся на данный момент на отечественном рынке. Всего группа исследования составила 35 систем, так или иначе декларирующих возможность комплексной автоматизации. Всем разработчикам мы разослали анкету с просьбой указать, какие функциональные возможности реализованы в их системе. На наш запрос ответили 17 разработчиков (48,6%) следующих систем: ИС Кондопога, e-Hospital, Амулет, ДОКА+, Интрамед, ФИРС АРМ, Интерин, Авиценна, МедОфис, Фобос, MedWork, TheDrep, Метео-П, Парацельс-А, Эверест, Э-Куб, МедИС-Т. По некоторым другим системам у нас имелась почти полная информация, составленная по данным официальных сайтов, однако в окончательном итоге мы не стали ее использовать в расчетах с целью обеспечить максимально возможную объективность. Вместе с этим при предварительной обработке материалы мы не обнаружили существенного различия в полученных показателях при использовании данных сайтов, поэтому в целом накопленная выборка признана нами в достаточной степени репрезентативной.

     Методика исследования. Для анализа функциональных возможностей  (ФВ)

мы составили обобщающую таблицу, в которой перечислили наиболее важные  и

общие возможности МИС (табл. 1). Всего в таблицу вошло 40 пунктов.  Было

бы  естественно   каждому   пункту   присвоить     индивидуальную оценку,

характеризующую степень важности  в  составе  МИС.  Однако  такой  подход

является весьма условным, поэтому каждому пункту мы присвоили оценку в  1

балл (f          = 1). Некоторые ФВ в свою  очередь состоят  из разделов,

       i = 1..40

каждый из которых был оценен нами  в  пропорциональной  мере.  Так,  МИС,

позволяющая автоматизировать полностью весь бухгалтерский учет ЛПУ (ФВ N 9

в таблице 1), получала оценку по этой ФВ в 1 балл. Если  же  в  МИС  была

реализована только некоторая часть (например, расчет  заработной  платы),

то система получала оценку как сумму включенных модулей, т.е.  меньше  1.

Кроме  этого,  если  разработчики  отмечали  в  анкете,  что  данная   ФВ

реализована у них частично, то мы также  выставляли  оценку,  меньшую  1,

чаще всего - 0,5.

Таким образом, максимально возможная оценка ФВ одной медицинской информационной системы составляет 40 баллов.

Таблица 1

Перечень функциональных возможностей МИС

1. Электронная история болезни

2. Электронная амбулаторная карта

3. Автоматизация регистратуры

4. Возможность информационного обмена с компаниями ОМС

5. Учет медицинских услуг в ОМС

6. Учет медицинских услуг в ДМС

7. Учет платных медицинских услуг

8. Учет посещений

9. Ведение полной бухгалтерии ЛПУ (внешняя подсистема: минус 0,1)

a. Автоматизация расчета стоимости лечения (0,25)

b. Расчет заработной платы (0,25)

c. Работа с банками (0,25)

d. Экспорт в другие финансовые системы (1С, Парус или указать, какие) (0,25)

10. Лабораторная подсистема (внешняя подсистема: минус 0,1)

a. В том числе автоматический обмен данными с анализаторами (0,4)

b. Встроенная подсистема контроля качества (0,3)

c. Возможность автоматического ведения журналов выполненных исследований (0,3)

11. Функциональная диагностика (база - 0,8)

a. Встроенное ПО автоматического анализа ЭКГ (0,2)

12. Лучевая диагностика (база - 0,2, внешняя подсистема: минус 0,1)

a. В том числе УЗИ (0,2)

b. В том числе возможность архивирования изображений (0,2)

c. Поддержка DICOM (0,2)

d. Возможность подключения внешних архивов (например, на DVD-дисках) (0,2)

13. Подсистема диспансерного наблюдения

14. Подсистема профосмотра

15. Подсистема учета временной нетрудоспособности

16. Подсистема вакцинопрофилактики

17. Автоматизация скорой помощи

18. Автоматизация вызовов врача на дом (в поликлинике)

19. Подсистема флюоротеки

20. Автоматизация выдачи рецептов (база - 0,2)

a. В том числе льготных рецептов (0,4)

b. Соответствие требованиями приказов N 55, 56 и 57 по учету медицинской помощи льготной категории граждан (0,4)

21. Автоматизация лечебных кабинетов (база - 0,1)

a. Массаж (0,15)

b. ЛФК (0,15)

c. ИРТ (0,15)

d. Бальнеотерапия (0,15)

e. Гидротерапия (0,15)

f. Электрофототерапия (0,15)

22. Подсистема автоматизации службы питания

23. Отдел кадров (внещняя подсистема, но интегрированная в МИС - 0,9)

24. Аптека

25. Автоматизированный учет материальных ресурсов ЛПУ

26. Ведение личных календарей (расписаний работы)

27. Контроль качества медицинской помощи

28. Ведение справочников

a. Встроенная МКБ-10 (0,3)

b. Встроенный справочник медицинских услуг (0,3)

c. Встроенный реестр лекарственных средств (0,3)

29. Встроенный интранет-сайт системы

30. Автоматический расчет статистических отчетов

a. Расчет установленных форм отчетности (16-ВН, 12, 30 и т.д.) (0,25)

b. Возможность изменять существующие формы или создавать новые (0,25)

c. Возможность создавать произвольные выборки по любому из регистрируемых в системе параметров (0,25)

d. Возможность экспорта в документы Microsoft Office (0,25)

31. Поддержка принятия решений

32. Возможность печати документов

33. Возможность экспорта документов в другие форматы

34. Возможность построения графиков изменения параметров в документах в динамике

35. Возможность удаленного доступа через http

36. Возможность удаленного доступа через собственный формат (протокол)

37. Возможность индивидуальной настройки системы под пользователя

38. Наличие отрытого API

39. Возможность самостоятельной доработки системы

40. Поставка системы с открытым исходным кодом

В присвоении оценки мы полагались на анкеты, полученные от разработчиков, без учета собственного мнения или мнения пользователей этих систем. Безусловно, каждый разработчик по-разному понимает и трактует ту или иную ФВ. Мы решили оставить эти оценки без коррекции. В основу такого решения была положена мысль о том, что если производитель декларирует наличие, например, электронной истории болезни (ЭИБ), то потенциальные пользователи будут принимать эту декларацию к сведению исходя из собственного понимания термина "ЭИБ", а не исходя из общепринятого или подразумеваемого разработчиком. В некоторых МИС (Интерин, Кондопога, ДОКА+) под ЭИБ понимают возможность полного ведения медицинской документации стационара (истории болезни) или поликлиники (амбулаторная карта) в рамках информационной системы - со всеми вытекающими отсюда возможностями МИС - регистрация пациентов, ведение дневниковых записей, архивирование результатов диагностики и лечения, использование лабораторных информационных систем и т.д. Некоторые же системы предусматривают в качестве ЭИБ систему, позволяющую автоматизировать подготовку определенных документов к печати или ввод данных о посещениях или оказанных услугах. В данной статье мы не беремся обсуждать полноту реализации каждой ФВ из числа рассмотренных, т.к. пока у нас нет возможности провести объективное исследование каждой информационной системы и определение в ходе этого исследования полноты соответствия каждого вида ФВ некоему общему критерию. Нам был важен факт обобщения (возможно, достаточно общего) ФВ существующих МИС и анализ полученных данных.

     Расчет процента встречаемости мы осуществляли следующим образом:  по

каждому  блоку  ФВ  была  определена  максимально  возможная сумма баллов

  MAX

FV    = Сумма f = 1, где  m - число систем, участвовавших в исследовании.

  i     j...m  m

Фактически, если бы все  системы  декларировали  одни  и  те  же  ФВ,  то

максимально возможная сумма баллов должна была бы равняться сумме  баллов

по каждой ФВ, указанной разработчиками в анкете. На практике,  все  таки,

разработчики  признавали,  что  той  или  иной  ФВ  в   их   системе   не

предусмотрено,  например  -  поддержка  лаборатории  и  т.д.  Поэтому  мы

                                                         real

суммировали указанные баллы по каждой ФВ у всех систем FV     = Сумма f ,

                                                         i      j...m  m

а затем суммировали баллы по всем ФВ в одном и том же блоке,  например  -

сумма баллов по блоку задач бухгалтерии FV      = Сумма f .  После  этого

                                          block   i..40  i

определялись 2 показателя:

                                              real

                                            FV     х 100

                                              i

       % встречаемости ФВ, по формуле: P  = ------------ %

                                        i        MAX

                                               FV

                                                 i

                                                     FV      х 100

                                                       block

       % встречаемости блока ФВ, по формуле P      = ------------- %

                                             block        MAX

                                                        FV

                                                          block

Анализ результатов.

Все системы в сумме набрали 472,85 баллов или 69,54% от максимально возможной суммы. Средний балл составил 27,81 (+6,51). Максимальный бал по ФВ выявлен у медицинской информационной системы Кондопога (37,8 баллов), минимальный - у e-Hospital (14,55баллов).

После подсчета среднего балла мы разделили все системы на 2 основных группы: с функциональными возможностями больше среднего (в нее попали 8 систем или 47%) и с функциональными возможностями ниже среднего (9 систем). При этом мы проанализировали важнейшие показатели МИС по этим 2 группам, представленные в таблице 2.

Таблица 2

Основные показатели МИС в разрезе реализованных
функциональных возможностей

Показатель	Среднее значение	Значения в группах
		Средний балл > 27,81 (ФВ выше среднего)	Средний балл < 27,81 (ФВ ниже среднего)
Давность разработки, лет	10,71	11,50	10,00
Число программистов, человек	21,18	33,5	10,22
Число внедрений	14,29	18,63	10,44
Число автоматизированных рабочих мест	571,06	1005,25	185,11
Среднее число автоматизируемых рабочих мест за 1 внедрение	47,98	82,53	17,26
Трудозатраты на разработку, человеко-лет.	259,59	434,25	104,33
Эффективность разработки МИС*	23,52	36,23	12,22
* Эффективность разработки МИС мы определяли как отношение трудозатрат на разработку (определенное как произведение числа разработчиков на длительность разработки) к числу внедрений

Как видно из таблицы, многие показатели достаточно сильно различаются в зависимости от богатства функциональных возможностей, имеющихся в МИС. При этом наиболее интересным оказалось распределение по длительности разработки, которое, фактически, свидетельствует о том, что среднее время, затраченное на создание современных МИС, не влияет на полноту реализованных функций в системах. Другими словами, длительность работы над системой, которая понадобилась разработчикам, еще не является показателем достаточно широкой базы возможностей системы! Например, медицинская информационная система Интерин, занявшая второе место по богатству возможностей и набравшая 36,95 баллов, разрабатывается в течение 11 лет. Столько же времени, по данным анкетирования, ушло на разработку системы TherDep, которая заняла предпоследнее место, набрав 17,65 баллов.

Вместе с этим, остальные показатели демонстрируют значительные разбросы. Так, на создание МИС с широкими функциональными возможностями требуется в 3 раза больше разработчиков и в 4,2 раза больше трудозатрат. При этом развитые с точки зрения ФВ системы имеют и более число внедрений - в 1,8 раза. Наконец, важнейший показатель - средний объем автоматизируемых рабочих мест в 1 ЛПУ в таких системах в 5,4 раза превышает средний показатель по небогатым с точки зрения ФВ системам. А это уже прямой показатель, говорящий о потенциале системы и возможности ее комплексного использования. И как итог, показатель эффективности разработки, т.е., по сути, отдачи от труда программистов, среди хорошо проработанных систем в 3 раза выше.

Все это свидетельствует, что современной медицинской информационной системе необходимо достаточно широкий спектр возможностей, чтобы надеется на высокие показатели эффективности ее разработки и объемов внедрения и, таким образом, составлять достойную конкуренцию на рынке среди других подобных систем.

Дальнейшим шагом исследования явилось изучение частоты встречаемости тех или иных функциональных возможностей. Для этого всех их мы разделили по следующим блокам:

Задачи бухгалтерии (п. 4, 5, 6, 7, 8, 9)

Задачи административного блока (п. 23, 31)

Хозяйственный блок (п. 22, 24, 25)

Задачи статистики (п. 30)

Блок общесистемных возможностей (п. 28, 29, 32-40)

Блок лечебно-профилактических возможностей

Блок лечебно-диагностических возможностей, в свою очередь, был разделен на 2 подраздела:

Общеклинические возможности (п. 3, 10, 11, 12, 15, 26, 27)

Специфичные задачи стационара или санатория (п. 1, 17, 21)

Специфичные задачи поликлиники (п. 2, 13, 14, 16, 18, 19, 20)

Для выявления распространенности различных групп ФВ мы подсчитали удельный вес каждой группы среди всех ФР, реализованных в системах. По сумме баллов мы получили следующее распределение:

Задачи статистики - представлены в 100% КМИС

Задачи бухгалтерии - представлены в 86,6% КМИС

Автоматизация лечебно-профилактической работы - возможна в 65% КМИС

Хозяйственный блок реализован в 63,73% КМИС

Автоматизация руководителей (административный блок) - в 45,29% КМИС

Полученные цифры являются подтверждением общей тенденции применения современных информационных систем в здравоохранении. На первое место вышли задачи статистики и бухгалтерии. Практически на одно место поставлены задачи автоматизации клинической работы и хозяйственного блока. Последнее место отводится задачам автоматизации работы администрации ЛПУ - отдела кадров и т.д. Все это подтверждает тезис о том, что большинство КМИС на рынке решают, прежде всего, задачи, не связанные напрямую с оказанием лечебно-профилактической помощи. Вместе с этим предложенные важнейшие общесистемные возможности присутствуют в 70,43% КМИС, что говорит о достаточно высоком техническом уровне предлагаемых решений.

Таким образом, мы можем сделать вывод, что с точки зрения качества программной реализации существующих КМИС для медицины имеется достаточно высокий уровень, несмотря на низкую для рынка рентабельность и инвестиционную привлекательность этого сектора [1]. Однако спектр предлагаемых функциональных возможностей главным образом направлен на решение задач статистики и бухгалтерии, хотя именно автоматизация клинической работы должна иметь превалирующее значение.

Одной из задач нашей работы явилось исследование, какой же спектр лечебно-профилактических направлений в первую очередь стремятся автоматизировать разработчики. Для этого проанализируем распределение ФВ в лечебно-профилактическом блоке:

Общеклинические возможности предоставляют 69,66% КМИС

Специфичные задачи стационара или санатория позволяют решать 50,69% КМИС

Специфичные задачи поликлиники можно автоматизировать в 66,55% КМИС

Общеклинические возможности характеризуются следующим распределением:

Таблица 3

Встречаемость общеклинических ФВ среди КМИС

Название ФВ	Встречаемость среди КМИС, %
Автоматизация регистратуры (п. 3)	100%
Ведение личных календарей (п. 26)	94,12%
Подсистема учета временной нетрудоспособности (п. 15)	88,24%
Функциональная диагностика (п. 11)	60%
Лабораторная подсистема (п. 10)	55,88%
Лучевая диагностика (п. 12)	54,12%
Контроль качества медицинской помощи (п. 27)	35,29%

В данной таблице приоритет у задач, связанных с управлением потоков пациентов внутри ЛПУ: регистратура, управление рабочим временем при помощи календарей. Часто реализуется учет листов временной нетрудоспособности (ЛВН), но, главным образом, в силу необходимости составления соответствующих статистических отчетов (форма 16-ВН, например). Налицо диссонанс в автоматизации диагностических служб: традиционно для любого ЛПУ лабораторные исследования имеют наибольшее значение - 80% всей диагностической информации по данным Михайлова [1]. Однако ФВ для лаборатории отстают от группы функциональной диагностики. Очевидно, это объясняется несравнимо большей сложностью в автоматизации лаборатории по сравнению с отделением функциональной диагностики. В работе лаборатории есть целый спектр специфических задач: подключение анализаторов в лабораторную сеть, автоматизация оценки качества, учет референтных значений, управление поступившими заказами и их распределение по рабочим местам и анализаторам и т.д. Крупные лаборатории в настоящее время в силу сложности и специфичности их работы предпочитают использовать специализированные лабораторные информационные системы (ILIMS, LabTrack и т.д.). По факту получается, что упростить работу регистратора - далеко на самого важного в лечении пациента сотрудника, к тому же нередко вообще не имеющего прямого отношения к лечебно-диагностическому процессу, предлагают 100% систем, а повысить эффективность и качество работы таких важных служб, как отделение функциональной диагностики или лабораторию - лишь чуть более половины МИС! И, как это не парадоксально, самое последнее место в группе "Общеклинические возможности" заняла функция автоматизации контроля качества медицинской помощи - реализованная только у 35,29%. Это наглядно символизирует, что во многих отечественных МИС автоматизация именно клинической работы стоит на последнем месте.

Таблица 4

Встречаемость ФВ для стационара среди КМИС

Название ФВ	Встречаемость среди КМИС, %
Электронная история болезни (п. 1)	97,06%
Автоматизация лечебных кабинетов (п. 21)	46,18%
Автоматизация скорой помощи (п. 17)	8,82%
Другие ФВ, не входящие в состав группы, но предназначенные для стационара или санатория
Автоматизация аптеки (п. 24)	76,47%
Автоматизация службы питания (п. 22)	44,12%

Таблица 4 также наглядно демонстрирует доминирование нелечебных задач. Например, автоматизация аптеки предусмотрена в 76,47% современных КМИС, а вот автоматизация лечебных кабинетов (массаж, физиолечение, ЛФК и т.д.), имеющих достаточно большее значение в стационарном лечении, предусмотрена всего лишь у 46,18% КМИС. Этот факт также вызывает сомнения в том, что термин "Электронная история болезни" понимается всеми одинаково. По нашему мнению, возможность ведения электронной истории болезни неотрывно связана с возможность вносить информацию обо всех направления диагностики и лечения пациента. Однако, как мы видим из таблиц 2 и 3, на практике это далеко не так - почти все разработчики (97.06%) продекларировали, что имеют электронную историю болезни, но возможность внести результаты функциональной диагностики есть только у 60%, а автоматизировать лечебные кабинеты могут только 46,18% КМИС?! Этот факт наводит на мысль, что некоторые разработчики понимают под термином "Электронная история болезни" лишь обложку, которая содержит данные о поступлении и статистическую информацию - но не полностью всю историю болезни, как могли бы подумать большинство врачей, читавших представленные анкеты.

Для контроля мы выделили в анкете пункт "Автоматизация скорой помощи". Эта задача является достаточно автономной и, как нам представляется, с успехом может быть решена при помощи специализированного программного продукта, аналогично со специализированными лабораторными информационными системами или программами для автоматизации расшифровки ЭКГ. Полученные результаты подтвердили это - лишь 8,82% КМИС имеют в своем составе средства для автоматизации скорой помощи, хотя на рынке есть несколько программ, которые предназначены именно для этого вида деятельности ЛПУ - а значит, такие программы востребованы и имеют достаточную эффективность.

Таблица 5

Встречаемость ФВ для поликлиники среди КМИС

Название ФВ	Встречаемость среди КМИС, %
Электронная амбулаторная карта (п. 2)	100%
Подсистема диспансерного наблюдения (п. 13)	76,47%
Подсистема профосмотра (п. 14)	76,47%
Автоматизация выписки рецептов (п. 20)	60%
Подсистема вакцинопрофилактики (п. 16)	58,82%
Подсистема флюоротеки (п. 19)	47,06%
Подсистема вызова врача на дом (п. 18)	47,06%

Аналогично тревожная ситуация и в возможностях КМИС для поликлиники. Все 100% разработчиков заявили о наличии электронной амбулаторной карты, но далеко не все позволяют вносить важнейшую для поликлиники информацию - данные диспансерного наблюдения или профосмотре, результаты вакционопрофилактики и т.д. Хотя и следует отметить высокую плотность показателей по ФВ для поликлиники.

Обсуждение.

В целом анализ полученных анкет позволяет сделать несколько важных выводов:

1. При выборе системы не следует обращать внимание на длительность разработки, т.к. она не влияет на качество программного продукта.

2. Наиболее достоверными показателями, свидетельствующими о действительно комплексном характере системы, являются среднее число автоматизируемых рабочих мест за 1 внедрение и трудозатраты на разработку.

3. Декларируемые на сегодня функциональные возможности существующих КМИС разительно друг от друга не отличаются. Поэтому строить свой выбор только на списке возможностей системы не рекомендуется.

4. Выявлены явные противоречия в толковании различных терминов между разработчиками, если не сказать - ошибочное толкование. Все это значительно осложняет задачу выбора КМИС руководителями ЛПУ и еще раз свидетельствует о том, что полагаться на рекламные буклеты или заявления разработчиков о наличии той или иной функции при выборе КМИС не следует ни в коем случае - слишком велика опасность приобретения системы, не отвечающей поставленным целям, и, как следствие - потеря денег и дискредитация самой идеи автоматизации ЛПУ.

Выявленная проблема породила ряд предложений, которые есть смысл обсудить в периодической печати или в среде профессиональных сообществ:

1. Что понимается под терминами "электронная история болезни" и "электронная амбулаторная карта"?

2. Необходимо разработать унифицированный набор требований и функциональных возможностей по каждому из декларируемых направлений, который, возможно, есть смысл опубликовать в виде национальных рекомендаций.

3. Необходимо усилить влияние сертификации КМИС, в том числе за счет добровольной сертификации на предмет соответствия общепринятым терминами и требованиям. Такие сертификаты соответствия должны стать определенным "знаком качества", защищающим интересы ЛПУ и их инвестиции при приобретении и внедрении КМИС.

Литература

1. Гусев А.В., Романов Ф.А., Дуданов И.П. Медицинские информационные системы: анализ рынка PCWeek N 47 / 2005. С 38-40 http://pcweek.ru/?ID=504911

2. Гусев А.В. и соав. Медицинские информационные системы. Петрозаводск.: Из-во ПетрГУ, 2005 г. с. 404

3. Михайлов Ю.Е. Информационно-компьютерные технологии - актуальный и неизбежный шаг совершенствования лабораторной диагностики (на примере создания и использования автоматизированной рабочей группы "Гематология") / Ю.Е. Михайлов // Клиническая лабораторная диагностика. 2001. N 7. С. 25-32.

4. Эльянов М.М. Медицинские информационные технологии. Каталог. Вып. 6 - М.: Третья медицина. - 2006. - с. 320 Электронная версия каталога опубликованная на сайте http://www.armit.ru.

А.В. Гусев,

к.т.н., старший инженер-программист ОАО "Кондопога",

Вычислительный центр ОАО "Кондопога", Карелия

e-mail: gusev@kbk.onego.ru

"Менеджер здравоохранения", N 12, декабрь 2006 г.