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

Как полагают аналитики 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 и др.) с открытым кодом бизнес-логики разрабатывает вендор. Отраслевую специфику в решение вносят партнерские компании, а специфику конкретного предприятия — партнер или ИТ-служба клиента. Заказчик получает решение с открытым кодом бизнес-логики, которое может сопровождать любая партнерская компания или его собственная ИТ-служба.

Рис. 1. Поддержка партнерской бизнес-модели платформами

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

Каждому — по отдельной «квартире»

Все упомянутые выше поставщики платформенных медицинских ERP (Cerner, Epic, Microsoft, Oracle, SAP и VistA) предлагают два варианта использования своих ключевых продуктов: установку на локальном оборудовании клиента и подключение к облачному сервису по модели «программное обеспечение как услуга» (SaaS).

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

В облачном приложении данные хранятся в ЦОДе в общей для всех медицинских организаций БД в режиме разделения данных. Каждой медицинской организации выделяется собственная область в базе данных, причем эти области изолированы.

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

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

В случае использования медицинской ERP как облачного приложения схема обмена данными в рамках одной организации меняется: обмен производится не между модулями системы /приложениями, а между областями данных. Для обеспечения работы медицинской ERP организации как единого целого используется специальная интеграционная шина — менеджер сервиса. Менеджер знает, какая область данных к какой организации относится, и обеспечивает обмен между ними.

Под запросы клиники

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

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

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

Рост в условиях облачности

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

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

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

Для облачных приложений появляется еще одна возможность масштабирования — увеличение числа узлов облачного приложения. Узел — это самодостаточный набор серверов для обслуживания одной базы данных приложения. В состав узла входят серверы / кластер серверов СУБД, приложений и службы публикаций. В одной базе данных может находиться информация нескольких организаций.

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

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

Общая схема горизонтального масштабирования облачного приложения приведена на рис. 2.

Рис. 2. Схема горизонтального масштабирования облачного приложения

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

Авторы: Гайдуков Алексей - руководитель разработки 1С:Медицина, gaya@1c.ru;

Игумнова Надежда - методист, igud@1c.ru