Исполняемое знание как объект медицинской информатики в надзорной экосистеме операционной и отделения реанимации и интенсивной терапии

Авторский коллектив

1. Прозоров А.А., Директор по технологиям РТЛАБ, архитектор Сбертех, ap@rtlab.ru;
2. Редкин И.В., Директор по науке РТЛАБ, к.м.н., ведущий научный сотрудник НИИ общей реаниматологии им. В.А. Неговского, ФНКЦ РР, iredkin@rtlab.ru;
3. Бахвалов И.М., Генеральный директор РТЛАБ Онкология, ibakhvalov@rtlab.ru;

Аннотация

Цель. Определить исполняемое знание как объект медицинской информатики, применимый к надзорной экосистеме операционной и отделения реанимации и интенсивной терапии (OR/ICU), где необходимы низкая задержка обработки физиологических данных, воспроизводимая интерпретация физиологического статуса пациента, контролируемое управление устройствами и семантически управляемая авторизация изменений.

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

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

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

Ключевые слова: мгновенная оценка состояния здоровья; исполняемое знание; надзорная экосистема OR/ICU; медицинская информатика; кодифицированные термины; операционная; отделение реанимации и интенсивной терапии; медицинские устройства; клиническая поддержка принятия решений; доказательства выполнения; пригодность к выполнению аудита

Сокращения и терминологические соглашения

ОРИТ — отделение реанимации и интенсивной терапии; OR/ICU — операционная и отделение реанимации и интенсивной терапии; ИИ — искусственный интеллект; FDA — U.S. Food and Drug Administration; IMDRF — International Medical Device Regulators Forum; SaMD — программное обеспечение как медицинское изделие (Software as a Medical Device); IHE PCD — Integrating the Healthcare Enterprise Patient Care Device; SDPi — Service-oriented Device Point-of-care Interoperability; ISO/IEEE 11073 SDC — сервисно-ориентированная модель связи медицинских устройств у постели пациента; FHIR — Fast Healthcare Interoperability Resources; DICOM — Digital Imaging and Communications in Medicine.

Термин executable knowledge в настоящей статье передается как «исполняемое знание». Термин computable knowledge передается как «вычислимые знания». Использование формы единственного числа для исполняемого знания обусловлено тем, что статья рассматривает его как центральный объект медицинской информатики, а не как совокупность разрозненных правил.

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

1. Введение

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

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

Литература по медицинской информатике на протяжении длительного времени рассматривает задачу перевода клинических знаний из текстовой формы в вычислимую. Формализмы компьютерно-интерпретируемых клинических рекомендаций, включая PROforma и GLIF3, показали, что клиническая логика может быть представлена в форме, пригодной для программного исполнения и обмена [2–4]. Вместе с тем надзорная экосистема OR/ICU предъявляет более узкие и операционно строгие требования. Для нее недостаточно только представить правило в исполнимом формате. Необходимо обеспечить автоматизированное развертывание, совместимость с медицинскими устройствами, явные границы полномочий, дисциплину релизов и воспроизводимую цепочку доказательств выполнения.

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

Регуляторные и стандартизационные подходы к совместимости медицинских устройств, программам поддержки клинических решений и программному обеспечению как медицинскому изделию подчеркивают необходимость явного описания интерфейсов, предполагаемого назначения, границ программного компонента и контуров управления [5–7]. Для систем надзора в OR/ICU это означает, что поведение у постели пациента не должно обосновываться только ссылкой на обученную модель или локальный интеграционный код. Необходимо иметь проверяемую цепочку: какое знание было авторизовано, каким образом оно было скомпилировано, какой пакет был выпущен, какие операционные факты были зарегистрированы и как они могут быть связаны с исходной семантической основой.

Цель настоящей статьи — определить исполняемое знание как объект медицинской информатики для надзорной экосистемы OR/ICU и описать архитектурные условия, при которых управляемая клиническая семантика может быть переведена в детерминированное и аудируемое исполнение у постели пациента с малой задержкой по времени.

2. Исполняемое знание: определение и отличие от более слабых форм

