Тяжелый выбор руководителя ЛПУ: тиражная медицинская информационная система или собственная разработка

Самолечение опасно для здоровья. Врачи не устают об этом повторять. Но, несмотря на все предупреждения, люди продолжают заниматься этим увлекательным делом.  А наиболее энергичные энтузиасты самолечения расширяют свою «частную практику» не только на членов семьи, но и на более широкий круг друзей и знакомых. Сложность предмета, высокие риски и нередко значительная стоимость экспериментов над здоровьем не может служить препятствием для увлеченного человека.

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

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

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

1. разработать МИС самим – дешевле, чем покупать готовую;
2. при самостоятельной разработке будет создан продукт, максимально соответствующий потребностям организации, а в покупной, особенно тиражной, системе чего-то может недоставать;
3. когда продукт будет готов, то можно будет не только пользоваться самим, но и продавать в другие ЛПУ.

Рассмотрим первый аргумент – о том, что самим сделать систему якобы дешевле. В его основе лежит несколько упрощенное и в конечном счете неверное представление о стоимости информационной системы. Ошибка заключается в том, что недооценивается динамика затрат на создание технологического решения, которое функционирует не автономно (как бытовой прибор с двумя-тремя кнопками), а как инструмент для работы организации, то есть довольно сложного сообщества людей, работающих в сложной предметной области.

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

Это происходит потому, что на старте мало кто представляет себе конечное состояние системы – когда ее можно считать готовой. Техническое задание часто не составляется, а если и готовится, то иллюзия дешевизны использования собственных программистов и простоты новых изменений побуждает все время вносить изменения, которые не всегда согласуются с первоначальными целями и чисто инженерными задачами обеспечения устойчивости и архитектурной целостности системы. Кстати говоря, отсутствие или скудость документации – одна из причин, по которым бывает трудно отнести самописные программы к категории программных продуктов (программный продукт должен обладать определенным набором дополнительных материалов, которые делают возможным его нормальную работу в отсутствие авторов).

Кроме того, на стоимость влияют некоторые риски. Пока эти риски «спят», процесс идет нормально. Но как только они реализуются, стоимость разработки может резко и неожиданно вырасти. Типичный пример подобного риска – уход ключевого разработчика системы, то есть того, кто фактически является ее архитектором. В условиях самостоятельной разработки очень многое, если не все, держится на одном специалисте, который знает всю тонкости и имеет непосредственный доступ к исходному коду программы. Если этот специалист по какой-либо причине становится недоступен, то развитие системы останавливается, и его возобновление требует гораздо больших затрат, чем прежде. Можно привести наглядную аналогию со строительством дома: если стройка заморожена, то по прошествии времени недострой сносят и ставят на его месте новое здание, так как возобновление старой стройки зачастую уже невозможно.

Дополнительные затраты при уходе ключевого специалиста связаны, в частности, с отсутствием или крайне фрагментарным состоянием документации. Все знания — в голове одного или нескольких сотрудников. Пока все нормально, никто не задумывается над тем, чтобы зафиксировать на бумаге задачу для программистов или хотя бы составить описание базы данных (наличие такого описания, кстати говоря, критически важно при возобновлении «недостроя» или при переносе данных в другую систему). В случае ухода идеолога или автора системы такие технологические пробелы могут поставить под вопрос не только развитие системы, но и ее нормальную эксплуатацию на уже достигнутом уровне.

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

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

Второй аргумент, который приводят сторонники самостоятельной разработки (ее еще называют inhouse-разработкой): в готовой, тиражной медицинской системе может не оказаться каких-то важных для клиники функций, а в своей программе их точно можно предусмотреть и реализовать в наиболее удобной для себя форме. Конечно, такое мнение может быть обосновано, если руководство уже посмотрело целый ряд готовых систем и убедилось, что не может найти нужную функциональность. Но на деле данная точка зрения часто оказывается предубеждением.

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

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

Если клиника должна автоматизировать сразу большой круг задач, то готовое решение в таких случая однозначно лучше. Например, сложно постепенно автоматизировать «с нуля» клинико-диагностическую лабораторию. Внедрить готовую лабораторную информационную медицинскую систему (ЛИМС) будет и дешевле и быстрее.

