CC BY
38
Госпитальные АИС
www.idmz.nu SOOS, №3
А.Г. БОРИСОВ,
генеральный директор компании «Пост Модерн Текнолоджи», г. Москва, info@pmtech.ru
МИС: ПРОМЫШЛЕННОЕ РЕШЕНИЕ ИЛИ ВНУТРЕННЯЯ РАЗРАБОТКА?
УДК 004.912
Борисов А.Г. МИС: промышленное решение или внутренняя разработка?
Аннотация: Статья посвящена анализу рисков разработки медицинских информационных систем силами IT-персонала ЛПУ. Авторы проводят качественное сопоставление показателей стоимости, гибкости и функциональной полноты собственных разработок ЛПУ и комплексных промышленных решений. Ключевые слова: медицинская информационная система, разработка программного обеспечения (ПО), стоимость разработки ПО, риски разработки ПО.
UDC 004.912
BorisovA.G. MIS: industrial solutions or in-house medical software development
Abstract: The article is dedicated to the risks of in-house medical software development implemented by IT-personel of clinics. The authors present a qualitative contrastive analysis for costs, flexibility and functionality of in-house products and integrated industrial solutions.
Keywords: healthcare information systems industrial solutions, risks of in-house medical software development, risks of software production
I
I
Врачи предупреждают об опасности самолечения. А граждане продолжают заниматься этим увлекательным делом. Удивительно, но в сфере информационных технологий и автоматизации медицинских учреждений дело обстоит почти таким же образом. Профессиональные разработчики предупреждают — создание самописных программ опасно для здоровья организации. И, тем не менее, руководители ЛПУ с завидным упорством продолжают заниматься «самолечением».
Почему же у многих возникает соблазн сделать свою медицинскую информационную систему? В качестве аргументов «за» такое решение обычно приводятся три соображения: а) так дешевле;
б) получится продукт, выкроенный точно по меркам организации, а в тиражной системе чего-то может не хватать;
в) будем продавать другим.
Рассмотрим аргумент первый — сделать самим дешевле. Это иллюзия, которая основывается на статическом представлении о стоимости информационной системы. В действительности стоимость решения следует рассматривать в динамике. Сторонники самостоятельной разработки, как правило, не знают, что динамика затрат на тиражную систему противоположна динамике затрат на создание собственной. При покупке промышленного решения основной объем затрат приходится на начальный период, когда оформляется приобретение прав на продукт и внедряется основной объем функционала. Затем затраты снижаются и стабилизи-
© А.Г. Борисов, 2009 г.
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 49 ■
Госпитальные А1/1С
и информационные
технологии
руются на уровне расходов на поддержку до того момента, пока руководством не будут поставлены новые амбициозные задачи. При разработке собственной системы дело обстоит ровно наоборот — расходы растут с каждым новым этапом.
Кроме того, у самописных систем имеется существенный фактор риска — уход архитектора информационной системы. Дело в том, что в условиях самостоятельной разработки очень многое, если не все, держится на одном специалисте, который знает все нюансы и, как правило, имеет непосредственный доступ к исходному коду программы. В наиболее одиозных случаях уход такого специалиста может сопровождаться исчезновением исходного кода программы. Если этот человек по какой-либо причине становится недоступен, то развитие системы останавливается, и его продолжение требует уже гораздо больших затрат, чем прежде.
Эти дополнительные затраты связаны, в частности, с отсутствием или крайне фрагментарным состоянием документации. Все знания — в голове одного или нескольких сотрудников. Пока все нормально, никто не задумывается над тем, чтобы формализовать постановку задачи или хотя бы составить описание базы данных. В случае ухода идеолога или автора системы такие технологические пробелы могут поставить под вопрос не только развитие системы, но и ее нормальную эксплуатацию на достигнутом уровне.
Профессиональные компании-разработчики умеют минимизировать подобные риски. Они технологизируют свои производственные процессы таким образом, чтобы продукт меньше зависел от отдельных людей, сколь бы высока не была их квалификация и место в иерархии управления производством. Профессиональный разработчик обязательно обеспечит заказчику и документацию, и «горячую линию» поддержки.
Существует множество примеров некогда с энтузиазмом начатых, а затем брошенных
информационных систем, которые тяжелым грузом висят на ногах руководителей ЛПУ. Особенно заметным это бремя становится при попытке продолжить развитие некогда начатой информационной системы с новыми людьми и новыми технологиями. Ведь при этом нужно извлечь данные и ноу-хау, похороненные в недрах умершей системы. Чтобы обеспечить преемственность, приходится нести дополнительные затраты.
Второй аргумент, который приводят энтузиасты inhouse-разработки, — в тиражной медицинской системе может не оказаться важных для клиники функциональных блоков. Это тоже предубеждение. В промышленной медицинской информационной системе (МИС) большинство необходимых функций, как правило, имеются. Кроме того, недостающие производитель может доработать. И сделает он это намного быстрее и качественнее, нежели «домашний» программист. Качество же в данном случае означает не только надежность работы программы, но в том числе и сохранение целостности решения, его способности к развитию. При выборе продукта нужно просто внимательно анализировать продукты и выбрать тот, который решает не только насущные задачи, но и имеет задел на будущее.
Проблема в том, что «горизонт» готовых к автоматизации задач ЛПУ расширяется постепенно. Сначала руководство видит перспективу в использовании ИТ на одном участке, скажем, в учете услуг. Затем осознается возможность и даже необходимость включения в информационную систему лечебного процесса. При самостоятельной разработке весь этот путь медучреждение проходит «наощупь», повторяя открытия и ошибки сотен клиник с похожими задачами и проблемами.
Если клиника планирует автоматизировать сразу большой спектр задач, то готовое решение в таких случая однозначно лучше. Например, сложно постепенно автоматизировать «с нуля» диагностическую лаборато-
■■■ -ео- ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Госпитальные АИС
рию. Внедрение готовой лабораторной системы точно обойдется дешевле.
Настраиваемость системы — отдельная тема. Практика показывает, что самодельные решения, как правило, практически не имеют возможностей по настройке. Оно и понятно: разработчику гораздо быстрее реализовать функцию в программном коде, чем создавать дополнительный, управляющий уровень системы, который к тому же позволяет выбрать один вариант поддержки функции из нескольких возможных. В последнем случае трудозатраты гораздо выше, а выгода, если система делается «под себя», далеко не очевидна. Иными словами, обеспечение адаптивности системы — это очень дорого. Поэтому в само-писных системах эти возможности практически не встречаются. В итоге сопровождение опять замыкается на конкретного программиста. Тем самым опять усиливаются риски, связанные с его возможным уходом.
У разработчиков тиражного решения другая мотивация. Они готовы идти на дополнительные трудозатраты при создании настроечных механизмов, если известно, что решение приобретет много пользователей. Экономический эффект на единицу трудозатрат в тиражном решении является более высоким. Это и стимулирует разработчиков к созданию гибких решений, которые подойдут максимально более широкому кругу пользователей.
Понимание важности настроечного механизма приходит не сразу. Проходит какое-то время, прежде чем руководство ЛПУ осознает, что автоматизация — вещь нестатичная, что со временем бизнес-процессы клиники приходится менять. И дело не только в росте объема услуг или хранимых данных, которые требуют более емкого и мощного оборудования. Накапливаются организационные изменения, возникают новые потребности, новое понимание повседневных и стратегических задач.
В результате рано или поздно должна измениться и информационная система. К сожалению, внутренняя разработка редко
www.idmz.nu SOOS, №3
бывает приспособлена к такого рода изменениям. Особенно когда речь идет не только об автоматизации учета или регистратуры, но об информационной поддержке лечебного процесса. Известно, что автоматизация врачей
— довольно тонкая и нетривиальная задача, учитывая сложность профессии и уровень автономии врачей-профессионалов в принятии решений.
Довольно часто в качестве одного из основных аргументов в пользу «домашней» разработки можно услышать такой довод, что только таким образом клиника может реализовать в информационной системе свои конкурентные преимущества. Следует признать
— медицинская информационная система действительно может быть конкурентным преимуществом коммерческой клиники. Она может закрепить и усилить такие организационные и технологические решения, поддержка которых без автоматизации требует существенно больших усилий или просто невозможна.
Однако, соглашаясь в целом с такой постановкой вопроса, необходимо отметить, что важные особенности и конкурентные преимущества могут быть подкреплены с помощью настроек в готовой промышленной системе. Тех самых настроек, которые, как было показано выше, заложены в промышленном решении, но отсутствуют при домашней разработке.
Кроме того, с точки зрения объема работ, необходимых для создания единой информационной системы ЛПУ, поддержка неких особенных функций или процедур — это скорее дополнительное удобство, но не решение ключевых задач. Наиболее массивная и трудоемкая часть потребностей в средствах автоматизации у разных медучреждений является схожей. Она может быть обеспечена средствами тиражной МИС при наличии у нее хорошо проработанного функционала и достаточной адаптивности к разнообразию бизнес-процессов разных ЛПУ. Надо сказать
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 51 ■
Госпитальные А1/1С
и информационные
технологии
со всей определенностью, что основная часть процедур (а именно они являются первоочередным объектом автоматизации) являются общими для подавляющего большинства медицинских организаций.
Приведем простой пример создания дополнительных опций. Коммерческая клиника имеет ИС собственной разработки и добавляет новую функцию — рассылка SMS-сообщений или автоматических электронных писем постоянным клиентам. Это могут быть уведомления о записи на прием или о готовности результатов анализов. Конечно, с точки зрения взаимодействия с пациентами, такой шаг может восприниматься как очень заметное изменение в организации сервиса, которое к тому же имеется пока у очень немногих конкурентов. Психологический эффект от такой опции может быть значительным. Но тот же психологический эффект может сослужить плохую службу руководству клиники, если затмит объективную стоимость решения. В этом и многих подобных случаях реализация подобной функции средствами промышленной системы в конечном итоге будет ниже, а ее устойчивость и, как следствие, долгосрочный эффект от эксплуатации будут выше.
Очень важно отношение руководителей к информационной системе. Что это — дорогая игрушка или рабочая лошадка? Конечно, работа по созданию информационной системы может быть очень увлекательной, может на какое-то время стать отдушиной в повседневной административной рутине. Но со временем энтузиазм проходит, часть работ, иногда очень важная, остается недоделанной, и в результате можно наблюдать множество примеров самодельных систем, в которых не работают не только «конкурентные», но и самые простые функции.
Профессиональные разработчики промышленных медицинских систем радикально снижают риски медучреждения. Простой пример: получить сертификацию на соответствие требованиям закона о безопасности персональ-
ных данных будет существенно проще и дешевле, работая с тиражной системой. Почему? Да хотя бы потому, что разработчики тиражной системы озаботились этой проблемой еще до того, как соответствующие требования вступили в силу. Чтобы решить данную проблему наиболее экономичным и качественным способом, они поддерживают контакт с отраслевыми ассоциациями, органами государственного управления, экспертами. Наконец, в промышленной разработке подобные задачи рассматриваются в комплексе с развитием архитектуры информационной системы и всех технологических процессов по ее разработке, внедрению и технической поддержке.
К сожалению, даже среди опытных менеджеров распространен стереотип — написать программу легко. Но так ли это? И принимаем ли мы во внимание колоссальное различие между компьютерной программой и комплексной информационной системой?
Используя образные сравнения, можно сказать, что идея самостоятельной разработки информационной системы не сильно отличается от идеи своими силами изготовить мебель для медучреждения. Вполне возможно, что такая мебель окажется гораздо более индивидуальной и будет полностью соответствовать самым специфическим запросам врачей и медперсонала. Но какова будет цена подобного решения? И почему так трудно найти ЛПУ с самодельной мебелью, но не надо далеко ходить, чтобы увидеть клинику, которая сама для себя пишет программное обеспечение?
В качестве последнего аргумента в защиту самостоятельной разработки ИС выступает тезис «будем продавать другим». Особенно сильным этот аргумент начинает казаться в тот момент, когда расходы на создание системы выходят за рамки первоначальной сметы. И поначалу такие соображения могут производить впечатление на инвесторов, на людей, принимающих решения. К сожалению, при этом выносится за скобки вопрос о том, как руководители буду сочетать управление
1 52 ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ ■
Госпитальные АИС
сразу двумя разными видами бизнеса: оказанием медицинских услуг и производством программного обеспечения. По умолчанию считается, что первое, безусловно, сложнее второго, и раз уж можем лечить людей, то написать и продать программу сумеем и подавно.
Возможно, одним из аргументов в пользу такого мнения служит то обстоятельство, что на рынке коммерческой медицины еще не встречались команды разработчиков ПО, которые проделали обратный путь: перешли от написания программ к лечению людей. Хотя, если государство вдруг отменит лицензирование медицинских услуг, кто знает, может, и такие появятся. Людям свойственно переоценивать сложность своей профессиональной области и преуменьшать сложность других профессий. И чем более общими являются наши представления о другой профессии, тем проще кажется задача начать новый бизнес в этой области. Неудивительно, что вокруг так много примеров подобной неудачной «диверсификации».
Производство продукта, рассчитанного на разные подходы и разных пользователей, сложнее, чем производство продукта, который предназначен только для одной организации. И чем сложнее продукт, тем сложнее
www.idmz.nu SOOS, №3
организовано его производство. Поэтому отдельные случаи продажи самодельных программ другим клиникам связаны обычно с большим сходством в профиле деятельности и постановке работы.
Учитывая все вышеизложенное, можно прогнозировать, что собственные разработки постепенно будут уходить в прошлое. Хотя отдельные попытки переиграть естественный порядок вещей будут, наверное, всегда. Медицинские учреждения отказываются от попыток писать собственно ПО не только потому, что содержать штат программистов дороже, чем купить систему на стороне. Ведь, кроме текущих расходов, есть еще инвестиции в развитие технологии и квалификацию разработчиков, в R&D — research and development (исследования и развитие).
Для собственных разработок характерно отсутствие «эффекта масштаба». Компании-разработчики ПО в каждый новый проект привносят опыт и технологии, наработанные ими в проектах не только на похожих клиентах, но и клиниках другого профиля, что придает промышленному решению и более богатые возможности, и гибкость настроек, и принципиально более высокий уровень надежности.
Органайзер
Ш1
Ш1
Конференция
ДРУЗЬЯ НАЦИОНАЛЬНОЙ МЕДИЦИНСКОЙ БИБЛИОТЕКИ. ПЕРСОНАЛЬНЫЕ ЭЛЕКТРОННЫЕ ДАННЫЕ ЗДОРОВЬЯ: ОТ БИОМЕДИЦИНСКИХ ИССЛЕДОВАНИЙ К ЗДОРОВЬЮ ЛЮДЕЙ
(2009 Conference Friends of the National Library of Medicine.
Personal Electronic Health Records: From Biomedical Research to People's Health)
Дата проведения: 20-21 мая 2009 года
Место проведения: National Institute of Health, Natcher Conference Center, 9000 Rockville Pike, Bethesda, MD
Подробная информация на сайте https://ww2.eventrebels.com/er/Registration/Landing-PageEntry.jsp?ActivityID=3759
■ ■ ■ ■ ■ ■■ ■ ■ ■ ■■■ ■ ■ ■ ■■ ■ ■ ■■■ ■ ■ ■ ■ 53 ■