В широком употреблении выражение «исполняемое знание» нередко сводится к набору правил, которые могут быть запущены в программном обеспечении. Для среды OR/ICU такого понимания недостаточно. Здесь исполняемое знание следует рассматривать как управляемый объект медицинской информатики, семантическая основа которого проходит этапы создания онтологии, авторизации, компиляции, выпуска в виде ограниченных артефактов исполнения и сопровождения структурированными доказательствами выполнения. При таком подходе операционные факты остаются трассируемыми к управляемому источнику авторизованной семантики.

От более слабых форм представления клинической логики исполняемое знание отличается тремя свойствами. Во-первых, его смысл закреплен в явном источнике авторизованной семантики, а не только в реализации контура исполнения. Во-вторых, оно становится операционным через управляемую компиляцию, а не через ручное переизложение инженерами реализации. В-третьих, контур исполнения должен порождать структурированные доказательства, связанные с источником полномочий, а не оставлять после себя изолированные технические журналы. Внешние стандарты происхождения и аудита демонстрируют значимость стабильных артефактов, несущих доказательства, даже если конкретные названия артефактов в данной статье относятся к рассматриваемой архитектурной программе [12, 13, 16].

В предлагаемой модели цепочка исполняемого знания включает несколько типов артефактов. Authorized snapshot (авторизованный снимок) представляет собой управляемую семантическую основу, выбранную для компиляции. Compiled IR Bundle (скомпилированный IR-пакет) является детерминированной операционной проекцией, потребляемой контуром исполнения. Lineage Receipt (квитанция о происхождении) связывает выпущенные артефакты с их семантической и релизной основой. Runtime Evidence Report (отчет о доказательствах выполнения) фиксирует наблюдаемое поведение контура исполнения в нормализованной форме. Refinement Candidate (кандидат на уточнение) представляет структурированное предложение изменения, возникающее из анализа доказательств выполнения. Governed Graph Update Request (запрос на управляемое обновление графа) формализует путь, по которому такое изменение возвращается в пространство авторизованных изменений семантики с целью улучшения работы системы.

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

Таблица 1. Артефакты в цепочке исполняемого знания

Артефакт	Роль в цепочке	Значение для OR/ICU
Authorized snapshot	Управляемая семантическая основа, выбранная для компиляции	Не позволяет прикроватной логике отклоняться от авторизованной семантики
Compiled IR Bundle	Детерминированная операционная проекция, потребляемая контуром исполнения	Обеспечивает низкозадержанное исполнение без обращения к источнику авторизованной семантики на критическом пути
Lineage Receipt	Связь происхождения и релиза между семантическими артефактами и артефактами исполнения	Делает каждый выпущенный пакет воспроизводимым и аудируемым
Runtime Evidence Report	Нормализованные доказательства выполнения, формируемые операционным поведением	Связывает наблюдаемое поведение у постели пациента с управляемой семантикой
Refinement Candidate	Структурированное предложение, возникающее при пересмотре доказательств выполнения	Удерживает операционное обучение внутри управляемого контура
Governed Graph Update Request	Формальный путь изменения источника авторизованной семантики	Не допускает превращения локальных правок контура исполнения в скрытый источник истины

Таким образом, исполняемое знание в OR/ICU представляет собой не статический каталог правил, а связанный контур «семантика — компиляция — исполнение — доказательства — уточнение». Именно эта связность позволяет рассматривать его как самостоятельный объект медицинской информатики.

3. Надзорная экосистема OR/ICU

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

Первым элементом является контур интеграции. Его задача заключается в сборе и маршрутизации данных от мониторов, анестезиологических рабочих станций, аппаратов искусственной вентиляции легких, инфузионных устройств и связанных шлюзов. Для надзорного стека высокой остроты наиболее релевантны профили IHE Patient Care Device, семейство SDPi и сервисно-ориентированная модель связи устройств ISO/IEEE 11073; сообщения на основе HL7 также сохраняют значение в окружающей практике интеграции [8–10]. Если семантика входных данных является произвольной или недокументированной, последующий контур исполнения не может быть надежно управляемым.

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

