Сложная корпоративная сеть распределенной обработки информации (Enterprise Nervous System) может быть построена на тех же принципах, что и обработка информации в нервной системе человека. Корпоративные информационные системы ближайшего будущего могут строиться на принципах нервной сети (биологической нейронной сети) с применением способов распределенного решения сложных задач (Distributed Problem Solving). Для реализации подобных концепций подходит архитектура на основе сложных событий [1], обеспечивающая асинхронную параллельную распределенную обработку потоков данных на основе выделения и обработки множеств событий. Данная архитектура — альтернатива традиционному фон-неймановскому подходу с пошаговым исполнением алгоритмов управления и обработки данных. Множество окон, фильтрующих события и запускающих обработчики отфильтрованных событий, концептуально реализуют распределенную сеть обработки данных. В частности, данная архитектура хорошо подходит для медицинской информатики для построения систем поддержки принятия решений [2, 3].

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

Рис. 1. Архитектура обработки событий

Одно и то же событие может обрабатываться независимо и асинхронно разными обработчиками в разных целях. Все обработанные диспетчером события имеют свойство, показывающее, в скольких открытых окнах обработки данное событие находится. Нулевое значение свойства говорит о том, что к событию «утрачен интерес» со стороны обработчиков. Такое событие может быть удалено из очереди и перенесено в историю, если предусмотрено историчное хранение таких событий или их ретроспективное использование.

Приведем примеры обработки событий. Госпитализирован пациент N. Данные об этом внесены в базу данных. Сработал триггер и сформировал первичное событие «пациент госпитализирован», которое попало в очередь на обработку. Диспетчер (один или несколько параллельных процессов обработки очереди событий) выяснил, что имеется обработчик «поиск госпитализированных пациентов, которым в течение трех суток не поставлен диагноз», заинтересованный в указанном событии. Диспетчер проверил, нет ли актуального окна, порожденного для данного обработчика с контекстом, подходящим для указанного первичного события. Если окно не нашлось, то диспетчер на основании шаблона обработчика открывает статическое окно обработки длительностью 3×24 часа и помещает в него обработанное первичное событие. Далее диспетчер должен решить — надо ли запускать обработчик для созданного окна. Очевидно, что в шаблоне обработчика должны специфицироваться режимы запуска. В данном примере следует запускать обработчик при условии, что в окне обработки окажется не менее двух разнотипных событий. Обработка завершится либо при наступлении и попадании в окно события «поставлен диагноз» (в этом случае окно просто закроется), либо при наступлении события «время жизни окна обработки истекло» (в этом случае будет создано новое событие «госпитализированному пациенту в течение трех суток не поставлен диагноз»), и окно будет закрыто.

В работе [2] приводится пример события «Медикаментозное назначение», которое может вызвать различные обработчики: проверить на совместимость и указать эффекты взаимодействия назначенных лекарственных средств; попасть на контроль к клиническому фармакологу; проверить назначение на соответствие стандартам лечения или технологическим картам; вызвать контроль наличия данного препарата в отделении и т. д. В работах [2, 3] приведены примеры использования данной архитектуры для решения задач ведения медицинских процессов по технологическим картам или по стандартам лечения, для построения цепочек логического вывода, для построения систем поддержки принятия врачебных решений.

Основные понятия

Событие (Event). Все события типизированы, однородны по структуре и формально являются кортежами атомарных фактов, кортежами пар <имя-значение>. Если событие необходимо связать с большими объектами данных (Large Object, LOB), то в кортежи фактов попадают локаторы на LOB. Типичным примером события из сферы медицины является событие «Поставлен диагноз», которое может включать в себя следующие факты: Тип диагноза, Пациент, Медкарта (случай заболевания), Дата и время постановки, Врач (автор диагноза), Формулировка диагноза, Код диагноза по МКБ10 и т. п. Модель конкретного события определяется исходя из целей обработки и дальнейшего использования этого события в информационной системе.

Темпоральные свойства событий. События, как правило, могут иметь темпоральные свойства: дата и время возникновения, длительность события, временной интервал актуальности события. Например, случай госпитализации в течение n дней.

Источники первичных событий. Основными источниками событий становятся потоки данных. Появление, изменение или удаление данных в системе свидетельствуют о произошедших событиях. Самый простой механизм, реализующий источники первичных событий, это триггеры на таблицах реляционной базы данных. Операции Insert, Update, Delete могут запускать триггеры, которые будут интерпретировать эти операции как события. Например, вставка актуальной записи в таблицу диагнозов приведет к возникновению события «Поставлен диагноз». Триггеры в этом случае играют роль адаптеров, переводя манипуляции с данными в формальные модели событий.

