В последнее время за обсуждением модных тем цифровизации и телемедицины остаются в тени вопросы базовой программной инфраструктуры в медучреждениях, которая не подвергалась радикальным изменениям. Между тем ИТ-руководителю медицинской организации полезно иметь представление об устройстве рынка медицинских информационных систем и доминирующих подходах к их построению. Поскольку некоторые важнейшие вопросы управления на уровне клиник до сих пор остаются нерешенными или решаются недостаточно эффективно.
Как полагают аналитики Gartner, одним из самых актуальных направлений работы руководителя ИТ-службы в медицине сегодня является совершенствование учета расходов при оказании медицинских услуг. В медицинских организациях зачастую слабо представляют себе структуру расходов и влияние стратегических решений на финансы. Если на производственных предприятиях для балансировки и оптимизации ресурсов используются ERP-системы, то в медицине многие классические бизнес-подходы плохо применимы. Из-за специфики отрасли — уникальности каждой услуги ввиду уникальности каждого пациента и высокой ответственности за принятые решения — информационные технологии используются в медицине главным образом для получения данных о состоянии здоровья пациента и для ведения медицинской документации. Однако ИТ-потребности клиник гораздо шире.
Для чего больнице ERP?
Основное назначение ERP-системы — управление ресурсами организации, автоматизация взаимодействия служб и расчет себестоимости услуг. Отраслевая специфика добавляет в медицинские ERP дополнительные модули, включая медицинскую информационную систему, выполняющую функции администрирования потоков пациентов, учета взаиморасчетов и ведения медкарт, а также такие вспомогательные системы, как больничная аптека, диетическое питание и клиническая лаборатория. Все модули медицинской ERP являются источниками данных при расчете себестоимости медицинской помощи.
В журнале ERP Solutions Review выделяются две наиболее распространенные цели внедрения медицинской ERP-системы. Во-первых, создание длительно хранимой интегрированной базы данных, куда в режиме реального времени поступают сведения о состоянии здоровья пациентов (electronic health record, EHR — электронной медицинской карты, ЭМК). Ведя медкарты в безбумажном виде, медицинская организация получает возможность оперативно формировать статистические и управленческие отчеты.
Во-вторых, снижение общих затрат на автоматизацию. В ERP-системе ведется централизованный учет пациентов, коек, листов назначений, запасов лекарств и т. д. Благодаря доступу к общей базе данных из любого подразделения, значительно сокращаются расходы, так как исключаются повторный ввод информации и обмен данными между приложениями.
Как устроен крупнейший рынок медицинских систем
Благодаря государственному субсидированию внедрения EHR, США являются одним из мировых лидеров в этой области. К середине 2017 года в программе внедрения EHR приняли участие почти 7,8 тыс. больниц. Примерно половина из них используют решение одного из десяти самых популярных на рынке разработчиков. Каждый из тройки крупнейших вендоров: Epic Systems, Cerner и Meditech — охватывает почти по 1 тыс. клиник. Уточним: Epic — разработчик автономной EHR-системы, а Cerner и Meditech — производители медицинских ERP-систем со встроенными EHR-модулями. Более чем в 1,2 тыс. госпиталей для ветеранов Министерства обороны США используется разработанная этим ведомством система VistA, которая является одновременно ERP- и EHR-системой. Активно действуют на медицинском рынке и поставщики классических ERP-решений: Microsoft, Oracle и SAP.
Лидеры среди ERP и EHR — платформенные системы, созданные в конце 1970-х — начале 1990-х годов. В случае построения ERP- и EHR-систем на разных платформах, как со стороны ERP, так и со стороны EHR задействуются интеграционные механизмы. Чаще всего они основаны на отраслевом стандарте — протоколах организации HL7.
Примером такого симбиоза двух платформ для создания медицинской ERP-системы служат Oracle и Epic: интеграция организована как на технологическом уровне (Oracle Health Management Platform), так и на бизнес-уровне. Многие партнеры Epic являются одновременно и партнерами Oracle, что позволяет им оказывать услуги по созданию медицинской ERP с EHR-модулем.
Следующая по распространенности коммерческая EHR-система — Cerner i.s.h.med, а также лидер среди свободно распространяемого программного обеспечения — VistA используют другой подход: создают единую систему на одной технологической платформе, где есть функции как ERP, так и EHR. Преимущества такого подхода: система имеет единый интерфейс, использует единую базу данных и единую среду разработки, интеграционных швов в ней нет.
Почему выигрывают платформы
Основная задача технологической платформы — повысить уровень абстракции при разработке прикладных решений. Платформа позволяет перейти от технических и низкоуровневых понятий к языку пользователей и специалистов в предметной области. Тем самым унифицируется и значительно ускоряется разработка прикладного решения и упрощается его сопровождение.
В технологических платформах имеется CASE-средство разработки, которое дает возможность создавать программы путем манипулирования графическими объектами вместо написания текста. Технологические платформы имеют собственные языки программирования 4-го поколения. Это высокоуровневые предметно-ориентированные языки, пригодные для визуального программирования, то есть программирования с помощью формирования различных схем.
Бизнес-логика прикладного решения описывается на предметно-ориентированном языке и обычно поставляется в его составе в исходных кодах. Сама платформа не является конечным программным продуктом. Пользователи работают с одним из многих прикладных решений, разработанных и выполняющихся на платформе. Таким образом, различные виды деятельности можно автоматизировать, опираясь на общую технологическую базу.
Индустриальный подход и партнерская модель
Все ведущие поставщики ERP/EHR используют партнерскую бизнес-модель, подразумевающую трехуровневое взаимодействие: вендор разрабатывает технологическую платформу и прикладные решения с отрытым исходным кодом бизнес-логики, партнеры адаптируют платформу под конкретного клиента и разрабатывают собственные решения на ее базе, а клиенты используют для автоматизации прикладные решения.
Это позволяет применять принципы разделения труда и индустриальный подход к разработке прикладных решений (см. рис. 1).
Платформа разрабатывается вне зависимости от отрасли и включает передовые технологии и стандарты. Центральные прикладные решения (CRM, ERP и др.) с открытым кодом бизнес-логики разрабатывает вендор. Отраслевую специфику в решение вносят партнерские компании, а специфику конкретного предприятия — партнер или ИТ-служба клиента. Заказчик получает решение с открытым кодом бизнес-логики, которое может сопровождать любая партнерская компания или его собственная ИТ-служба.
.png) |
| Рис. 1. Поддержка партнерской бизнес-модели платформами |
В платформу встраиваются технические средства поддержки внесения изменений, что позволяет существенно снизить затраты на сопровождение внедренного прикладного решения.
Каждому — по отдельной «квартире»
Все упомянутые выше поставщики платформенных медицинских ERP (Cerner, Epic, Microsoft, Oracle, SAP и VistA) предлагают два варианта использования своих ключевых продуктов: установку на локальном оборудовании клиента и подключение к облачному сервису по модели «программное обеспечение как услуга» (SaaS).
В первом случае на одну медицинскую ERP-систему создается одна или несколько баз данных. Организация владеет своими данными, которые хранятся на серверах в локальной сети. Модули медицинской ERP взаимодействуют между собой напрямую в рамках локальной сети. При необходимости обмен сведениями о состоянии здоровья пациентов между организациями производится через внешние механизмы, например через интеграционную шину.
В облачном приложении данные хранятся в ЦОДе в общей для всех медицинских организаций БД в режиме разделения данных. Каждой медицинской организации выделяется собственная область в базе данных, причем эти области изолированы.
Обычное приложение можно сравнить с коттеджем на одну семью, которая пользуется его инфраструктурой (стены, крыша, водоснабжение, отопление и т. п.). А облачное приложение похоже на многоквартирный дом, где каждая семья пользуется инфраструктурой того же состава, но сама инфраструктура служит всему дому целиком.
Цель облачных приложений — снизить расходы на поддержание приложения путем «обобществления» расходов на инфраструктуру. С точки зрения поставщика, это примерно то же самое, что и снижение стоимости приложения посредством применения тиражного решения (с возможностью настройки и доработки) вместо написания ПО под заказ. Только в одном случае обобществляется разработка, а в другом — эксплуатация. Этот подход подразумевает не только иную организацию хранения данных, но и модель работы приложения в целом, включая аспекты его архитектуры, модель развертывания и организацию обслуживания.
В случае использования медицинской ERP как облачного приложения схема обмена данными в рамках одной организации меняется: обмен производится не между модулями системы /приложениями, а между областями данных. Для обеспечения работы медицинской ERP организации как единого целого используется специальная интеграционная шина — менеджер сервиса. Менеджер знает, какая область данных к какой организации относится, и обеспечивает обмен между ними.
Под запросы клиники
Чтобы сохранить ключевое преимущество технологических платформ в облачных приложениях — возможность быстрой адаптации приложений по запросам медицинских организаций, используется технология расширений.
Изменения прикладного решения выполняются в расширении. Расширение подключается к области данных облачного прикладного решения. В результате каждая медицинская организация работает с собственным решением, измененным в соответствии с ее требованиями, а код прикладного ПО остается неизменным.
Когда поставщик выпускает новую версию прикладного решения, платформа автоматически объединяет новую версию с расширением и клиент продолжает работать с приложением, модифицированным под его потребности.
Рост в условиях облачности
Для локальных приложений задача увеличения числа подключаемых пользователей обычно решается установкой более производительного оборудования (вертикальное масштабирование) или кластеризацией серверов приложений и серверов управления базами данных (установка дополнительных серверов).
В случае установки более производительного оборудования рост его стоимости по отношению к мощности происходит нелинейно. То есть после достижения определенного предела увеличивать производительность становится слишком дорого.
При кластеризации серверов приложений и серверов управления базами данных также не наблюдается линейного увеличения производительности с увеличением числа серверов, поскольку обработка общих данных на нескольких серверах требует накладных расходов, которые растут с числом серверов. Как правило, после установки в кластер более трех серверов производительность увеличивается лишь незначительно.
Для облачных приложений появляется еще одна возможность масштабирования — увеличение числа узлов облачного приложения. Узел — это самодостаточный набор серверов для обслуживания одной базы данных приложения. В состав узла входят серверы / кластер серверов СУБД, приложений и службы публикаций. В одной базе данных может находиться информация нескольких организаций.
При достижении критического числа конкурентных пользователей или объема базы данных к облачному приложению может быть подключен дополнительный узел. Таким образом, достигается практически линейное увеличение производительности с ростом числа узлов.
Для обеспечения одновременного обновления прикладных решений и технологической платформы во всех узлах используется служба публикаций.
Общая схема горизонтального масштабирования облачного приложения приведена на рис. 2.
.png) |
| Рис. 2. Схема горизонтального масштабирования облачного приложения |
Большинству из упомянутых технологических платформ 30 лет и даже более. Однако приложения, созданные на этих платформах, успешно адаптировались к новым условиям и облачным технологиям и сохранили свои позиции в секторе медицинских ERP. Платформенный подход доказал свою жизнеспособность, и этот факт несомненно стоит учесть при разработке стратегии развития ИТ медицинской организации.
Авторы: Гайдуков Алексей - руководитель разработки 1С:Медицина, gaya@1c.ru;
Игумнова Надежда - методист, igud@1c.ru