Третьим элементом является детерминированное ядро безопасности (safety kernel), отделенное от детерминированного вычислительного ядра (compute core). Такое разделение необходимо, поскольку надзорная система OR/ICU не только классифицирует состояние, но и может опосредовать действия, направленные на устройства. Контур исполнения может сформировать рекомендацию или целевую команду, однако именно детерминированное ядро безопасности должно проверять совместимость предполагаемого действия с возможностями устройства, временной актуальностью, валидностью клинического контекста, локальной политикой и, при необходимости, требованием подтверждения человеком [5, 17, 18].

Четвертым элементом является структурированный журнал событий. Результаты оценки, тревоги, записи аудита и диагностические трассы должны формировать операционную память, пригодную для воспроизведения и анализа. Событийный слой должен быть достаточно структурированным, чтобы поддерживать формирование Runtime Evidence Report и последующий управляемый пересмотр. Это требование согласуется с подходами FHIR Provenance, FHIR AuditEvent и PROV-O, хотя конкретный артефакт доказательств выполнения остается предметно-специфичным [12, 13, 16].

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

Шестым элементом является контур визуализации и отладки онтологии. В нем могут выполняться просмотр волновых форм, экспорт эпизодов, воспроизведение событий и исследование связей с онтологией. DICOM и DICOMweb уместны именно в этом контуре, но не как основная среда управления у постели пациента [14, 15]. Такой подход позволяет использовать каждое семейство стандартов там, где оно наиболее соответствует требованиям задержки, аудируемости и клинического смысла.

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

Рисунок 1. Многослойная надзорная экосистема OR/ICU

Таблица 2. Контуры, ответственность и границы полномочий

