Электронная медицинская карта

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

Как полагают аналитики 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

Трое из четырех врачей в США убеждены: внедрение систем электронных медицинских карт (electronic healthcare records, EHR) приводит к увеличению затрат, причем эти затраты перевешивают экономию, которую дает повышение эффективности. А семеро из десяти полагают, что EHR снижают производительность труда медицинского персонала.

В опубликованном Deloitte отчете «2016 Survey of US Physicians» говорится, что за два года, прошедших со времени предыдущего опроса, мало что изменилось и доктора по-прежнему сохраняют негативное мнение о системах электронных медкарт. Почти все хотят, чтобы системы EHR улучшились: 62% сообщили о необходимости повысить их интероперабельность, а 57% считают, что нужно улучшать технологические процессы и добиваться роста производительности.

Компания Deloitte организует опросы врачей в масштабах США начиная с 2011 года. В последнем, проведенном весной, принимали участие 600 респондентов. Но об отрицательном отношении врачей к системам электронных медкарт свидетельствует не только опрос Deloitte.

Опубликованные в июле журналом British Medical Journal (BMJ) результаты обследования 17 больниц в США показали, что в долгосрочной перспективе влияние EHR на результаты лечения пациентов будет крайне незначительным, а в ближайшем будущем – даже негативным.

В исследовании Deloitte, проводившемся специалистами Гарвардского университета и больницы Brigham and Women's Hospital, говорится, что внедрение новой системы электронных медкарт или переключение на другую ее версию предсказуемо несет разрушительные последствия и затрагивает «практически каждого работника и каждый процесс».

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

Системы электронных медицинских карт стали обязательными в США после принятия в 2009 году Закона о применении медицинских информационных технологий в экономической деятельности и клинической практике (Health Information Technology for Economic and Clinical Health Act, HITECH). Закон установил три фазы для подтверждения «существенного использования » (Meaningful Use) интероперабельных электронных медкарт. Поставщики медицинских услуг, внедрившие у себя системы EHR, получали определенные привилегии. Отказавшиеся лишались денежного возмещения по программам Medicaid и Medicare. Под программу, стимулирующую «существенное использование», попали подавляющее большинство больниц и частнопрактикующих врачей, внедривших у себя системы EHR.

В прошлом году, однако, центры государственной медицинской помощи (Centers for Medicare & Medicaid Services, CMS) решили заменить программу Meaningful Use и ввести новые правила, предусматривающие поощрение врачей в зависимости от результатов проведенного лечения. В принятом в 2015 году законе MACRA (Medicare Access and CHIP Reauthorization Act) описывается новая система стимулирования MIPS (Merit-Based Incentive Payment System). Система включает в себя компоненты трех существующих программ, учитывающих качество врачебных услуг, их стоимость и применение технологий: Physician Quality Reporting System (PQRS); Physician Value-Based Payment Modifier (VM) и Medicare EHR Incentive Program. Предлагается также стимулировать использование некоторых альтернативных моделей оплаты (alternative payment models, APM).

«На смену мерам стимулирования, предусмотренным в программе Meaningful Use, приходят сейчас более эффективные меры стимулирования, – написал в своем блоге доктор Митч Моррис, возглавляющий в Deloitte Consulting направление Global Life Sciences and Health Care Industry. – Программа MACRA оценивает врачей по четырем основным критериям: качество лечения, стоимость лечения, использование новых технологий и улучшение результатов».

Окончательный вариант стимулирующих мер, соответствующих требованиям закона 2015 года, был сформулирован в начале сентября 2016 года и находится на рассмотрении в Белом доме. Ожидается, что он будет принят 1 января 2017 года. В опросе Deloitte 2016 года, в котором принимали участие врачи, оказывающие первую помощь, и специалисты отдельных направлений, содержалось несколько новых вопросов о MACRA.

В законе MACRA больше внимания уделяется интероперабельности систем EHR, этот показатель считается ключевым для повышения производительности труда и улучшения результатов лечения. Президент Американской медицинской ассоциации Стивен Стек заявил, что именно из-за отсутствия интероперабельности потенциал систем EHR используется недостаточно полно.

«Конгресс поставил интероперабельность во главу угла при принятии закона MACRA», – писал Моррис в своем блоге.

По мнению директора IDC Health Insights по исследованиям Синтии Бургард, несмотря на все недочеты, в системах EHR есть много положительного. Они представляют собой транзакционные системы и репозитарии данных, а не аналитические и не процессные системы. Возможно, такие системы и не повышают производительность труда, но они имеют ключевое значение для оформления документации, выдачи указаний и назначения лечения.

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

Эту точку зрения разделяет и Моррис.

Несмотря на то что, как свидетельствуют результаты опроса Deloitte, большинство врачей негативно относится к системам EHR, это вовсе не означает, что программа Meaningful Use провалилась. В частности, 78% опрошенных убеждены в том, что системы EHR гораздо больше способствуют проведению анализа и составлению отчетности, чем улучшению результатов лечения. «По сравнению с 2014 годом этот процент вырос, – пишет Моррис. – Вместе с тем готовы отказаться от систем EHR лишь немногие: трое из пяти опрошенных предпочли бы сохранить существующую систему EHR и не заменять ее».

Врачам, имеющим частную практику, внедрение систем EHR обходится в десятки тысяч долларов, крупные больницы и медицинские центры тратят на это десятки миллионов долларов, тем не менее инвестиции в технологию окупаются. К примеру, в 2007 году в Brigham and Women's Hospital пришли к выводу, что ежегодная экономия после внедрения компьютеризированной системы назначения лечения (computerized physician order entry, CPOE), позволившей на 55% снизить число серьезных врачебных ошибок, составляет от 5 до 10 млн долл. Больницы сообщали также об экономии за счет отказа от хранения бумажных медицинских карт и обеспечения электронного доступа к отчетам и результатам лабораторных анализов.

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

– Lucas Mearian. Doctors: E-health records raise costs, don’t help patient outcomes. Computerworld, Sep 29, 2016