CC BY
1
ОРИГИНАЛЬНАЯ СТАТЬЯ
ОС1: 10.21045/1811-0185-2024-Б-33-52 УДК 004.414
ПОДХОДЫ К РАЗРАБОТКЕ
КОНЦЕПТУАЛЬНОЙ МОДЕЛИ АРХИТЕКТУРЫ ЦИФРОВОЙ МЕДИЦИНСКОЙ ЭКОСИСТЕМЫ
А.Е. Михеев н
ФГБУН «Институт программных систем им. А.К. Айламазяна» Российской академии наук, г. Переславль-Залесский, Россия. https://orcid.org/0000-0002-4777-2732.
И Автор для корреспонденции: Михеев А.Е.
АННОТАЦИЯ
До настоящего времени ни в академических кругах, ни в медицинском и ИТ сообществах не сформировано единого мнения, какой должна быть архитектура медицинской экосистемы. В связи с ориентированностью медицинских экосистем, в отличие от иных бизнес-экосистем, в первую очередь на удовлетворение потребностей пациентов в здоровье-сбережении, а также в связи с постоянными изменениями в мире ИТ и современном бизнесе, работа по согласованию бизнеса и ИТ в интересах пациентов в медицинской экосистеме приобретает особое значение. Предлагается использовать подход, основанный на концепции архитектуры предприятия (АП), которая уже в течение достаточно длительного времени использовалась для разработки информационных систем, в сочетании с подходом, основанном на управлении ИТ-сервисами. В данной статье приводится обоснование использования концепции АП совместно с управлением ИТ-сервисами для согласования потребности бизнеса и информационных технологий при разработке архитектуры медицинской экосистемы. Цель данной статьи - дать общее представление об использовании АП для решения проблем совместного создания ценностей в рамках медицинской экосистемы средствами информационных технологий. Также в статье представлен фреймворк TOGAF как один из наиболее перспективных общих фреймворков для разработки архитектуры медицинской экосистемы. В качестве экосистемного продукта описан массив медицинских услуг экосистемы, также описаны основные артефакты и система управления экосистемы. Настоящая статья может стать отправной точкой для разработки архитектуры медицинской экосистемы с использованием существующих архитектурных фреймворков или для разработки специализированных фреймворков для применения в этой области.
Ключевые слова: цифровая экосистема медицинской помощи, медицинская информационная система, МИС, электронная медицинская карта, ЭМК, согласование бизнес-моделей и ИТ, информационные системы, архитектура предприятия, фреймворк АП, TOGAF, личный кабинет пациента, ИИ, искусственный интеллект, большие данные, большой банк клинических данных.
Для цитирования: Михеев А.Е. Подходы к разработке концептуальной модели архитектуры цифровой медицинской экосистемы. Менеджер здравоохранения. 2024; 5:33-52. DOI: 10.21045/1811-0185-2024-5-33-52
Введение
работе [1] обосновывается важность , перехода к медицинским экосистемам, а также рассматриваются проблемы их создания. Чтобы наметить пути решения означенных проблем, предлагается использовать подход, основанный на концепции архитектуры предприятия1 (АП, англ. Enterprise Architecture, EA), которая уже в течение достаточно длительного времени использовалась для разработки информационных систем (ИС) в сочетании с подходом, основанном на управлении ИТ-сервисами. В данной статье также приводится обоснование использования концепции АП совместно с управлением ИТ-сервисами для
1 Википедия/ https://ru.w¡k¡ped¡а.org/w¡k¡/Архитектура-предприятия. Доступ: 12.11.2024.
согласования потребности бизнеса и информационных технологий при разработке архитектуры медицинской экосистемы.
В связи с ориентированностью медицинских экосистем на удовлетворение потребностей конечных пользователей (пациентов) в здоровьесбережении, в отличие от иных бизнес-экосистем, а также в связи с постоянными изменениями в мире ИТ и современном бизнесе, работа по согласованию бизнеса и ИТ в интересах пациентов становится очень важной. Работа является продолжением исследований, начатых в работах [1, 2, 3]. Далее будут рассмотрены:
1) Подход к процессу проектирования архитектуры цифровой медицинской экосистемы. Архитектура предприятия и фреймворк ТООАР.
2) Цифровая трансформация в рамках медицинской экосистемы: объединение подходов на основе
•КС
© Михеев А.Е, 2024 г.
Manager
Zdravoochranenia
/Менеджер
здравоохранения
АП и сервис-ориентированной архитектуры для совместного создания ценностей в экосистеме.
3) Особенности медицинской экосистемы: эко-системный продукт и проактивное взаимодействие с пациентом.
4) Информация и данные экосистемы.
5) Подход к проектированию интеграционной архитектуры медицинской экосистемы.
6) Управляющая компания и платформа управления (оркестровки) процессом совместного создания ценностей.
7) Обсуждение предложенного подхода и выводы.
Подход к процессу проектирования архитектуры цифровой медицинской экосистемы
Согласно тенденциям цифровой экономики и продвигая единый системный подход к обработке клинических данных, при проектировании архитектуры цифровых медицинских экосистем необходимо учитывать настоящие и будущие вызовы современного мира, изменения окружающей среды при реализации пациентоцентричности совместного создания ценностей, включая:
• особенности развития современных МИС, новые подходы к организации медицинской помощи, развитие биомедицинских технологий, медицинской информатики, информационных технологий и прочего;
• объективные и субъективные потребности отдельных МО и их совокупности, не всегда объединяемые общей целью и, как правило, не принадлежащие одному юридическому лицу и не связанные общей формой собственности;
• консервативность медицинского сообщества. То есть, необходимо предусмотреть гибкость
и адаптивность архитектуры экосистемы. Очевидно, что не обойтись без моделирования цифровой медицинской экосистемы. С этой целью архитектура экосистемы рассматривается как архитектура предприятия (АП) - практика проектирования, планирования и управления общей структурой и работой организации, связанная с согласованием технологий, процессов, интересов членов организации (сотрудников и подразделений) с ее бизнес-целями и стратегией. Мы считаем, что в связи с возникновением новых типов предприятий вследствие развития электронного бизнеса, электронной коммерции, активного внедрения ИТ в деятельность компаний, концепция АП - одно из
наиболее перспективных направлений, позволяющее при правильной методологии использования не только поддержать инициативы по созданию медицинских экосистем, но и предложить новые подходы для успешной работы многим современным МО в условиях перехода к цифровой экономике.
Такой подход поддерживается и рядом других исследователей, которые считают, что использование концепции АП может стать позитивным фактором для создания бизнес-экосистем в здравоохранении [4, 5], так как на основе архитектур разных уровней (бизнес-архитектуры, архитектуры данных, архитектуры приложений и архитектуры технологий) позволяет сформировать такую структуру экосистемы, в соответствии с которой взаимодействие с бизнес-средой осуществляется в рамках экоси-стемного или корпоративного континуума.
По своей сути АП помогает понять, как взаимосвязаны различные системы организации, процессы и «подразделения», как их можно оптимизировать для более эффективной совместной работы, как адаптироваться к изменениям, предоставляя основу для контролируемого внедрения новых технологий и процессов в рамках выбранной стратегии [6]. В работе [7] предложено представление концепции АП в виде куба, который мы делим по трем измерениям на компоненты, сегменты и уровни, как показано на рисунке (рис. 1):
Рис. 1. Кубическое представление основных элементов анализа и проектирования АП ([адаптировано по [7])
Менеджер
здравоохранения /
Мападег
2024
• компоненты - структурные элементы предприятия (системы), включая подразделения, базы данных, продукты, услуги, стандарты, политики, ИТ-системы и т.п., а также цели действий, принципы деятельности, функции участников (людей и подразделений), процессы и ограничения;
• сегменты - совокупность сквозных компонентов предприятия, образующая направления деятельности;
• уровни - иерархическая структура детализации общего каркаса АП, где стратегические инициативы предприятия находятся на самом верху, а технологии и инфраструктура - на базовом (нижнем) уровне.
Модель архитектуры медицинской экосистемы, описанная с использованием концепции АП в общем случае предполагает наличие:
1. Описания экосистемного продукта2 и всех других элементов экосистемы, включая их назначение, функционал и пр.
2. Описания подходов к управлению этими элементами для достижения стратегических целей экосистемы.
3. Артефактов - крупных организационно-структурных элементов, создающих ценности в виде:
• целей, стратегии, стратегических инициатив, общих правил, политики экосистемы и пр.;
• продуктов и услуг экосистемы;
• анализа данных и преобразования данных в информацию;
• систем и приложений, сервисов и их компонентов;
• ИТ-инфраструктуры и технологий.
Хотя АП - это не ИТ-архитектура [8], можно с уверенностью предположить, что модель цифровой медицинской экосистемы будет на более 90% состоять из объектов и структур, связанных с ИТ: описания целевого состояние архитектуры взаимоотношений элементов экосистемы друг с другом и со средой в терминах приложений, бизнес-процессов, сервисов, ИТ-инфраструктуры, работающих совместно для улучшения здоровьесбережения пациентов и ориентированных на цели бизнес-стратегии экосистемы. Очевидно, чтобы избежать дублирования усилий, затрат и времени необходим объединенный подход, совмещающий моделирование экосистемы как АП и управление ИТ-услугами [9].
Рассмотрим подход к проектированию архитектуры цифровой медицинской экосистемы как
архитектуры предприятия с использованием одной из наиболее популярных и распространенных высокоуровневых рамочных моделей (фреймворков)3 для проектирования и сопровождения корпоративных архитектур на основе ИТ-решений - методологии Open Group Architecture Framework (TOGAF), разработанной консорциумом Open Group, которая наиболее применима в следующих ситуациях [10]:
1. Высокоструктурированные архитектурные проекты: предлагается структурированный и четко определенный подход к разработке архитектуры.
2. Архитектура предприятия: предоставляется структура для согласования требований нескольких подразделений, групп и систем.
3. Крупномасштабные программные проекты: предоставляется метод для управления крупными и сложными проектами по разработке программного обеспечения.
Очевидно, что проектирование «корпоративной» архитектуры экосистемы удовлетворяет одновременно всем ситуациям эффективного применения TOGAF, которая, тем не менее, должна быть адаптирована для реализации принципов медицинской экосистемы, изложенных в работе [1].
Эта возможность обеспечивается тем, что TOGAF не является предписывающим стандартом, не является строго последовательным методом (допускает итерации), не ограничивается только архитектурой и не ограничивается только информационными технологиями [11]. В последних версиях TOGAF акценты смещены от данных, приложений и платформенных технологий к бизнес-архитектуре и архитектуре взаимодействия данных и приложений. TOGAF определяет, как создавать и применять АП, позволяя совмещать два направления: проектирование экосистемы как АП и управление ИТ-услугами (англ. IT Service Managemen - I TSM)4. В результате может быть создана эталонная модель архитектуры, обеспечивающая комплексный подход к эффективному предоставлению ИТ-услуг разными участниками экосистемы, лучшее соответствие ИТ потребностям экосистемы, снижение затрат и рисков.
TOGAF - это каркасная модель (фреймворк) управления проектированием архитектуры, которая, среди прочего, затрагивает такие темы, как управление заинтересованными сторонами и управление рисками. На каждом этапе проводится
С
#хс
2 Экосистемные продукты - продукты, полученные из экосистемы (естественной среды), которые могут быть использованы разными ее участниками, как потребителями, так и поставщиками.
3 Методология и набор поддерживающих инструментов, которые адаптируются для использования в каждом конкретном случае.
4 Википедия/ https://ru.wikipedia.org/wiki/ITSM. Доступ: 12.11.2024.
Manager
Zdravoochranenia
/Менеджер
здравоохранения
сопоставление конечного результата с общей бизнес-миссией, видением архитектуры, движущими силами и целями, а также его оценка. Кроме того, TOGAF позволяет строить архитектуру на разных уровнях абстракции: от дизайна до технологической архитектуры низкого уровня.
Ядром TOGAF служит набор методов и методик для разработки и внедрения архитектуры (англ. architecture development method - ADM), который описывает процесс разработки архитектуры, проводя архитекторов через ряд фаз, во время которых осуществляется обязательное взаимодействие со структурой управления требованиями. Модель ADM представлена на рисунке (рис. 2).
Ключевые фазы метода разработки архитектуры (ADM) [11][12]:
1. Подготовка, инициализация и настройка архитектурного процесса.
2. Определение области действия, выявление заинтересованных сторон, получение их поддержки и формирование четкого видения и формального представления архитектуры. Архитектурное видение: понимание проблем и возможностей, эскиз решения и определение общей стратегии изменений архитектурного видения.
3. Разработка бизнес-архитектуры - определяет стратегию бизнеса, управление, организацию участников и ключевые бизнес-процессы, а также определение необходимых изменений в рабочих процессах, организационной структуре и стратегиях для обеспечения разработки представленного видения архитектуры.
4. Архитектура информационной системы -проектирование изменений в логических и физических моделях данных для поддержки представленной архитектуры.
5. Технологическая архитектура - технологии, которые используются для имплементации и применения решений информационных систем: определение изменений, связанных с аппаратным обеспечением, технологической инфраструктурой и многим другим, что необходимо для реализации представленной архитектуры.
6. Дорожная карта - определение этапов и итераций от текущего состояния к целевому видению архитектуры. Каждая итерация может включать один или несколько связанных проектов.
7. Планирование внедрения - оценка деловой ценности каждой выполненной итерации и расстановка приоритетов проектов на основе зависимостей, затрат, выгод и рисков.
8. Управление внедрением - обеспечение соответствия между реализацией и представлением архитектуры, путем проверки выполнения критериев приемки.
9. Управление изменениями архитектуры -оценка изменений, происходящих во время реализации архитектуры, выявление и управление рисками.
В результате применения ADM по TOGAF создаются многоразовые архитектурные артефакты, например ИТ-платформы, ИТ-продукты и ИТ-сервисы экосистемы, образующие в итоге структуру архитектурного контента. Артефакты проверяются
Рис. 2. Модель метода разработки архитектуры (ADM) TOGAF (адаптировано по [11])
—1 3G
Manager
Zdravoochranania 2024
Рис. 3. Цикл разработки архитектуры по TOGAF (адаптировано по [13])
на соответствие потребностям бизнеса и архитектурным целям. После чего сохраняются в качестве эталонов. Все этапы вместе образуют цикл разработки архитектуры по TOGAF (рис. 3).
В контексте настоящей работы описание архитектуры медицинской экосистемы - это не детальное рассмотрение, а лишь попытка выявить архитектурные особенности через некоторые абстракции и сопоставить их с другими архитектурами, найти общее и разное для соотнесения архитектуры предприятия с каким-либо видом (стилем, разновидностью, концептом) [8]. При этом переход от замкнутого мира моделирования деятельности отдельного предприятий к более гибкой структуре экосистемы («открытого мира») и эволюция корпоративных архитектур [5] определяют изменение контекста адаптивных и распределенных систем (структур), которые необходимы для функционирования и взаимодействия участников экосистемы в ходе совместного создания ценностей, включая совместную эволюцию экосистемы и индивидуальное развитие в процессе цифровой трансформации каждого участника.
Разработка модели архитектуры экосистемы должна включать в себя комбинацию подходов «сверху вниз» и «снизу вверх». Подходы «сверху вниз» состоят в постановке целей высокого уровня и разработке плана их достижения, тогда как подходы «снизу вверх» включают сбор, аккумулирование и использование информации и данных от всех участников медицинской экосистемы [8].
Цифровая трансформация в рамках медицинской экосистемы: объединение подходов на основе АП и СОА для совместного создания ценностей
Цифровая трансформация сегодня - доминирующий способ развития бизнеса МО, как и любых других предприятий, посредством создания и предложения цифровых продуктов и сопутствующих услуг (цифровых сервисов). Цифровые продукты/сервисы могут адаптироваться к меняющимся отраслевым требованиям и ранее неизвестным запросам пациентов или же к новым формам организации медицинской помощи за счет изменения текущего поведения и/или состояния, следовательно и функционала, посредством облачных технологий:
• функциональность цифровых продуктов может быть расширена или адаптирована с помощью внешних сервисов;
• цифровые продукты могут создаваться поэтапно или поэтапно могут предоставляться дополнительные услуги, например, за счет временно заблокированного функционала.
То есть функциональность цифровых продуктов является динамичной и адаптивной, а клиенты, чьи требования меняются со временем, могут получать дополнительную функциональность без изменения точки доступа к цифровым продуктам и услугам, например, с помощью мобильных технологий. Одновременно продлевается жизненный цикл цифровых продуктов за счет добавления
с
«КС
->
Manager
Zdravoochranenia
/Менеджер
здравоохранения
и вывода из эксплуатации сервисов (предоставления цифровых услуг).
Разработка адекватных цифровых продуктов и соответствующих цифровых сервисов связана с понятием ценности, которая обычно ассоциируется с выгодой (смыслом) и объединяет такие категории, как важность, желательность и полезность [1]. Концепция ценности важна и для согласования цифровых бизнес-моделей с архитектурой экосистемы, ориентированной на совместное создание ценностей разными участниками [5]. Поставщики цифровых продуктов и сервисов экосистемы поддерживают совместное с пациентами и другими заинтересованными сторонами создание ценности за счет:
1) Постоянной обратной связи: экосистема позволяет постоянно собирать данные об использовании продукта потребителем.
2) Широкого распространения цифровых продуктов в экосистеме: данные, предоставляемые большим количеством экземпляров цифровых продуктов, позволяют получить новое знание (информацию), получение которого невозможно при использовании данных только от одного потребителя, будь то пациент или МИС одной МО.
Подход совместного создания ценностей, основанный на предоставлении разнообразных услуг (обслуживании) и логике пациентоцентричности, реализуется в экосистеме, благодаря непрерывной связи поставщиков медицинской помощи и производителей ИТ-продуктов/сервисов с потребителями, в первую очередь с пациентами, за счет плат-форменности экосистемы. Платформа экосистемы дополняет цифровые продукты разных производителей общими сервисами экосистемы, в том числе сервисом омниканальности5. Участники экосистемы динамично превращаются в сопроизводителей цифровых сервисов, взаимодействуя с ними через стандартизированные интерфейсы. Использование услуги как цифрового сервиса может быть измерено, что закладывает основу для применения разных бизнес-моделей, основанных на биллинге (использовании) и программах лояльности.
Таким образом, медицинская экосистема за счет платформенности и широкого использования цифровых сервисов изначально ориентирована на обслуживание и пациентоцентричность: предоставление новых продуктов и услуг во взаимодействии с потребителями (чаще всего с пациентами). Именно по этой причине во многих исследованиях
5 Доступ к единому набору сервисов в разных интерфейсах.
обсуждается совмещение АП с сервис-ориентированной архитектурой (СОА, англ. SOA - service-oriented architecture), в данном случае - архитектурным подходом, при котором концепция объединения поставщиков цифровых сервисов и их потребителей становится основой для структурирования всей организации [9] или, в нашем случае, экосистемы.
Сервис-ориентированная архитектура - это парадигма (реализация определенного ряда принципов при проектировании ИТ-системы), ориентированная на обеспечение гибкости бизнеса. Она базируется на разделении приложения на слабосвязанные компоненты (сервисы), что позволяет быстро реагировать на изменения в бизнесе посредством реорганизации бизнес-процессов путем создания новых или преобразования существующих ИТ-продуктов к форме сервисов, предоставляемых в бизнес-слое архитектуры. Преимуществами СОА являются композиция и оркестровка сервисов: каждый сервис в СОА имеет разную степень детализации и может поддерживать бизнес-процессы как по отдельности, так и совместно с другими сервисами [9]. СОА позволяет предоставлять сервисы на всех архитектурных уровнях предприятия, поддерживая создание артефактов, взаимосвязь уровней архитектуры и выделение сегментов АП.
Рассматривая СОА в качестве архитектурного подхода, мы сюда же отнесем и более передовой, по мнению многих исследователей, стиль разработки высокомасштабируемых и модульных приложений, в том числе мобильных, основанный на микросервисах (МСА) [5], так как хотя МСА и СОА - разные архитектурные стили, у них много общих характеристик, главными из которых и наиболее важными для наших целей мы считаем перечисленные ниже [14]:
• распределенная архитектура - доступ к компонентам сервиса осуществляется удаленно с помощью одного из протоколов удаленного доступа (REST, SOAP, AMQP, JMS, MSMQ и т.п.);
• модульность - инкапсуляция частей приложения в автономные сервисы;
• слабая связанность - возможность индивидуального проектирования, разработки, тестирования и развертывания практически без зависимости от других компонентов приложения;
• предпочтение перезаписи техническому обслуживанию - позволяет по мере роста бизнеса перестраивать архитектуры или заменять их небольшими частями.
Manager
Zdravoochranania 2024
К сожалению, кроме преимуществ распределенные архитектуры имеют и свои недостатки, к которым относятся, в первую очередь, повышенная сложность и стоимость, обсуждение которых выходит за рамки настоящей статьи.
Исходя из вышеизложенного, мы предлагаем расширенную эталонную кубическую модель архитектуры медицинской экосистемы (рис. 4), ориентированной на обслуживание пациентов с учетом меняющихся условий внешней среды.
Рис. 4. Эталонный куб архитектуры медицинской экосистемы (адаптировано по [4, 5])
При моделировании архитектуры цифровой медицинской экосистемы используются следующие уровни [3, 1]:
1. Уровень инфраструктуры (технологический). Его образует платформа разработки или ядро (конструктор) системы с инфраструктурой управления данными, средствами обеспечения информационной безопасности и прочими системными компонентами в виде общих системных сервисов экосистемы.
2. Уровень трансформации (прикладной).
За него отвечает прикладная платформа для построения бизнес-решений, содержащая различные продукты, приложения и сервисы.
3. Уровень взаимодействия (бизнес-уровень) - бизнес-платформа управления (оркестровки) процессом совместного создания ценностей экосистемы: согласованные коммуникации между продуктами и сервисами, поддерживаемые как базовыми уровнями инфраструктуры и трансформации, так и конечными потребителями.
4. Уровень экосистемы. Платформа более высокого уровня с поддержкой сквозных процессов медицинской помощи, участниками которых являются многие МО, пациенты и другие экосистемы.
Уровни архитектурной модели медицинской экосистемы соответствуют слоям СОА и специализированной платформе - введем понятие стека платформ, что позволяет и предполагает использование ИТ-платформ разных производителей или комбинацию таких платформ, наилучшим образом обеспечивая достижение целей и соответствие требованиям экосистемы. Платформы - это эффективные артефакты архитектуры экосистемы, которые обеспечивают понимание и коммуникацию. Соответствие уровней архитектуры медицинской экосистемы, стека платформ и СОА представлено также в таблице ниже:
На сегодняшний день не существует единого подхода, который можно было бы использовать для создания системы управления экосистемой, обеспечивающей соответствия между управлением услугами, архитектурными концепциями и артефактами экосистемы: различные подходы используются как дополняющие друг друга, а в большинстве случаев и одновременно. Мы, как и авторы работы [9], предлагаем использовать предоставляемые сервисы в качестве ключевого элемента интеграции между концепциями АП и управлением ИТ-услугами (ГОМ).
•КС
Таблица 1
№ Уровень архитектуры медицинской экосистемы Слой СОА Платформа
Уровень экосистемы Слой бизнес-процессов - объединяет продукты и сервисы для решения задач различных участников Бизнес-платформа
2 Уровень взаимодействия (бизнес-уровень) Слой сервисов - организовывает взаимодействие ИТ-продуктов и ИТ-сервисов путем совместного использования данных Интеллектуальная платформа бизнес-решений и аналитики (информации и данных)
3 Уровень трансформации (прикладной) Интеграционный слой - связывает между собой компоненты, продукты и сервисы Прикладная платформа для построения бизнес-решений
4 Уровень инфраструктуры (технологический) Компонентный слой - обеспечивает работу продуктов и сервисов Технологическая платформа для разработки приложений
Manager
Zdravoochranenia
/Менеджер
здравоохранения
Интеграция архитектуры экосистемы и управления ИТ-сервисами
Предложенный подход к проектированию архитектуры медицинской экосистемы включает в себя разработку различных архитектур, определяет взаимодействие между ними посредством управления цифровыми сервисами, которое используется для управления активами, участниками, деятельностью путем согласования бизнес-целей и стратегий. Тем самым раскрываются перспективы архитектуры платформенной экосистемы, обеспечивая соответствия между управлением услугами и артефактами экосистемы, а также концепциями АП и управления ИТ-сервисами.
В нашем понимании платформа экосистемы (уровень 1 в таблице 7) - совокупность платформ, системы управления, бизнес-продуктов, цифровых сервисов, данных и инфраструктуры, используемая для быстрой настройки предложений цифровых продуктов (медицинских услуг и услуг медицинского назначения) в континууме экосистемы [4, 5]. Чтобы прояснить взаимосвязь между понятиями на рисунке (рис. 5) предлагается упрощенная модель, позволяющая понять взаимосвязь между понятиями в различных архитектурах или представлениях.
Архитектура экосистемы в соответствии с концепцией АП должна представлять экосистему от стратегического результата до технологической инфраструктуры с помощью многоуровневой архитектуры. Поэтому одно из самых первых определений должно
касаться поставляемого продукта/услуги - результата деятельности экосистемы. В соответствии со стратегией продукт/услуга экосистемы должны быть описаны как основные направления деловой активности, сформированные в соответствии со стратегическими требованиями: предлагаемые в экосистеме продукты/услуги должны соответствовать выбранной стратегии и быть интегрированы с определенными целями участников или всей экосистемы.
В свою очередь, на формирование стратегии влияет мнение потребителей продуктов/услуг, формирующееся в процессе использования продукта/ услуги. Следовательно, услуги должны быть определены и измерены с точки зрения как пользователей, так и бизнеса. Эффективная ориентация экосистемы на обслуживание (услуги) заключается в предоставлении потребителям (МО и пациентам) таких услуг, которые, во-первых, им нужны, во-вторых, которые они ожидают получить (и готовы оплачивать), а с точки зрения бизнеса определение продуктов/ услуг является необходимым условием для уточнения цели предоставления услуг и возможности измерить полученный эффект (ценность).
С технической точки зрения для преобразования услуги в ИТ-сервис нет необходимости знать о потребности пользователей в деталях, поскольку они уже зафиксированы в продукте/услуге. Но важным является представление о том, какие общие ИТ-сервисы и данные необходимы для предоставления определенных сервисов, и как они непосредственно влияют на производительность
Рис. 5. Схема упрощенной модели управления ИТ-сервисами в медицинской экосистеме (адаптировано по [5, 9])
—1 40
Мападег
2024
ТЕМАТИЧЕСКИЙ СПЕЦВЫПУСК
ИТ-сервисов. Соответственно, необходимо определить направление деятельности, поставщика услуги, используемые ИТ-продукты (приложения), информационную базу и вспомогательную технологическую инфраструктуру.
Какие действия следует выполнить для создания и поддержки ИТ-сервисов (то есть соответствующие ИТ-процессы и правила взаимодействия) определяется политикой экосистемы, реализуемой системой управления. Политика экосистемы определяет также услуги, которые переводятся в каталог услуг. Каждый участник предоставляет дизайн ИТ-сервиса в составе:
• описание сервиса;
• интерфейс сервиса;
• цели и соответствие стратегии экосистемы.
С помощью сервисов устанавливается взаимосвязь между элементами и архитектурами экосистемы, контролируемая системой управления посредством политики экосистемы:
• стратегия определяет, где, почему и какие услуги должны предоставляться;
• дизайн сервиса преобразует продукт/услугу в ИТ-сервисы;
• цифровая трансформация участников в контексте СОА определяется внедрением ИТ-сервисов
в процессы повседневной деятельности участников экосистемы;
• оперативная повседневная деятельность контролируется системой управления (например, посредством биллинга и системы лояльности);
• в целях улучшения качества обслуживания постоянно проводится анализ соответствия между текущим и желаемым состоянием.
Таким образом, используя концепцию АП в качестве основы для представления экосистемы с помощью различных и независимых архитектур, мы можем сопоставить жизненный цикл ИТ-сервисов с архитектурными взаимосвязями. Отправной точкой совмещений подходов АП и СОА является определение экосистемного продукта.
Особенности медицинской экосистемы: экосистемный продукт и проактивное взаимодействие с пациентом
Медицинские экосистемы в отличие от вертикально-интегрированных производственных структур (например домена Здравоохранение (рис. 6), создаваемого в соответствие со стратегическим направлением в области цифровой трансформации
с
«КС
Рис. 6. Структура домена Здравоохранение
Manager
Zdravoochranania
/Менеджер
здравоохранения
здравоохранения6) в настоящей статье рассматри-
ваются как открытые и слабосвязанные системы, фокусирующиеся на данных и на генерировании новых знаний о здоровьесбережении, поэтому позволяют участникам использовать полученные знания по-своему - например, в отдельных экосистемах МО участников. Цель перехода к медицинским экосистемам - преобразование разрозненных элементов информации эпизодической медицинской помощи в целостные рабочие процессы континуума медицинской помощи, призванное помочь врачам в принятии единственно верных и своевременных клинических решений [1].
Ядром деятельности любой МО-участника экосистемы с точки зрения экономики является производство и реализация на рынке медицинских услуг [15]. Очевидно, что в качестве основного экоси-стемного продукта необходимо рассматривать сервис или услугу по оказанию медицинской помощи, которые могут оказываться как оффлайн, так и онлайн. Во избежание разночтений, продукт, получаемый потребителем оффлайн (например, медицинская услуга в стационаре), будем называть услугой, а получаемый онлайн - сервисом. Это связано с тем, что в любых бизнес-экосистемах доступность экосистемного продукта неоднородна. Различные его составляющие имеют разную «проникающую способность» в среду потребителей [16]: нередко в разных регионах по-разному представлены одни и те же составные части экосистемного продукта, а какие-то его элементы не представлены вовсе. Примеры такого ограничения широко известны: AppStore или GooglePlаy в условиях санкций ограничивают российских потребителей в получении приложений или покупке товаров, отечественные бизнес-экосистемы (Яндекс, Озон или Вайлдберрис) также осуществляют доставку товаров с региональными ограничениями.
В терминах медицинской экосистемы основное преимущество сервиса как экосистемного продукта перед услугами (товарами и работами) состоит в том, что сервисы могут быть слабосвязанными и предоставляться удалённо, в том числе трансгранично, и, соответственно, не имеют такого рода барьеров [16]. Кроме того, переход к медицинским экосистемам в настоящей статье рассматривается
6 Распоряжение Правительства Российской Федерации от 17 апреля 2024 г. № 959-р «Об утверждении стратегического направления в области цифровой трансформации здравоохранения» / http://publication.pravo.gov.ru/document/0001202404190016. Доступ: 10.10.2024.
как один из способов цифровой трансформации здравоохранения. Соответственно, ориентация на сервис как на экосистемный продукт является доминирующим методом цифровизации медицины: МО заинтересованы во внедрении механизмов создания и распространения цифровых продуктов и сервисов [17]. Массив медицинских услуг и цифровых сервисов всех МО экосистемы описывает ее производственную базу и является важным инструментом управления [15].
Главным в системе организации медицинской помощи является пациент со своими проблемами и не всегда осознанной потребностью в лечении, который, как правило, обращается в клинику только при возникновении проблем, когда не может с ними справиться самостоятельно. Учитывая, что доступность медицинской помощи во многом определяется ее стоимостью, а она в запущенных случаях и при несвоевременной диагностике увеличивается в разы, большое значение приобретают вовлеченность пациента в процесс лечения, своевременное обнаружение проблем и профилактические мероприятия. При этом, зачастую, человеку нужна не собственно медицинская помощь, а поведенческая коррекция: морально-психологическая, социальная помощь, а иногда и просто добрый совет.
Очевидно, что в здравоохранении, как и в розничном бизнесе, фактором успеха становится проак-тивное взаимодействие с пациентом между обращениями в МО, чтобы вовремя обнаружить ухудшение состояния или возникновение заболевания, сформировать потребность в лечении. При этом важным элементом такого взаимодействия становятся удобная навигация и сопровождение пациента по системе медицинской помощи, так как у пациента есть потребность получать ее в одном месте - не обязательно территориально, но в тех условиях, которые ему понятны и знакомы. Он хочет, чтобы его «вели» как в самой МО, так и при направлении в другую МО. Чтобы медицинская помощь, оказываемая в процессе маршрутизации по разным МО, была эффективной и, по возможности, без увеличения стоимости при направлении в разные МО [2].
Таким образом, одной из основных задач проектирования архитектуры медицинской экосистемы (рис. 7), является, в общем случае, формирование структуры, предоставляющей:
1) Врачу: информацию, необходимую для оценки состояния и принятия решений о коррекции здоровьесбережения пациента, в нужном объеме, в нужном формате, в нужном месте и в нужное
Менеджер
здравоохранения /
Мапедег
2024
Рис. 7. Упрощенная концептуальная модель экосистемы
время при минимизации стоимости хранения и доставки информации - одного из существенных факторов доступности медицинской помощи.
2) Пациенту: удобную и понятную навигацию по системе медицинской помощи экосистемы, а также удобные инструменты управления своими медицинскими данными.
Одной из важных особенностей медицинской экосистемы является предоставление пациентам системы взаимопомощи посредством организации онлайн-сообществ пациентов со схожими проблемами. Сетевые сообщества пациентов, обмениваясь информацией и опытом, способствуют как первичному, так и вторичному привлечению пациентов к клиническим процессам экосистемы медицинской помощи. Кроме того, эти сообщества могут играть важную роль на уровне медицинских исследований: активные группы пациентов в сообществах могут организовывать и проводить собственные исследования, собирать и анализировать данные, публиковать их результаты [18].
Описание основных элементов (артефактов) экосистемы, включая их назначение, функционал и пр., а также описание подходов к управлению этими элементами для достижения стратегических целей экосистемы следует ниже.
Информация и данные экосистемы
Барьером на пути широкого практического применения современных методов анализа больших данных в российской медицине является отсутствие доступных для исследователей банков больших
обезличенных клинических данных. Переход к экосистемам должен способствовать созданию новой, ориентированной на будущее основы для оказания медицинской помощи и проведения научных исследований, в первую очередь, за счет ведения банка клинических данных (БКД), содержащего нормализованные и очищенные данные всех ЭМК МО экосистемы [3].
БКД является богатым источником медицинских данных для исследований, включая демографические данные, симптомы, лабораторные тесты, диагнозы, методы лечения, поведение пациента, связанное со здоровьем, условия направления для лечения в стационаре и т.п. Сопоставление наборов данных амбулаторной помощи, стационарного лечения, данных об образе жизни, данных о конкретных заболеваниях и данных о смертности с данными ЭМК расширяет диапазон данных, необходимых для получения полной клинической картины у пациентов, и, следовательно, влияющих на принятие решений. Это отличный источник поиска прецедентных решений для лечения пациентов. В ходе проведенных исследований [21, 22] прецедентный подход доказал свою эффективность и тем самым еще раз подтвердил научную и практическую целесообразность в сборе и накоплении больших клинических данных. Одновременно были выявлены и проблемы, возникающие при решении задач проектирования и создания хранилищ для больших клинических данных [23].
Для поддержки функционирования хранилищ данных традиционно используются реляционные базы данных для структурированных данных, таких
->
Мепедег
гс1гауоос1пгвпвп1а
Рис. 8. Модель банка клинических данных экосистемы
как ИЭМК (ЭМК), и базы данных NoSQL для неструктурированных данных, таких как изображения, тексты и другие объекты, которыми оперируют объектно- ориентированные инструменты и технологии (С++/С#^ауа и т.п.). Хотя уже достаточно давно предпринимаются многочисленные попытки перевести представление реляционных данных к объектному виду, поскольку в противном случае необходимо одновременно использовать две разные модели данных (реляционную для хранения и объектную для работы бизнес-приложения) и непрерывно конвертировать их из одной в другую [24], для больших данных «традиционные» реляционные СУБД уже не являются лидерами в построении хранилищ больших данных [23].
Источником данных в основном выступают МИС и личные кабинеты пациентов. Сервисы БКД извлекают необработанные (сырые), но предварительно обезличенные данные из различных источников, преобразуют их в единый заранее определенный формат и загружают в БКД, как это представлено на рисунке (рис. 8). В связи с тем, что предполагается перенос данных из устаревших систем, консолидация разрозненных наборов данных больших объемов из различных типов внутренних и внешних источников, а перестраивание процедур загрузки данных при изменении бизнес-правил и требований к форматам данных, скорее всего, потребуется нечасто, предлагается использовать наиболее распространенную архитектуру конвейера передачи данных7 Е^ (англ. Extrаct-Trаnsform-Loаd, извлечение-преобразование-загрузка).
Появление в России БКД, предоставляющих открытый доступ к большому объему клинических данных, ускорит внедрение современных методов ИИ в российское здравоохранение, будет стимулировать профильные министерства и ведомства
России к сбору и накоплению клинических данных в национальном масштабе, может способствовать реальному повышению качества и эффективности медицинской помощи в России. Сложности объединения данных ЭМК в БКД связаны с различными подходами к организации данных в составе ЭМК, включая способы управления полнотой данных, различные классификации и определения заболеваний. Проблемно-ориентированная формализация клинических данных, основанная на архитектуре потока событий (рис. 9), в расчете на применение к данным банка современных методов искусственного интеллекта предложена в [23].
7 Набор инструментов и процедур для перемещения и консолидации данных из одной системы в другую с изменением методов
хранения и обработки данных.
Рис. 9. Модель архитектуры на основе потока событий [23]
Ценность данных в экосистеме многократно возрастает наряду с их безопасным использованием и хранением. Технологии автоматического обновления и пополнения данных - один из ключевых факторов использования участниками хранилищ данных экосистемы и принятия экосистемы пользователями (врачами и пациентами) в целом. Автоматическое обновление повышает ценность хранилищ
данных экосистемы для всех потребителей, устраняя дублирование данных и повышая точность, полноту и своевременность содержимого ИЭМК, ЭМК и ПЭМК, но является непростой задачей, которая заключается не только в периодической проверке и обнаружении новых или измененных данных в системе ЭМК МО и импорте этих данных в соответствующие документы (например, при запросе пациентом копии медицинских данных из какого-либо места лечения), но и в установлении или обновлении взаимосвязей между внутренними элементами данных ИЭМК и ПЭМК, если взаимосвязи изменились в ЭМК-источнике данных [18].
В контексте настоящей статьи ИТ-инфраструктура экосистемы обеспечивает основное межорганизационное информационное взаимодействие. В общих хранилищах размещается только административная, управленческая информация, общие обязательные сведения, в том числе получаемые из внешних информационных ресурсов, а также БКД, все остальные данные других распределенных приложений, используемых в МО, могут храниться как локально, так и централизованно, в зависимости от используемой архитектуры. В настоящей статье предлагается рассмотреть подход, когда соответствующие хранящиеся локально данные могут динамически объединяться из различных локально распределенных медицинских и других информационных систем.
Для получения информации о том, где хранятся те или иные сведения о здоровьесбережении, используется специализированное хранилище оперативных данных (ОХД), посредством сервисов которого
каждый домен экосистемы (как совокупность информационных систем, продуктов и сервисов отдельной МО или некоторого лечебно-профилактического объединения) уведомляет другие домены об изменениях в системе здоровьесбережения пациента. Таким образом, электронная медицинская карта (ЭМК) каждой МО или в составе личного кабинета пациента (персональная ЭМК) превращается в один из вариантов виртуальной ЭМК (ВЭМК), динамически интегрирующей распределенные информационные системы и обеспечивающей преемственность медицинской помощи (рис. 10).
Источником данных могут быть МИС, личные кабинеты пациентов, устройства интернета вещей, социальные сети, API-интерфейсы и другие системы хранения (хранилища данных, озера данных и т.п.). В связи с тем, что ключевую роль играет скорость обработки данных, а в процессе задействованы огромные объемы данных, которые могут быть использованы по-разному и, соответственно, по-разному преобразованы, предлагается использовать архитектуру конвейера передачи данных ELT (англ. Extract-Load-Transform, извлечение-загрузка-преобразование). ELT является, на наш взгляд, менее используемой и отлаженной сегодня технологией, чем ETL, что создает проблемы с точки зрения доступных инструментов и компетентных специалистов. Функции оперативного хранилища данных:
• периодическая проверка и обнаружение новых или измененных данных в ЭМК МО-участников;
• импорт измененных данных в соответствующие документы ЭМК или ПЭМК, например, при
С
#хс
Рис. 10. Модель оперативного хранилища данных
Manager
ZdrevoochreneniB ,
обращении или запросе копии медицинских данных из какой-либо МО;
• простой и быстрый поиск необходимых данных;
• получение данных там и тогда, где и когда это необходимо потребителю.
Важны также и стандарты взаимодействия или интеграционная архитектура участников медицинской экосистемы.
Подход к проектированию интеграционной архитектуры медицинской экосистемы
Интероперабельность широко признана в качестве ключевого условия успешности экосистем здравоохранения, в том числе, во многом за счет нее достигается экономический эффект от взаимодействия составляющих медицинской экосистемы. Функциональная совместимость достигается за счет использования согласованных стандартов, которые определяют синтаксическое и семантическое значение информации. Согласованные и реализуемые стандарты снижают риски, затраты и сроки реализации проектов по разработке эко-системных технологий здравоохранения.
На сегодняшний день в России использование стандартов, в основном, сосредоточено на стандартах сообщений между сервисами и терминологических стандартах:
• стандарты сообщений описывают форматы обмена транзакциями между системами;
• стандарты терминологии включают словари и описания концептов, используемых в системах, например, объектов и их свойств.
Для создания медицинской экосистемы потребуются дополнительные стандарты, включая стандарты аутентификации, авторизации и безопасности, клинических процессов, электронного представления медицинских знаний, омниканальности и т.п., некоторые из которых, возможно, будут внедряться по мере совершенствования домена Здравоохранение, но пока не получили широкого распространения.
Несмотря на усилия многих авторитетных международных организаций, таких как ^7, которые в определенной степени способствовали интеграции различных программных продуктов в здравоохранении, повсеместной интероперабельности пока достичь не удалось. ^7 уЗ, например, подвергался резкой критике в отрасли за внутреннюю несогласованность, сложность и дороговизну реализации в реальных системах, а также за то, что способствовал появлению многих неудачных и застопорившихся
внедрений информационных систем [19]. Несмотря на то, что на сегодняшний день отраслевые и законодательные программы здравоохранения по всему миру инвестировали огромные ресурсы в интеропе-рабельность МИС, цель обеспечения функциональной совместимости в сфере здравоохранения остается пока недостижимой [19, 25].
Сегодня уже существует множество конкурирующих стандартов, другие продолжают совершенствоваться или находятся в стадии разработки. Хотя ни один единый стандарт не стал явным победителем, стандарты HL7 пользуются популярностью, особенно с появлением стандарта Fast Healthcare Interoperability Resources или «FHIR» - международного стандарта, определяющего формат хранения/обмена/предоставления медицинской информации в электронном виде8 и включающий в себя спецификацию RESTful API9, которая получила широкое распространение в качестве доминирующей информационной абстракции всемирной сети. Практические преимущества архитектур RESTful включают в себя «легкие» интерфейсы, которые обеспечивают более быструю передачу и обработку структур данных, в том числе подходящих для мобильных устройств.
Проблему использования существующих стандартов мы рассмотрим на примере использования стандарта FHIR. Центральным понятием FHIR являются ресурсы, которые разделены по типам и группам, при этом каждый тип имеет собственную структуру полей, значения которых могут быть примитивными или композитными типами и ссылками на другие ресурсы. Большинство других стандартов основаны на документальном подходе (например, отчеты, история болезни пациента, выписки из больницы, страховка, претензии и т.д.). Для каждого ресурса хранится история его изменений как перечень состояний с датами их актуальности и номером версии объекта.
Стандарт FHIR заслуженно пользуется поддержкой в России благодаря своей открытости и расширяемости для удовлетворения будущих потребностей, вследствие относительно высокого уровня документирования и поддержки, а также благодаря наличию HAPI FHIR, который является Java-реализацией спецификаций HL7 FHIR с открытым исходным кодом. Несмотря на указанные преимущества, известны и проблемы широкого применения FHIR в МИС:
8 Международный стандарт Fast Healthcare Interoperability Resources/ https://www.hl7.org/fhir/overview.html. Доступ: 11.11.2024.
9 RESTful API / https://www.hl7.org/fhir/http.html. Доступ: 11.11.2024.
Manager
Zdravoochranania 2024
• как ресурсо-ориентированная среда, FHIR обеспечивает очень простую реализацию базовых артефактов, их передачу и сохранение. Однако существуют разночтения относительно того, как эти базовые ресурсы должны быть объединены в более крупные коллекции и взаимосвязи (например, медицинские документы);
• для достижения семантической совместимости одного FHIR недостаточно - необходимо использовать и терминологические стандарты, например, RxNorm для информации о лекарствах и SNOMED для ЭМК или ПЭМК, или любые другие, которые предоставляют конечную точку входа API (например, LOINC или UMLS);
• сопряжение или адаптация МИС с большой историей эксплуатации к современным спецификациям, таким как FHIR, является сложной задачей, требующей существенной финансовой поддержки;
• одна из сложностей использования FHIR заключается в том, что могут использоваться разные версии FHIR-стандарта одновременно при неполной их реализации: разные системы могут иметь отклонения в перечне, составе и структуре ресурсов и/или API, а также содержать дополнительную функциональность, не входящую в спецификацию;
• подход с использованием FHIR, как и любого другого стандарта, нуждается в тщательной качественной и количественной оценке для проведения тестирования и анализа в реальных условиях, что может потребовать не меньше времени и усилий, чем разработка собственных стандартов взаимодействия.
Так, в исследовании [20] отмечается, что преобразованию данных к стандарту FHIR препятствуют различные требования разработчиков и клиницистов к элементам данных, которые должны быть включены в структуры обмена данными. И хотя в этой работе указывается, что элементы данных, определенные во FHIR, могут охватывать почти 80% реальных данных, по нашему опыту, для РФ эти цифры значительно ниже. В итоге, практически с каждым участником экосистемы приходится «говорить» на его «личном» языке [25].
Тем не менее, выдачу в ответ на запрос пользователем данных, хранящихся в другой МО, технически несложно осуществить посредством стандартизации данных, реализации API, использованием стандартных сетевых протоколов [25]. Но агрегация тех же данных, хранящихся во множестве МО, как
и получение из них практически полезной информации представляет собой очень нетривиальную задачу из-за больших трудностей с обеспечением семантической интероперабельности, когда система не только в состоянии принять данные в достаточно свободном формате, но и «понимает» их [25].
Поэтому термин «стандарты» применительно к экосистемам в настоящей статье используется в очень широком смысле: для обозначения соглашений по поводу чего-либо, требующего координированных действий. Такие соглашения оставляют свободу выбора там, где важна гибкость и разнообразие. Другими словами, стандарты являются общим решением, не обязывающим всех использовать единые системы или процессы, но требующим соблюдения определенных ограничений. Основная цель внедрения общих стандартов взаимодействия в экосистеме - обеспечение структурной совместимости с другими системами или приложениями путем разработки логики оптимального формата для простого кодирования объектов данных.
Таким образом, одну из задач проектирования медицинской экосистемы можно сформулировать следующим образом: создать информационную структуру и инструменты, позволяющие принять «достаточно хорошие» стандарты в достаточно короткие сроки, чтобы экосистема могла быстро развиваться и расширяться, сохраняя свое многообразие и приспособляемость. Введение минимальных стандартов создания, обработки и обмена медицинской информацией, а также технологий для их поддержки и развития, способно быстро трансформировать усилия в реально работающую экосистему медицинской помощи.
Разработка цифровых экосистем должна включать адаптивные структуры для устранения системных ошибок, препятствующих свободному обмену информацией и организации сквозных рабочих процессов. Вслед за авторами работы [25] мы предлагаем использовать собственные стандарты взаимодействия медицинской экосистемы. Что, конечно же, не предполагает разработку собственной интеграционной архитектуры с нуля, но подразумевает применение опыта использования известных протоколов, обеспечивающих полноту данных в настоящий момент, и работу с методологически зрелыми инструментами и технологиями интеграции [26]. Таким образом, в экосистеме оптимизируется практическая эффективность широко известных стандартов интероперабельбости для поддержки системного подхода к обработке
С
#хс
Manager
Zdravoochranenia
/Менеджер
здравоохранения
клинических данных, как основы преемственности и непрерывности медицинской помощи.
Управляющая компания и платформа управления (оркестровки) процессом совместного создания ценностей
МО обладают различными локальными ресурсами, использование которых для создания новой услуги или цифрового сервиса, способствующих финансовому благополучию МО, неочевидно. Известно множество проблем, связанных с проведением исследований рынка, планированием и разработкой нового продукта, поиском каналов сбыта, недостаточной компетентностью кадров, привлечением необходимых финансовых средств и других ресурсов. Таким образом, оценить ценность локальных ресурсов и осуществить их цифровую трансформацию самой МО сложно. Эти задачи в составе медицинской экосистемы решаются платформой управления или оркестровки процессом создания ценностей путем стимулирования активного вовлечения участников в совместную работу по созданию ценностей посредством обеспечения четкого видения и общей базы данных услуг или сервисов, на основе которой может строиться деятельность экосистемы. Платформа управления также оказывает поддержку участникам экосистемы в установлении новых связей и в обмене своими знаниями и ресурсами.
Платформа управления процессом совместного создания ценностей - система, с помощью которой заказчики и поставщики организуются таким образом, чтобы они могли взаимодействовать и, снижая
транзакционные издержки, создавать новые ценности для конечных потребителей (клиентов) в интересах совместной эволюции и индивидуального развития каждого. Контроль над процессом при этом полностью остается в руках поставщиков или заказчиков, а иногда и клиентов. Одновременно необходимо понимать различие: платформа - это не экосистема, хотя экосистема в значительной степени зависит от наличия конкретной физической платформы в качестве «домашней базы» для совместной деятельности по созданию ценностей [27].
К сожалению, современное понимание структур и практик, поддерживающих совместное создание ценности посредством платформ в медицинских экосистемах, все еще не сформировано [27]. Но уже сегодня понятно, что задачи и функционал платформы управления не могут быть ограничены только технологическими решениями. В исследовании [27] определено, что участие в совместных инновационных экосистемах и содействие их внедрению требуют гибкости нового типа и важных решений, в некоторых случаях требующих от МО готовности отказаться от своей текущей бизнес-модели, чтобы выжить в развивающейся экосистеме.
Понятие платформы оркестровки неразрывно связано с процессом совместного создания ценностей, в ходе которого участники экосистемы получают возможность расширения собственных прав и возможностей за счет взаимодействия [27, 17]. Впервые двухфазная модель совместного создания ценности была предложена в 2009 г. в [28] и модифицирована авторами позже в работе [17]. В адаптированном виде она представлена на рисунке (рис. 11):
Рис. 11. Модель процесса совместного создания ценностей (адаптировано по [17])
I. Фаза взаимодействия:
1. Приобретение общего опыта в ходе совместного использования.
2. Совместное определение понятий.
II. Фаза расширения прав и возможностей:
3. Совместная эволюция.
4. Индивидуальное развитие.
Это представление о процессе совместного создания ценностей не является исчерпывающим и используется для того, чтобы представить различные содержательные и взаимодополняющие подходы к пониманию процессов функционирования платформы управления экосистемой.
На практике процесс совместного создания ценности начинается после того, как участники экосистемы объединяются на основе взаимных интересов в области новых знаний о системном лечебно-диагностическом процессе: используемых данных и инноваций. Предполагается, что стимулом для интереса участников к экосистеме является симпа -тия к ней, сформированная в процессе PR-акций: общения в социальных сетях и других медиа-площадках. Платформа управления ценностями облегчает и упорядочивает процесс совместного создания новых ценностей заказчиками и поставщиками. В течение 1-й фазы потенциальные участники экосистемы проявляют интерес к экосистеме, делятся совместным опытом и осознают свои потребности и ожидания, сопоставляя их с потребностями и ожиданиями других участников экосистемы. Далее начинается разработка общей модели использования посредством совместного определения понятий. В течение 2-й фазы актуализируется и оценивается конкретная ценность совместного результата: создания (или разрушения) ценностей [27, 17] и создается структура, которая поддерживает способы создания новых знаний и обмена ими.
При выборе платформы экосистемы потенциальный участник (МО) учитывает количество других МО и пациентов, использующих ту же платформу, в дополнение к цене, которую он должен заплатить за присоединение. Другими словами, размер сети МО (количество пациентов) является одним из параметров качества при выборе платформы, что связано с наличием внешних связей между потенциальными участниками экосистемы, вследствие чего привлекательность платформы медицинской экосистемы для заказчиков определяется характеристиками поставщиков медицинской помощи и потребителей и/или наоборот. С точки
зрения пациентов, важнее может быть разнообразие, а не количество поставщиков медицинской помощи. Следует понимать, что вовлечение МО в экосистему не способно принести быстрый положительный эффект для поставщиков медицинской помощи, поэтому МО-участники экосистемы должны быть нацелены не на краткосрочную прибыль, а стремиться к долгосрочному успеху.
В медицинской экосистеме платформа управления процессом совместного создания ценностей выполняет следующие задачи:
1. Вовлечение новых участников и реализация политики экосистемы.
2. Облегчение и организация совместного создания новых ценностей заказчиками и поставщиками, в интересах конечных потребителей (клиентов) - в нашем случае пациентов.
Она находится в ведении управляющей компании (УК - оператор во взаимодействии с держателем платформы) [2] - специально организованной структуры, которая служит инструментом развития, поддержки и расширения экосистемы посредством реализации соответствующей политики.
Выстраивание управления для экосистемы как единого целого требует формирования специального управленческого центра. При этом управление ею не может осуществляться директивно. Подобный подход не предполагает отказа от роли лидера со стороны создателя (оператора) медицинской экосистемы, но подразумевает выстраивание скорее партнёрских и равных взаимоотношений между её участниками в горизонтальной плоскости, в противовес жёсткой иерархии в управлении классическими холдингами. Процесс управления скорее можно описать как согласование решений между участниками [16].
Автономность нужна для того, чтобы абстрагироваться от формата «основной продукт и комплиментарный» и сконцентрироваться на главной цели - развитии всей экосистемы: развивать все сервисы всех МО в равной степени, а не отталкиваться от базовых продуктов и сервисов владельца ИТ-платформы или оператора экосистемы [16]. УК в контексте медицинской экосистемы выступает в качестве «производителя системы обслуживания», который спроектирует экосистему как систему обслуживания и предпримет усилия по запуску цикла положительной обратной связи и совместного создания ценности [17].
Развитие экосистемы будет зависеть также от того, к каким соглашениям придут МО «первой
С
#хс
Manager
Zdravoochranenia
/Менеджер
здравоохранения
волны» по поводу масштабов и содержания взаимодействия, и как эти соглашения будут оформлены в виде политики экосистемы. Поэтому процесс управления медицинской экосистемой должен быть двухфазным:
1. Согласование решений между участниками [16].
2. Трансформация согласованных решений в политику экосистемы [3], посредством которой и осуществляется управление взаимодействием участников и совместным использованием ими продуктов и сервисов экосистемы.
Управляющая компания экосистемы выполняет работу по стандартизации функций и интерфейсов цифровых медицинских продуктов и сервисов экосистемы, включая разработку функциональных моделей (функциональные требования, информационное наполнение, критерии функционального соответствия), и разработку архитектуры перенаправления пациентов между различными поставщиками медицинской помощи с использованием средств биллинговой системы и системы лояльности. Для согласования ИТ-услуг с бизнес-стратегией УК может использовать также руководящие принципы ITIL (англ. Information Technology Infrastructure Library -библиотека инфраструктуры информационных технологий) - общепризнанный набор рекомендаций, призванный помочь организациям максимально эффективно использовать ИТ. УК выполняет, в том числе, исследовательские функции в интересах развития комплексного продукта (массива медицинских услуг) и всей совокупности МО экосистемы, способствуя тому, чтобы каждый бизнес-домен экосистемы становился каналом привлечения пациентов для других участников, одновременно препятствуя выходу пациента из экосистемы.
Обсуждение и выводы
Используемый в настоящее время набор архитектурных методик весьма широк. Различные фрэймворки, как правило, ориентированы на разные целевые аудитории и отличаются широтой охвата проблемы, вниманием к определенным областям, размером проектируемых предприятий разной отраслевой принадлежности и т.д. Ни одна из методик не занимает главенствующего положения и ни одна из них не предоставляет всех инструментов, необходимых для описания архитектуры. Однако накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей,
примеров и опыта различных предприятий, относящихся к разным отраслям.
Для согласования бизнес-целей и применяемых ИТ уже достаточно давно используется подход, основанный на концепции АП. Как показано в работе [9], сочетание фреймворков TOGAF с фреймворками управления ИТ-сервисами (ГОМ) может создать методологическую основу для развития цифрового предприятия. Компоненты и модель разработки архитектуры по TOGAF предоставляют систематический и достаточно эффективный способ согласования бизнес-целей с архитектурными задачами. Поскольку разработчики экосистем и другие корпоративные разработчики продолжают искать эффективные и масштабируемые решения, TOGAF остается достойным рассмотрения инструментом для достижения архитектурных целей и поддержания конкурентоспособности МО в динамично развивающемся мире технологий [11, 12, 13].
Для описания архитектуры цифровой медицинской экосистемы используется уровневая модель, которая кратко описывает и поддерживает взаимосвязи в экосистеме различных технологических уровней и/или платформ в соответствии с определением [3]. Каждый уровень играет исключительную роль, гарантируя, что операционная модель экосистемы, описывающая использование экосистем-ного продукта (цифровых продуктов и сервисов), может представлять собой совокупность повторно используемых артефактов (готовых компонентов), необходимых для описания бизнес-услуги и связанной с ней бизнес-модели. Бизнес-модели определяются на верхнем уровне, но опираются на своеобразные иерархические зависимости [29]:
• основные функциональные компоненты могут использоваться как локально, так и централизованно;
• из комбинаций компонентов формируются цифровые сервисы и продукты экосистемы;
• продукты экосистемы могут использоваться в качестве сервиса и наоборот. Комбинирование продуктов и сервисов экосистемы из готовых компонентов позволяет гибко создавать и распределять новые ценности, удовлетворяющие потребностям как пациентов, так и бизнеса.
Предлагаемый подход к проектированию архитектуры медицинской экосистемы поддерживает создание бизнес-моделей, при переходе от оф-лайн-услуги к онлайн-сервису, например: от приема врача к предоставлению услуг телемедицины; или
—1 50
Manager
Zdravoochranania 2024
от группы сервисов к комплексному сервису, например: от услуг онлайн-регистратуры и телемедицины к предоставлению услуг домашнего стационара. Предоставляемые сервисы используются в качестве ключевого элемента интеграции между концепциями АП и управление ИТ-услугами. Уровневая модель также облегчает описание такого свойства экосистемы, как открытость для подключения внешних информационных ресурсов, взаимодействия с другими экосистемами и подключения исследовательских проектов в сферах ИТ и медицины (глубокое машинное обучение, добыча данных (data mining), интеллектуальный анализ данных, глубинный анализ данных, СППВР, персональная медицина и др.).
Настоящая статья может стать отправной точкой для разработки архитектуры медицинской
экосистемы с использованием существующих фреймворков или для разработки специализированных фреймворков, которые могут быть применены в этой области. В конкретной прикладной области, такой как медицинская экосистема, ориентированная на обслуживание, необходимы дополнительные исследования для изучения взаимосвязи между бизнес-моделями МО и ИТ-сервисами. В ходе таких исследований должна быть предложена формализованная мета-модель архитектуры медицинской экосистемы таким образом, чтобы, с одной стороны, адекватно использовались элементы различных платформ разработки корпоративного континуума, с другой - была представлена ме-тамодель совместного сервис-ориентированного бизнеса участников экосистемы (МО и пациентов).
1. Михеев А.Е. Перспективы создания цифровых медицинских экосистем в России: цифровые двойники и другие технологии, проблемы и подходы. Менеджер здравоохранения. 2024; S:4-32. DOI: 10.21045/1811-0185-2024-S-4-32
2. Белышев Д.В. и др. Реализация «виртуальной больницы» в виде ИТ-экосистемы. // Врач и информационные технологии. - 2018. - № 5. - С. 18-33.
3. Михеев А.Е. МИС как бизнес-платформа цифровой экосистемы медицинской помощи. // Менеджер здравоохранения. 2022; S: 5-22. DOI: 10.21045/1811-0185-2022-S-5-22.
4. Masuda Y, Zimmermann A., Viswanathan M, Bass M, Nakamura O, Yamamoto S. Adaptive Enterprise Architecture for the Digital Healthcare Industry: A Digital Platform for Drug Development. Information 2021, 12, 67. https://doi.org/10.3390/info12020067
5. Zimmermann, Alfred & Schmidt, Rainer & Sandkuhl, Kurt & Jugel, Dierk & Bogner, Justus & Mohring, Michael. (2018). Evolution of Enterprise Architecture for Digital Transformation. 87-96. 10.1109/ED0CW.2018.00023. [Электронный ресурс] URL: https://www.researchgate.net/publication/328993200 (доступ 09.11.2024)
6. Enterprise Architecture и ее подходы/ [Электронный ресурс]. URL: https://habr.com/ru/companies/ otus/articles/710138/ (Доступ: 21.08.2024 г.).
7. Bernard S.A An Introduction to Enterprise Architecture; AuthorHouse: Bloomington, IN, USA, 2012; pp. 31-45.
8. Enterprise Architecture vs алхимия предприятия. Ключевые мифы. [Электронный ресурс]. URL: https:// habr.com/ru/articles/345424/ (Доступ: 21.08.2024 г.).
9. Gama N.; Sousa P; da Silva M.M. Integrating enterprise architecture and IT service management. In Building Sustainable Information Systems; Springer: Boston, MA, USA, 2013; pp. 153-165. [Электронный ресурс] URL: https://www.academia.edu/54686714/Integrating_Enterprise_Architecture_and_IT_Service_ Management?email_work_card=view-paper. (Доступ: 16.11.2024).
10. Open Group Architecture Framework (TOGAF). [Electronic resource]. URL: https://www.opengroup.org/ togaf. (Accessed: 12.09.2024 г.).
11. Nigam R. TOGAF In Nutshell. [Electronic resource]. URL: https://rajatnigam89.medium.com/togaf-in-nutshell-bdd8428e7489& (Accessed: 12.09.2024 г.).
12. Berrisford G. What is TOGAF not? Electronic resource]. URL: https://www.linkedin.com/pulse/what-togaf-graham-berrisford/ (Accessed: 12.09.2024 г.).
13. Архитектура предприятия, TOGAF 10 и адаптивность организационной структуры. [Electronic resource]. URL: (https://habr.com/ru/companies/otus/articles/756986/)
14. Microservices vs. Service-Oriented Architecture by Mark Richards. [Электронный ресурс]. URL% https:// www.developertoarchitect.com/downloads/microservices-vs-soa.pdf. (Доступ 20.11.2024 г.).
15. Михеев А..Е, Фохт О.А., Хайт И.Л. Стратегия управления медицинскими услугами в медицинских информационных системах. // Менеджер здравоохранения. 2022; S: 23-33. DOI: 10.21045/1811-0185-2022-S-23-33.
16. Кобылко А.А. Функции управления в бизнес-экосистемах // ЭКО. 2021. No 8. С. 127-150. DOI: 10.30680/ECO0131 -7652-2021 -8-127-150
17. Kijima K. & Arai Y. 2016. Value Co-Creation Process and Value Orchestration Platform. In Kwan S., Spohrer J. & Sawatani Y. (Eds.), Global Perspectives on Service Science: Japan: 137-154. New York: Springer. [Electronic resource]. URL: https://www.kijima-lab.com/alumni/dl/160312_K-Kijma-Chapter1Editing.pdf (Accessed: 08/10/2022).
18. Михеев А.Е. Личный кабинет и расширение полномочий пациентов в цифровых экосистемах медицинской помощи. // Менеджер здравоохранения. 2023; S:46-54. DOI: 10.21045/1811-0185-2023-S-46-54.
•КС
Manager
Zdravoochranenia
/Менеджер
здравоохранения
ЭХО
зЯо f
19. Bender Duane & Sartipi Kamran. (2013). HL7 FHIR: An agile and RESTful approach to healthcare information exchange. Proceedings of CBMS2013-26th IEEE International Symposium on Computer-Based Medical Systems. 326-331. 10.1109/ CBMS.2013.6627810.
20. Bae Y.S., Park Y, Lee S.M, Seo H.H., Lee H, Ko T, Lee E, Park S.M. and Yoon H.-J. Development of blockchain-based health information exchange platform using HL7 FHIR standards: Usability test. IEEE Access, vol. 10, pp. 79264-79271, 2022. [Electronic resource]. URL: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9841542 (Accessed: 13.09.2024 г.).
21. Malykh V.L., Kononenko I.N. andRudetskiyS.V. Estimation of accuracy of recommended diagnostic and treatment actions based on precedent approach. Proceedings of the International Conference e-Health 2016, Madeira, Portugal, July 1-4, 2016. pp. 52-58.
22. Малых В.Л., Рудецкий С.В. Сравнительный анализ различных подходов к поддержке принятия врачебных решений на основе больших клинических данных. Московская научно-практическая конференция по Искусственному интеллекту в медицине MosCAI'17. 12 октября 2017 года, Москва, Конгресс-центр гостиницы Космос.
23. Малых В.Л., Михеев А.Е, Рудецкий С.В. Проблемно-ориентированная модель банка клинических данных. Программные системы: теория и приложения, 2018, 9:4(39), с. 219-237. [Electronic resource]. URL: https://psta.psiras.ru/read/ psta2018_4_219-237.pdf (Accessed: 30.08.2024 г.).
24. Белышев Д.В., Кочуров Е.В. Модульные хранилища данных в платформе «Интерин IPS» для PostgreSQL. Врач и информационные технологии. 2021; S5: 32-43. doi: 1025881/18110193_2021_S5_32.
25. Малых В.Л, Калинин А.Н., Рудецкий С.В. Архитектура взаимодействия в медицинской экосистеме // Программные системы: теория и приложения. 2024. Т. 15. No 2(61). С. 475-492. [Electronic resource]. URL: https://psta.psiras.ru/ read/ psta2024_2_475-492.pdf (Accessed: 12.09.2024 г.).
26. Рудецкий С.В, Бельченков А.А., Калиновский В.В., Морозов М.А., Фохт О.А. Эволюция подхода к интеграции между медицинской и лабораторной информационной системами. // Менеджер здравоохранения. 2023; S:55-64. DOI: 10.21045/ 1811-0185-2023-S-55-64.
27. Ketonen-Oksi S. and Valkokari K. Innovation ecosystems as structures for value co-creation. Technol. Innov. Manage. Rev., vol. 9, no. 2, pp. 25-35, Feb. 2019, [Electronic resource]. URL: http://dx.doi.org/10.22215/timreview/1216. (Accessed: 21.08.2024 г.).
28. Galbrun, J., & Kijima, K. 2009. Co-Evolutionary Perspective in Medical Technology: Clinical Innovation Systems in Europe and in Japan. Asian Journal of Technology Innovation, 17(2): 195-216. https://doi.org/10.1080/19761597.2009.9668679
29. Белышев Д.В., Гулиев Я.И., Михеев А.Е. Цифровая экосистема медицинской помощи. // Врач и информационные технологии, № 5, 2018, с. 4-17.
m
о
ORIGINAL PAPER
APPROACHES TO THE DEVELOPMENT OF A CONCEPTUAL MODEL OF THE ARCHITECTURE OF THE DIGITAL MEDICAL ECOSYSTEM
A.E. Mikheev x
Ailamazyan Program Systems Institute of RAS; https://orcid.org/0000-0002-4777-2732.
H Corresponding author: Mikheev A. E.
ABSTRACT
To date, no consensus has been formed in academic circles, nor in the medical and IT communities on what the architecture of the medical ecosystem should be. Due to the focus of medical ecosystems, unlike other business ecosystems, primarily on meeting the health-saving needs of patients, as well as due to constant changes in the IT world and modern business, the work on business and IT coordination in the interests of patients in the medical ecosystem is of particular importance. It is proposed to use an approach based on the concept of enterprise architecture (AP), which has been used for quite a long time for the development of information systems, in combination with an approach based on the management of IT services. This article provides a rationale for using the AP concept in conjunction with IT service management to align the needs of business and information technology in developing the architecture of the medical ecosystem. The purpose of this article is to give a general idea of the use of AP to solve the problems of joint value creation within the medical ecosystem by means of information technology. The article also presents the TOGAF framework as one of the most promising general frameworks for developing the architecture of the medical ecosystem. An array of ecosystem medical services is presented as an ecosystem product, and the main artifacts and the ecosystem management system are also described. This article can be a starting point for the development of the architecture of the medical ecosystem using existing architectural frameworks or for the development of specialized frameworks for use in this field.
Keywords: digital ecosystem of medical care, medical information system, MIS, electronic medical record, EMC, coordination of business models and IT, information systems, enterprise architecture, AP framework, TOGAF, patient's personal account, AI, artificial intelligence, big data, large clinical data bank.
For citation: Mikheev A.E. Approaches to the development of a conceptual model of the architecture of the digital medical ecosystem.
Manager Zdravoohranenia. 2024; S:33-52. DOI: W.2W45/1811-0185-2024-S-33-52
ИНФОРМАЦИЯ ОБ АВТОРАХ / ABOUT THE AUTHORS
Михеев Александр Евгеньевич - старший научный сотрудник, Исследовательский центр медицинской информатики «Института программных систем им. А.К. Айламазяна» Российской академии наук, г. Переславль-Залесский, Россия.
Aleksandr E. Mikheev - Senior Research Scientist of the Medical Informatics Research Center, Ailamazyan Program Systems Institute of RAS, Pereslavl-Zalessky, Russia. E-mail: [email protected]
Менеджер
здравоохранения /
Meneger
Zdrevoochrenenie 2024