Элемент рисунка 1	Уровень	Основная ответственность	Граница полномочий
Прикроватная среда	Среда	Физическая среда OR/ICU, в которой устройства, пациенты, персонал и шлюзы создают чувствительные ко времени наблюдения и возможные точки действия	Не авторизует семантику, не заменяет клиническую ответственность и не принимает решения об изменениях управления
Мониторы, вентиляторы, анестезиологические устройства, насосы, шлюзы	Группа устройств и шлюзов	Предоставление измерений, настроек, состояния устройств, тревог и ограниченных возможностей действий, направленных на устройства, в контур интеграции	Источник наблюдений и возможностей, но не источник исполняемого знания и не контур межустройственных надзорных решений
Контур интеграции	Контур	Перемещение данных от устройств и шлюзов в надзорную экосистему в виде структурированных фактов, пригодных для детерминированного исполнения	Не должен становиться скрытым источником авторизованной семантики или логикой прикроватной оценки состояния
IHE PCD, SDPi, ISO/IEEE 11073 SDC, шлюзы с привязкой к HL7	Группа адаптеров	Протокольные и шлюзовые адаптеры, которые проводят телеметрию, состояние устройств и связи с клиническим контекстом в контур интеграции	Только полномочия транспорта и нормализации; нет полномочий утверждать термины, компилировать логику или выдавать действия, направленные на устройства
Контур исполнения	Контур исполнения	Размещение выпущенного детерминированного вычислительного ядра и детерминированного ядра безопасности при низкой задержке у постели пациента	Может исполнять выпущенный ограниченный набор; не должен изменять исходную семантику или заменять управление
Детерминированное вычислительное ядро	Компонент исполнения	Исполнение авторизованной логики и формирование детерминированных оценок состояния, находок, рекомендаций и кандидатов целевых команд	Полномочия оценки состояния только внутри выпущенного пакета; не граница действий, направленных на устройства, и не поверхность авторизованной семантики
Детерминированное ядро безопасности	Компонент исполнения	Ограничение действий, направленных на устройства, с учетом возможностей устройств, временной актуальности, валидности контекста, локальной политики и правил подтверждения человеком при необходимости	Только полномочия ограничения действий; не прямой синоним логики оценки состояния и не утверждение о клинической автономности
Журнал событий	Контур доказательств	Сохранение результатов, тревог, событий аудита и диагностических трасс как структурированной операционной памяти для воспроизведения и аудита	Только полномочия сохранения доказательств; не неструктурированный отладочный дамп и не новый источник семантической истины
Результаты, тревоги, аудит, диагностические трассы	Группа артефактов доказательств	Фиксация поведения, создаваемого детерминированным вычислительным ядром, детерминированным ядром безопасности и окружающими поверхностями выполнения	Доказательства наблюдаемого поведения, но сами по себе не клиническая валидация, не исправление семантики и не управляемое замыкание
Нисходящие проекции	Группа проекций	Обслуживание потребителей медицинских записей, аналитики, графовых и отчетных представлений, визуализации и отладки онтологии на основе структурированных доказательств событий	Только полномочия потребительской проекции; нет полномочий изменять выпущенный пакет или исходную семантику
Контур медицинских записей	Компонент проекции	Передача релевантных для медицинской записи сводок и событий в рабочие процессы медицинских записей	Поверхность документирования, но не критический путь исполнения у постели пациента и не источник авторизованной семантики
Аналитические, графовые и отчетные представления	Компонент проекции	Поддержка агрегированного анализа, графового просмотра, контроля качества и операционной отчетности	Только аналитическое представление, а не исполняемая прикроватная логика принятия решений
Контур визуализации и отладки онтологии	Компонент проекции	Предоставление рецензентам и процессам отладки онтологии возможности просматривать структурированные доказательства и семантические связи	Только поверхность рецензирования; не прямое изменение графа, не исправление трассы в интерфейсе пользователя и не управление устройствами
Контур управления	Группа управления	Авторизация семантического содержания, компиляция артефактов релиза, наблюдение доказательств выполнения и направление уточнений к контролируемому изменению семантики	Управляет исполняемым знанием, но не исполняет критический путь у постели пациента и не выдает действия, направленные на устройства
Источник авторизованной семантики	Компонент управления	Поддержание единого управляемого источника авторизованного семантического содержания, используемого как вход релиза	Только семантические полномочия; не хранилище наблюдений выполнения и не запись доказательств развертывания
Авторизация и компиляция	Компонент управления	Валидация, авторизация и понижение управляемой семантики в выпущенные артефакты исполнения с доказуемым происхождением	Только полномочия компиляции и принятия; само по себе не доказывает клиническую эффективность и не активирует развертывание
Отчет о доказательствах выполнения	Артефакт доказательств управления	Нормализация наблюдений из журнала событий в рецензируемые доказательства, которые можно объединить с выпущенной семантикой	Только артефакт объединения доказательств; не замена журнала событий, исходного графа или решения о замыкании
Кандидат на уточнение / запрос на управляемое обновление графа	Артефакт рабочего процесса управления	Передача рецензируемых предложенных изменений от наблюдаемого поведения к процессам управляемого обновления графа и замыкания	Только полномочия предложения; не утвержденное изменение семантики до завершения управляемого замыкания

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

4. Жизненный цикл перехода от семантики к исполнению

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

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

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

Третьим этапом является компиляция. Управляемый источник авторизованной семантики преобразуется в Compiled IR Bundle и связанные артефакты релиза, включая Lineage Receipt. На этом этапе смысл становится пригодным для машинно быстрого исполнения, но сохраняет проверяемую подотчетность. Надзорная экосистема не должна обращаться к графовому хранилищу на критическом пути у постели пациента. Управление сохраняется за счет того, что исполняется только выпущенная и ограниченная проекция авторизованной семантики.

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

Пятым этапом является развертывание. В контексте OR/ICU развертывание означает не только копирование файлов. Оно выбирает и активирует выпущенный ограниченный набор исполнения в конкретном состоянии перехода от семантики к исполнению: какой пакет активен, какие возможности включены, какой контур безопасности действует и какой поток событий должен формироваться как доказательство. Если развертывание не связано с той же цепочкой происхождения, исполняемое знание утрачивает проверяемую связь с операционной реальностью.