Таймеры. Таймеры являются источниками событий. Обработка событий часто потребует использования различных темпоральных отношений, в том числе и обработки событий от таймеров — наступление определенных моментов времени.

Обработчики событий (Events Handlers). Обработчики событий являются генераторами новых событий. Каждый обработчик задает шаблон (образец, pattern) обработки событий. Шаблон определяет множество потенциально разнотипных событий, которые предполагается обрабатывать с помощью обработчика, определяются контекст обработки, имя программного модуля, реализующего обработчик, характеристики окна обработки, условия запуска обработчика. Например, требуется создать обработчик для выделения контрольного медицинского события — «госпитализированному пациенту в течение трех суток не поставлен диагноз». Обработчик, выделяющий такое событие, будет обрабатывать следующие события: «пациент госпитализирован»; «поставлен диагноз»; «время жизни окна обработки истекло» (событие от таймера).

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

Окно обработки (Events Window). Обработка событий происходит в рамках темпоральных окон, имеющих длительность и расположенных на шкале текущего времени. Окна могут быть статические — неподвижные относительно шкалы времени и динамические — «скользить» по шкале времени. Динамические окна применяются для реализации на отобранных событиях темпорального отношения «события произошли одновременно». Размеры окон могут быть изменены в ходе обработки. Эти свойства окон обработки позволяют достичь большой гибкости в организации процесса обработки. Например, обработчик «поиск госпитализированных пациентов, которым в течение трех суток не поставлен диагноз» при появлении события «пациент госпитализирован» открывает статическое окно обработки длительностью 3×24 часа с контекстом данного пациента.

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

Обработка событий может выполняться не только автоматическими обработчиками, но и людьми (manual processing). «Запуск» обработчика (человека) можно осуществить с помощью формирования сообщений с предложением выполнить определенные действия по обработке указанного в сообщении множества событий. Поскольку в автоматизированной системе людей интересуют многие выделяемые системой события, то в архитектуре предусмотрена возможность «подписки» людей на интересующие их события с указанием типов событий и контекстов их отбора. Например, лечащий врач хочет получать сообщения о появлении результатов диагностических исследований у своих пациентов либо непосредственно получать результаты исследований.

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

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

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

В процессную модель можно еще добавить понятия участников процесса (роли, actors) и выполняемых участниками действий.

На рис. 2 показан переход от событий к процессам. Следует отметить, что уровень объектов можно было бы опустить, «погрузив» объекты в состояния — в обработчики событий. В этом случае каждый объект ассоциировался бы со своим состоянием.

Рис. 2. Архитектура процессов на основе обработки событий

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

Вместе с тем применение событийной архитектуры имеет и свои сложности. В первую очередь — это выделение и описание событий. Здесь напрашивается онтологический подход к моделированию событий, выделение классов событий, включение в онтологию не только событий, но и их обработчиков, использование принципов наследования при обработке событий. В работе [2] приводится пример использования в целях моделирования событий лечебно-диагностического процесса средства разработки онтологий Protégé (protege.stanford.edu). Но разработка онтологий в сфере медицинской информатики — чрезвычайно сложный и трудоемкий процесс — достаточно привести пример ведущейся еще с 1965 года разработки «Систематизированной медицинской номенклатуры SNOMED CT» (www.snomed.org), которую можно рассматривать как многоязычный тезаурус со свойствами онтологии.

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

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

***

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

Литература

1. Александр Болдачев. Архитектура на основе событийной семантики // Открытые системы. СУБД. — 2021. — № 3. — С. 33–35. URL: https://www.osp.ru/os/2021/03/13055996 (дата обращения: 30.08.2022).

2. Малых В. Л., Рудецкий С. В., Хаткевич М. И. Активная МИС // Врач и информационные технологии. — 2016. — № 6. — С. 16–24. URL: https://www.elibrary.ru/download/elibrary_27404825_91525094.pdf (дата обращения: 30.08.2022).

3. Малых В. Л. Системы поддержки принятия решений в медицине // Программные системы: теория и приложения. — 2019. — № 2 (41). — Т. 10 — С. 155–184. URL: http://psta.psiras.ru/read/psta2019_2_155-184.pdf (дата обращения: 30.08.2022).

Владимир Малых (mvl@interin.ru) – зав. лабораторией, Сергей Рудецкий (rsv@interin.ru) – м.н.с., Исследовательский центр медицинской информатики, Институт программных систем им. А. К. Айламазяна РАН, (Переславль-Залесский).

DOI: 10.51793/OS.2022.57.27.003