Имеет смысл еще немного задержаться на вопросе о настраиваемости систем. Здесь имеются различия как между разными готовыми решениями, так и между готовыми, с одной стороны, и самодельными, с другой. Если некоторые готовые решения оказываются менее гибкими, чем другие тиражные системы, то самодельные решения зачастую вообще не имеют развитых инструментов настройки. Причины этого достаточно банальны: разработчик, необремененный задачами по обеспечению тиражного характера решения, практически всегда ориентирован на том, чтобы побыстрее реализовать функцию в программном коде. Зачем ему создавать дополнительный, управляющий уровень системы, который, к тому же, позволяет выбрать один вариант поддержки функции из нескольких возможных? Трудозатраты оказываются гораздо выше, а выгода, если система делается «под себя», не очевидна.

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

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

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

С переменами в работе должна меняться и информационная система. К сожалению, «домашняя» разработка редко бывает готова к такого рода изменениям и с точки зрения организации производства ПО и с точки зрения его архитектурных особенностей. Эта неготовность становится особенно заметна тогда, когда задачи автоматизации выходят за рамки процессов хозяйственного учета и регистрации пациентов и начинают непосредственно затрагивать повседневную работу врачей. Автоматизация врачей – довольно непростая задача. Здесь приходится учитывать сложность профессии и высокий уровень автономии врачей-профессионалов в процессе диагностики и лечения.

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

Но, соглашаясь в целом с такой постановкой вопроса, надо отметить, что конкурентные преимущества могут быть подкреплены с помощью настроек в готовой, промышленной системе – тех самых настроек, которые, как правило, представлены в промышленном решении, но часто отсутствуют при «домашней» разработке.

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

Для наглядности приведем пример создания дополнительных опций. Коммерческая клиника эксплуатирует программу собственной разработки и добавляет новую функцию – рассылку SMS-сообщений или электронной почты постоянным клиентам с уведомлениями о  записи на прием или о готовности результатов анализов. С точки зрения взаимодействия с пациентами такое новшество может восприниматься как очень заметное изменение сервиса, вряд ли доступное большинству конкурентов. Эмоциональный эффект от такой опции может быть заметным. Но тот же эмоциональный эффект может сослужить плохую службу руководству клиники, если затмит объективную стоимость решения. В этом и подобных случаях реализация новой функции средствами промышленной системы в конечном итоге была бы ниже, а ее устойчивость и, как следствие, долгосрочный эффект от эксплуатации –  выше.

Ключевым фактором для объективной оценки инвестиций в информационные технологии является отношение руководителей к информационной системе. Чем является система для людей, принимающих решения? Что это – дорогая игрушка, поле для профессиональных экспериментов, рабочая лошадка или неустойчивое сочетание первого, второго и третьего? Безусловно, работа по проектированию информационной системы может быть очень увлекательной. На какое-то время она может стать отдушиной в административной рутине. Но со временем энтузиазм проходит, часть работы, иногда очень важная, остается недоделанной, и в результате можно наблюдать множество примеров самодельных программ, в которых бездействуют не только «конкурентные», но и самые насущные функции.

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

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

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

В качестве последнего аргумента в защиту самостоятельной разработки информационной системыт выступает тезис «будем продавать другим». Особенно сильным этот аргумент начинает казаться в тот момент, когда расходы на создание системы выходят за рамки первоначальной сметы (если она была) или (что более вероятно) за рамки ощущения разумной достаточности. Поначалу идея коммерциализации может производить впечатление на инвесторов и других персон, принимающих ключевые финансовоемкие решения. При этом обычно выносится за скобки вопрос о том, как руководители буду сочетать управление сразу двумя разными видами бизнеса: оказанием медицинских услуг и производством программного обеспечения. Считается, что первое безусловно сложнее второго, и раз уж организация может лечить людей, то написать и продать программу и подавно сумеет.

Возможно, косвенным подтверждением мнимой простоты производства ПО могут счесть тот факт, что на рынке коммерческой медицины еще не встречались команды программистов, которые проделали обратный путь – перешли от написания программ к лечению людей (хотя если государство вдруг отменит лицензирование медицинских услуг, то кто знает – может, и такие появятся). Людям свойственно переоценивать сложность своей профессиональной области и преуменьшать сложность других специальностей. И чем менее четкими и более общими являются наши представления о другой профессии, тем проще кажется задача начать новый бизнес в этой области. Неудивительно, что вокруг так много примеров неудачной «диверсификации», о которых, правда, редко можно узнать из открытых источников.

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

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

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