Шестым этапом является формирование доказательств выполнения. Контур исполнения должен производить Runtime Evidence Report, совместимый с той же семантической цепочкой, которая авторизовала, скомпилировала, выпустила и развернула пакет. PROV-O, FHIR Provenance и FHIR AuditEvent демонстрируют, что происхождение, контекст действия и аудиторские события могут моделироваться как структурированные объекты, пригодные для последующего пересмотра [12, 13, 16]. В рассматриваемой архитектуре доказательства выполнения должны проектироваться как объект первого класса, а не как побочный технический журнал.

Седьмым этапом является управляемое уточнение. Refinement Candidate не является оперативной правкой контура исполнения. Это структурированная находка, которая при принятии может привести к Governed Graph Update Request. Такое разграничение сохраняет асимметрию между контуром исполнения и источником полномочий: операционный опыт может инициировать пересмотр семантической основы, но не должен молча изменять ее во время выполнения.

Рисунок 2. Замкнутый жизненный цикл перехода от семантики к исполнению в надзорной экосистеме OR/ICU

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

5. Обоснование детерминированной архитектуры прикроватного исполнения

Архитектура OR/ICU, рассматриваемая в данной статье, должна быть детерминированной, ориентированной на периферийное исполнение, основанной на правилах и формально аудируемой. Это положение не является отрицанием потенциальной роли искусственного интеллекта в медицинской информатике. Оно отражает требования конкретной среды: инспектируемость, воспроизводимость, строго определенные полномочия на действия, направленные на устройства, и высокодоверительное управление семантическими изменениями в регуляторно значимой и критичной по безопасности клинической зоне [5–7, 17, 18].

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

Воспроизводимость необходима потому, что надзорная система должна поддерживать ретроспективный анализ того, как была сформирована оценка состояния или целевая команда при конкретном пакете, клиническом контексте и состоянии устройств. Такая воспроизводимость существенно надежнее, если путь исполнения детерминирован, активным артефактом знания является Compiled IR Bundle, а операционное поведение фиксируется в Runtime Evidence Report.

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

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

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

Следовательно, тезис данной статьи следует формулировать ограниченно: в рамках надзорной экосистемы OR/ICU, определяемой здесь, ИИ не включается в границу прикроватного контура исполнения. Возможная роль ИИ выше по цепочке не исключается, но не подменяет детерминированную, аудируемую и управляемую логику у постели пациента.

6. Контуры совместимости и развертывания

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

Для контура интеграции наиболее релевантны профили IHE Patient Care Device, семейство SDPi и сервисно-ориентированная модель связи устройств ISO/IEEE 11073 [8–10]. Эти подходы лучше соответствуют телеметрии с низкой задержкой, потокам тревог и событий, а также ограниченному внешнему взаимодействию с устройствами в условиях неотложной помощи, чем документно-центричные или архивно-центричные протоколы.

Контур медицинских записей имеет иную функцию. FHIR и связанные корпоративные представления целесообразно использовать для сохранения структурированного контекста пациента, результатов, происхождения данных, аудиторских событий, непрерывности передачи ответственности и клинической документации [11–13]. Этот контур необходим для надзорной экосистемы, однако он не тождественен плоскости управления у постели пациента. Любая архитектура, предполагающая, что путь корпоративной медицинской записи автоматически пригоден для низкозадержанного прикроватного исполнения, должна рассматриваться как методологически уязвимая.

Контур визуализации и отладки также выполняет отдельную роль. DICOM и DICOMweb могут использоваться для визуализации, экспорта эпизодов, просмотра волновых форм и исследования связей с онтологией [14, 15]. Такое размещение не снижает значения DICOM, а определяет его корректное положение в экосистеме: визуальное представление и анализ должны быть отделены от чувствительного к задержке исполнения и от контура медицинских записей.

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

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

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

7. Обсуждение и ограничения области применения

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

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

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

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

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

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

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

8. Заключение

Надзорной экосистеме OR/ICU необходимы не только совместимые потоки данных и быстрые прикроватные вычисления. Ей требуется объект медицинской информатики, который способен удерживать источник авторизованной семантики, детерминированное исполнение, происхождение, доказательства выполнения и управляемое уточнение в одной проверяемой цепочке. В настоящей статье таким объектом определено исполняемое знание.

Предложенная модель показывает, почему семантическое управление должно сохраняться после компиляции, почему прикроватный контур исполнения должен быть детерминированным и ограниченным, почему контур интеграции, контур медицинских записей, контур визуализации и контур управления должны оставаться различными и почему путь от Authorized snapshot к Runtime Evidence Report является конститутивным для системы. Полученные положения могут использоваться как концептуальная основа для дальнейшего описания замкнутого цикла управления формализуемым знанием и для разработки предметных реализаций в анестезиологии, реаниматологии и кардиологии.

9. Авторская основа

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

Конфликт интересов

Рукопись описывает реализацию определенного аспекта платформы HealthOS, а именно: модель исполняемого знания в надзорной экосистеме OR/ICU.

Финансирование

Финансирование работ со стороны РТЛАБ.

10. Литература

1. World Health Organization. “Integrated emergency, critical and operative care (ECO).” https://www.who.int/teams/integrated-health-services/clinical-services-and-systems/emergency–critical-and-operative-care
2. M. Peleg. “Computer-interpretable clinical guidelines: a methodological review.” Journal of Biomedical Informatics, 46(4), 744–763, 2013. https://doi.org/10.1016/j.jbi.2013.06.009
3. J. Fox, N. Johns, and A. Rahmanzadeh. “Disseminating medical knowledge: the PROforma approach.” Artificial Intelligence in Medicine, 14(1–2), 157–181, 1998. https://doi.org/10.1016/S0933-3657(98)00021-9
4. M. Peleg, A. A. Boxwala, O. Ogunyemi, et al. “GLIF3: a representation format for sharable computer-interpretable clinical practice guidelines.” Journal of Biomedical Informatics, 37(3), 147–161, 2004. https://doi.org/10.1016/j.jbi.2004.04.002
5. U.S. Food and Drug Administration. “Design Considerations and Pre-Market Submission Recommendations for Interoperable Medical Devices.” Guidance for Industry and Food and Drug Administration Staff, September 2017. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/design-considerations-and-pre-market-submission-recommendations-interoperable-medical-devices
6. U.S. Food and Drug Administration. “Clinical Decision Support Software.” Guidance for Industry and Food and Drug Administration Staff, January 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
7. International Medical Device Regulators Forum. “Software as a Medical Device (SaMD): Key Definitions.” IMDRF/SaMD WG/N10FINAL:2013. https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
8. Integrating the Healthcare Enterprise. “Patient Care Device (PCD) Technical Frameworks.” https://www.ihe.net/resources/technical_frameworks/#PCD
9. Integrating the Healthcare Enterprise. “Service-oriented Device Point-of-care Interoperability (SDPi).” https://profiles.ihe.net/DEV/SDPi/index.html
10. ISO. “ISO/IEEE 11073-10207:2017 Health informatics — Point-of-care medical device communication — Domain information and service model for service-oriented point-of-care medical device communication.” https://www.iso.org/standard/76538.html
11. HL7 International. “FHIR Release 4 (v4.0.1).” https://hl7.org/fhir/R4/index.html
12. HL7 International. “FHIR Resource Provenance (R4).” https://hl7.org/fhir/R4/provenance.html
13. HL7 International. “FHIR Resource AuditEvent (R4).” https://hl7.org/fhir/R4/auditevent.html
14. National Electrical Manufacturers Association. “DICOM Standard.” https://www.dicomstandard.org/
15. National Electrical Manufacturers Association. “DICOMweb: DICOM Over the Web.” https://www.dicomstandard.org/using/dicomweb
16. W3C. “PROV-O: The PROV Ontology.” https://www.w3.org/TR/prov-o/
17. ISO. “ISO 14971:2019 Medical devices — Application of risk management to medical devices.” https://www.iso.org/standard/72704.html
18. ISO. “IEC 62304:2006/AMD 1:2015 Medical device software — Software life cycle processes.” https://www.iso.org/standard/64686.html