Scientific journal
Modern high technologies
ISSN 1812-7320
"Перечень" ВАК
ИФ РИНЦ = 1,279
FUNCTIONAL MODELING OF THE AUTOMATED MEDICAL DECISION-MAKING PROCESS IN SURGICAL TREATMENT
Введение
Цифровая трансформация здравоохранения, предусмотренная стратегическими и нормативными документами РФ [1, 2], требует создания и обеспечения эффективного функционирования автоматизированных систем управления медицинскими технологическими процессами (АСУ МТП) и их основных модулей. Понятие МТП возникло еще во второй половине XX в., когда началось активное внедрение информационных систем и технологий, средств автоматизации и методов математического и ситуационного моделирования во все сферы социально-экономической сферы, в том числе в медицинский сектор [3, 4]: это «система взаимосвязанных необходимых и достаточных научно обоснованных лечебно-диагностических мероприятий, выполнение которых позволяет наиболее рациональным образом провести лечение и обеспечить достижение максимального соответствия научно прогнозируемых результатов реальным при минимизации затрат». При хирургическом лечении автоматизированная поддержка принятия врачебных решений становится особенно актуальной, поскольку цена ошибки крайне высока, а влияние человеческого фактора (например, интенсивные нагрузки и дефицит времени) может существенно снижать объективность выбора тактики и результативность лечения.
Исходя из проведенного анализа источников, например [5, 6] и в соответствии со стандартами архитектуры клинических СППР, можно определить полный перечень основных функций, которыми должна быть наделена современная АСУ МТПХЛ, а именно: сбор и обработка информации о состоянии пациента, диагностирование; хирургическое планирование; автоматизированное управление ресурсами; поддержка принятия врачебного решения; сопровождение выполнения операции с использованием различных видов роботизированных подсистем; оценка результатов реализованного хирургического вмешательства; аналитика данных и отчетность; хранение и актуализация данных, моделей, алгоритмов, правил; обеспечение интерактивного взаимодействия персонала. Возможна детализация данных функций и их дополнение. Таким образом, АСУ МТПХЛ должны не только включать модули, реализующие традиционные для информационных систем функции, но и актуализировать работу модулей с возможностями интеллектуальной поддержки принятия решений на основе использования различных цифровых решений и моделей [7, 8].
Одними из первых автоматизированных экспертных систем в хирургии, использовавших в своей основе методы интеллектуального моделирования, стали системы для прогнозирования длительности нахождения в стационаре пациентов с острым панкреатитом [9]. Сегодня спектр подобных автоматизированных систем значительно расширился. Например, к ним относятся системы автоматизированного мониторинга в режиме реального времени с обратной связью с опытом хирургических пациентов [10–12]. Также интерес представляют системы, реализующие функции автоматизированной оценки хирургических навыков с помощью искусственного интеллекта [13]. Особо следует отметить подсистемы с прогностическими способностями, а именно, реализующие оценку и прогнозирование необходимости хирургического вмешательства (например, [14]), выбора метода оперативного лечения [15]. Однако, несмотря на многообразие существующих автоматизированных систем, большинство из них разрабатывается для применения на узком спектре хирургических нозологий. Кроме того, существующие медицинские информационные системы и системы поддержки принятия решений в основном работают в разомкнутом режиме: выдают рекомендацию на основе первично введенных данных и не инициируют дополнительных функций при неполноте или неопределенности.
В данной работе мы рассматриваем процесс актуализации функции автоматизированного формирования врачебного решения, объединяющего работу нескольких подсистем АСУ МТПХЛ, представляя универсальный подход к моделированию и формальному описанию данного процесса. Рассматривается один из ключевых этапов проектирования АСУ МТПХЛ и ее модулей – функциональное моделирование, позволяющее структурировать схему преобразования входных данных (состояние пациента) в выходные (сценарий лечения) и определить необходимые подфункции, потоки информации и механизмы их реализации.
Цель исследования – представить обобщенный концептуальный подход к моделированию процесса автоматизированного формирования врачебного решения как ключевого этапа построения автоматизированных систем управления медицинскими технологическими процессами при хирургическом лечении.
Материал и методы исследования
Используемые подходы к построению функциональной модели
Исходным материалом для построения функциональных моделей – которые позволяют наглядно представить функции АСУ исследуемого класса и ее подсистем, их структуру, взаимосвязи компонентов и процессы работы – послужил анализ существующих подходов к построению автоматизированных систем и процессов в медицинской практике, а также результаты исследования авторов самого МТПХЛ как объекта автоматизированного управления, построения его концептуальной модели на основе теоретико-множественного подхода. Для формального описания МТПХЛ введен кортеж:
Modelconcept = <Ω, R, DInd, DContr, Ind, Contr, Z, U, M, F, O>, (1)
включающий следующие множества: Ω – универсум состояний пациента (антропометрические, функциональные, лабораторные данные, жалобы) и существующих диагнозов D; R – наблюдаемое (текущее) состояние пациента; DInd, DContr – абсолютные показания/противопоказания к операции (DInd ⊆ D – множество диагнозов, которые однозначно требуют хирургического лечения (абсолютные показания, например «Прободная язва» ∈ DInd, «Острая кишечная непроходимость» ∈ DInd); DContr ⊆ D – множество диагнозов, которые являются абсолютными противопоказаниями к любой хирургической операции, например «терминальная стадия онкологии» ∈ DContr, «агональное состояние» ∈ DContr); Ind, Contr – множество значений параметров и признаков, которые формируют показания/противопоказания к конкретному методу хирургического вмешательства; Z – множество сопутствующих (обеспечивающих) процессов, U – множество решений (консервативное лечение, сценарии операций, дополнительная диагностика); M – методологический инструментарий (методы, модели, алгоритмы для принятия промежуточных и итоговых врачебных решений, актуализирующие обратные связи в АСУ); F – решающая функция, которая по сути является отображением, реализуемым исследуемой системой из пространства наблюдаемых данных R в пространство решений U с использованием методологического инструментария M. Областью определения F будет декартово произведение булеанов B (множества всех подмножеств Ω, D, M):
F: B (Ω) ×B(D) × B (M) → U. (2)
Важный параметр U, фигурирующий в концептуальной модели (1) и соотношении (2), определяет множество всех возможных врачебных решений (пространство действий исследуемой системы). Например: U = {«здоров», «инфаркт миокарда», «необходима срочная операция», «назначить дополнительное обследование», ... }. В случае МТПХЛ жизненно важное значение имеет принятие врачебного решения о необходимости хирургического вмешательства, поэтому представим множество U как объединение нескольких подмножеств, а именно
U = P∪S∪H, (3)
где P = {p1,p2}, p1 = 0 (отказ от консервативного лечения в пользу хирургической операции), p2 = 1 (отказ от хирургической операции в пользу консервативного лечения); S – множество всех возможных сценариев хирургического лечения; H – множество дополнительной или расширенной диагностики (переход на новый цикл сбора данных – элементов Ω для формирования нового подмножества R).
Рис. 1. Обобщенная структурная схема АСУ МТПХЛ Примечание: составлен авторами по результатам данного исследования
Следует особо отметить, что представленная модель объекта автоматизированного управления, в отличие от известных теоретико-множественных представлений МТП, включает в качестве обязательного механизм автоматизированной поддержки принятия врачебных решений (промежуточных/итоговых):
M = Mmet∪Mmod∪Malg, (4)
где Mmet, Mmod, Malg – множество соответствующих методов, моделей, алгоритмов для реализации процесса автоматизированного принятия решений (например, деревья решений, регрессионные зависимости, искусственные нейронные сети, логические правила и др.).
На рис. 1 представлена обобщенная структурная схема АСУ МТПХЛ, демонстрирующая процесс взаимодействия исследуемого объекта автоматизированного управления с другими модулями АСУ, различные подсистемы которой составляют инструментарий для наполнения множеств в (1)–(3) и формирования базы знаний (БЗ).
В качестве метода функционального моделирования процесса автоматизированного формирования врачебного решения выбрана нотация IDEF0, поддерживаемая CASE-средством верхнего уровня BPwin. Данная нотация позволяет представить модель исследуемого процесса как набор взаимосвязанных функций (блоков), каждый из которых преобразует входы в выходы под действием управляющих воздействий и с использованием механизмов, продемонстрировать реализацию обратных связей, обеспечивающих замкнутость контура управления и адаптивность процесса принятия врачебных решений.
Для демонстрации последовательных действий при формировании конкретных сценариев лечения (u ∈ U, (2)) в АСУ рассматриваемого класса при актуализации разработанных теоретико-множественной и функциональной моделей разработан обобщенный алгоритм.
Методы тестирования результатов моделирования
Проведено ретроспективное тестирование на клинических данных. В исследование включены 50 обезличенных историй болезней пациентов, проходивших лечение в хирургических отделениях клиник Белгородского региона в 2024–2025 гг. Нозологии представлены следующими заболеваниями: острый панкреатит (12 историй), хронический панкреатит с осложнениями (8), желчнокаменная болезнь (15), другие хирургические заболевания органов брюшной полости (15).
Критерии включения: возраст старше 18 лет; наличие полного пакета первичной медицинской документации (история болезни, результаты лабораторных и инструментальных исследований, заключение врачебной комиссии); плановое или экстренное хирургическое лечение; отсутствие тяжелой сопутствующей патологии в стадии декомпенсации (для снижения гетерогенности выборки).
Критерии исключения: неполнота данных, препятствующая воспроизведению логики принятия решения; отказ пациента от подписанного информированного согласия на лечение (в рамках первичного лечения); наличие онкологических заболеваний на поздних стадиях (IV стадия), требующих паллиативной тактики вне рамок стандартных протоколов.
Исследование осуществлено с соблюдением требований анонимности персональных данных. Ввиду ретроспективного характера и использования обезличенных данных информированное согласие пациентов не требовалось, что соответствует положениям Хельсинкской декларации (версия 2024 г.). Для каждой истории болезни полученное модельное решение (сценарий лечения u ∈ U) сравнивалось с фактическим врачебным решением, принятым лечащим врачом или консилиумом и зафиксированным в итоговом эпикризе. Совпадением считалось полное соответствие рекомендованного системой и реализованного варианта лечения (операция с указанием метода / консервативная терапия / направление на дополнительную диагностику). Процент совпадений вычислен как отношение числа совпавших случаев к общему числу проанализированных историй (n = 50) с умножением на 100 %. Доверительные интервалы (95 %) для доли совпадений рассчитаны по методу Клоппера – Пирсона. Пограничными случаями определены ситуации, в которых решение модели не совпало с врачебным решением. Для каждого такого случая проведен экспертный анализ тремя независимыми хирургами (стаж работы > 10 лет) для оценки клинической обоснованности рекомендации системы.
Результаты исследования и их обсуждение
Построение функциональной модели
Основная функция системы определена как «Автоматизированное формирование врачебного решения» (блок А0). На рис. 2 представлена контекстная диаграмма.
Рис. 2. Контекстная диаграмма функциональной модели Примечание: составлен авторами по результатам данного исследования
Рис. 3. Декомпозиция контекстной диаграммы в соответствии с детализацией основной функции (нотация IDEF0) Примечание: составлен авторами по результатам данного исследования
Вход (I): данные о наблюдаемом состоянии пациента (I1), включающие инструментальные и лабораторные данные, жалобы, симптомы, текущие диагнозы и наследственные характеристики. Выход (O): итоговый сценарий лечения (O1) – решение о консервативной терапии, конкретный метод хирургического вмешательства или запрос на дополнительную диагностику. Управление (C): C1 – законодательные и нормативные документы (ГОСТы, требования к АСУ); C2 – клинические рекомендации и протоколы лечения; C3 – критические множества медицинских показаний и противопоказаний (1). Механизмы (M): M1 – техническая инфраструктура (ПО, компьютерная техника, исполнительные устройства); M2 – персонал (врач-пользователь, медицинский персонал, собирающий данные); M3 – методологический инструментарий: подмножества M (1), (4).
Для детализации процесса контекстная диаграмма декомпозирована на пять блоков согласно декомпозиции основной функции на пять подфункций (А1–А5) (рис. 3).
А1 «Сбор данных о состоянии пациента». Входы: I1 (первичные данные) и I2 (запрос на дополнительную диагностику, поступающий от А2 или А3). Выход: подмножество имеющихся данных R′ ⊂ R. Управление: C1, C2, C3. Механизмы: M1, M2.
А2 «Проверка полноты данных». Вход: R′ (выход А1). Выходы: полное наблюдаемое состояние R (если данных достаточно); запрос на дополнительную диагностику H (направляется на вход А1). Управление: C1, C2, C3. Механизмы: M1, M2, а также выделенный компонент механизма M3, а именно специализированные модели и алгоритмы проверки полноты данных MН ⊂М (Mmet), (4). Данная подфункция реализует обратную связь во внутренних контурах управления АСУ МТПХЛ: при выявлении недостаточности данных система инициирует дообследование пациента.
А3 «Оценка необходимости хирургического вмешательства». Вход: R (наблюдаемое состояние после проверки полноты). Выходы: решение p2 (отказ от операции в пользу консервативного лечения) → А5; решение p1 (необходимость операции) → А4; запрос на расширенную диагностику H (при конкурирующих вариантах p1 и p2) → А1. Управление: C3 (критические множества абсолютных показаний/противопоказаний). Реализуемые механизмы: M1, M3, а именно выделенный компонент Mneed ⊂М (4) – это множество моделей и алгоритмов, реализующих автоматизированную оценку необходимости хирургического вмешательства.
А4 «Выбор метода хирургического лечения». Входы: R (состояние пациента) и p1 (решение о необходимости хирургической операции). Выход: конкретный вид хирургического вмешательства (Smeth∈S, (1)). Управление: C3 (показания и противопоказания к конкретным методам – Ind, Contr, (1). Механизмы: M1, M3, а именно, компонент Mmeth ⊂М (4) – это множество моделей и алгоритмов автоматизированного выбора конкретного метода хирургического вмешательства из представленных в БЗ АСУ МТПХЛ.
А5 «Формирование итогового врачебного решения». Входы: R (состояние пациента), решение P (из А3), выбранный вид операции Smeth (из А4, если требуется). Выход: итоговый сценарий лечения u ∈ U (3). Управление: C1, C2, C3. Механизмы: M1, M2.
Алгоритм автоматизированного формирования сценариев лечения
На рис. 4 представлен обобщенный алгоритм (обозначим m1alg∈Malg, (4), актуализирующий автоматизированное формирование рекомендуемых вариантов хирургического лечения на основе комплекса имеющихся (изменившихся/прогнозируемых) данных о состоянии пациента согласно представленным выше моделям, на основе двухэтапного формата: решение о необходимости реализации хирургического вмешательства или проведения консервативного лечения, P; выбор метода хирургического вмешательства Smeth ∈ S и формирование итогового сценария u ∈ U.
Результатом сбора данных является формирование множества наблюдаемого состояния конкретного пациента R, эти данные заносятся в специализированную базу данных, которая в том числе в последующем может быть использована для формирования/корректировки/уточнения математических и ситуационных моделей (компонентов множества M, (4)), разработанных и хранящихся в банке моделей в БЗ исследуемой АСУ. Проверка имеющихся данных (реализация специализированного механизма из множества M) определяет их полноту и возможное формирование первичного врачебного решения.
В случае, когда врач приходит к выводу о достаточной полноте данных, актуализируется процедура для оценки необходимости хирургического вмешательства – подмножество Mneed ⊂ M. Механизм в виде разработанных для решения данной задачи моделей и алгоритмов также вызывается из БЗ АСУ МТПХЛ.
Рис. 4. Обобщенный алгоритм автоматизированного формирования сценария хирургического лечения Примечание: составлен авторами по результатам данного исследования
Результаты принятого решения соответственно заносятся в специализированную базу данных для дальнейшего использования в практике принятия решений или моделировании. Механизм Mneed включает оценку конкретных параметров из критических множеств DInd, DContr ⊆ D (1), других составляющих множества Ω. Соответствующим врачебным решением может быть: u = p2, где p2 ∈ P в случае, когда есть абсолютные противопоказания к хирургическому вмешательству или когда терапевтического лечения достаточно для решения возникшей ситуации; u = s, где s ∈ S в случае необходимости и рациональности хирургического вмешательства с дальнейшим выбором наименее рискованной допустимой операции (консервативный вариант исключен); u = h, где h ∈ H в случае необходимости проведения расширенной диагностики.
На следующем шаге представленного алгоритма реализуется механизм оценки и выбора метода хирургического лечения – комплекс специализированных моделей и алгоритмов из подмножества Mmeth ⊂ M (также вызывается из БЗ АСУ МТПХЛ). На этом этапе реализуется анализ конкретных параметров из критических множеств Ind, Contr (1), а также других компонентов множества Ω.
В случае необходимости проведения хирургического вмешательства и выбора конкретного метода лечения результирующий сценарий лечения s представим в виде следующего модернизированного кортежа: s = (название выбранного метода хирургического вмешательства Smeth, целевой орган, уровень срочности операции, уровень инвазивности, риски, источник информации о состоянии пациента). Некоторые конкретные примеры, полученные на основе взаимодействия с экспертами предметной области: s1 = («Лапароскопическая холецистэктомия», «Желчный пузырь», «Плановая», «Минимально инвазивная», «Риск интраоперационного кровотечения, повреждения желчных протоков, послеоперационная инфекция», «УЗИ брюшной полости, клинический анализ крови, анамнез пациента»); s2 = («Эндоваскулярное стентирование», «Аорта», «Срочная (при расслаивающей аневризме)», «Минимально инвазивная», «Тромбоз, миграция стента, повреждение сосуда», «КТ-ангиография, ЭхоКГ, данные гемодинамики»); s3 = («Лапаротомия с ревизией кишечника», «Тонкий кишечник», «Экстренная», «Открытая, полостная», «Некроз кишки, сепсис, спаечная болезнь», «Жалобы на схваткообразные боли в животе, задержку стула и газов, рвоту»).
Таким образом, обеспечивается возможность управления процессом принятия стратегического врачебного решения в АСУ МТПХЛ на основе формализованных медицинских знаний.
Результаты тестирования
При тестировании на выборке из 50 историй болезней совпадение рекомендаций разработанного решения (с использованием предложенных моделей и алгоритма) с фактически принятыми врачебными решениями составило 46 случаев (92 %) при 95 % доверительном интервале для доли совпадений 80,5–98,0 %. Полученные расхождения (8 %, 4 истории) отмечены в следующих клинических ситуациях: 2 случая острого панкреатита (модель предлагала динамическое наблюдение и дополнительную диагностику, врачи выполнили дренирующую операцию); 2 случая хронического панкреатита (модель настаивала на консервативной терапии, врачи провели хирургическое вмешательство ввиду болевого синдрома, который система оценила как купируемый). Все 4 случая расхождения признаны пограничными случаями, при этом экспертная оценка, проведенная хирургами, показала, что в 3 из 4 случаев (75 %) решение модели было клинически допустимым и безопасным, однако врачи выбрали более активную тактику, руководствуясь дополнительными факторами. В одном случае (острый панкреатит) эксперты поддержали решение врачей, указав на недостаточную чувствительность модели к динамике воспалительных маркеров.
Следует отметить часть полученных в процессе тестирования совпадений (12 случаев, 24 %), в которых как система инициировала запрос на дополнительную диагностику (обратная связь от блоков А2/А3 к А1), так и назначения врачей включали процесс дообследования, а именно: компьютерную томографию брюшной полости (5 случаев), динамический анализ лейкоцитов и С-реактивного белка (4), ультразвуковое исследование с допплерографией (3). В 10 из этих 12 случаев (83 %) дополнительное обследование позволило снять неопределенность и принять обоснованное решение: в 7 случаях рекомендована операция, в 3 – консервативная терапия. В 2 оставшихся случаях (17 %) неопределенность сохранилась, и окончательное решение принимал консилиум врачей.
Разработанная функциональная модель процесса автоматизированного принятия врачебных решений при хирургическом лечении обладает рядом преимуществ. Прежде всего, это полнота охвата, так как модель включает все ключевые этапы принятия врачебного решения от сбора данных до формирования итогового сценария, используя механизм запроса недостающей информации (обратные связи от А2 и А3 к А1). Кроме того, это соответствие клинической логике; управляемость: наличие управляющих потоков C1–C3 позволяет учитывать внешние нормативные требования и медицинские знания, задать ограничения для принятия решений с использованием критических множеств (показаний/противопоказаний).
Модель легко модифицировать при изменении клинических протоколов, провести дальнейшую детализацию: каждая подфункция (особенно А3 и А4) может быть подвергнута собственной декомпозиции для уточнения логики работы. Научная новизна построенной функциональной модели определяется выделением методологического инструментария (M3) в качестве отдельного механизма автоматизированного анализа, который включает: модели и алгоритмы проверки полноты данных (MН); модели и алгоритмы оценки необходимости хирургического вмешательства (Mneed); модели и алгоритмы выбора метода операции (Mmeth). Все они являются частью БЗ АСУ МТПХЛ и при совместном применении с представленным алгоритмом формирования сценариев управления обеспечивают обратную связь во внешних и внутренних контурах управления системой (подсистемами).
В пилотной ретроспективной проверке на ограниченной выборке (50 историй) получены следующие результаты: 92 % совпадений с реальным врачебным решением с 95 % доверительным интервалом [80,5‒98,0] %, которые требуют внешней проспективной валидации. Отмеченные расхождения (8 %) в основном касались пограничных случаев, где модель предлагала консервативную тактику или дополнительную диагностику, что врачи сочли безопасным.
Представленные модели и алгоритм определяют структуру АСУ рассматриваемого класса с реализацией обратной связи как неотъемлемого элемента, обеспечивающего замкнутость контура управления (в том числе, внутренних контуров управления) и адаптивность процесса принятия врачебных решений. Так, введение обратной связи от блока А2 («Проверка полноты данных») к блоку А1 («Сбор данных») позволяет: формализовать правило «если ∃ недостающие данные, то выдать запрос H на дообследование»; повторно выполнить сбор данных и пересчитать R′ → R до достижения полноты или до возникновения ситуации, когда дальнейшее обследование нецелесообразно.
Следует отметить, что на этапе оценки необходимости хирургического вмешательства (блок А3) часто возникают ситуации, когда на основании имеющихся данных невозможно однозначно выбрать между консервативным лечением (p₂) и операцией (p₁). Это так называемые «серые зоны» клинической логики. В данном случае рационально реализовать специализированную систему правил (составляющая множества M), при актуализации которых система генерирует не итоговое решение, а запрос на расширенную диагностику (H), который поступает на вход А1. Это второй контур обратной связи (от А3 к А1). Он позволяет преодолеть уровень неопределенности между p₁ и p₂. Без такой обратной связи автоматизированная система была бы вынуждена либо произвольно выбирать один из вариантов, либо блокироваться в неопределенности.
Состояние пациента может ухудшаться или улучшаться во времени. Классические разомкнутые системы (без обратной связи) не способны отслеживать эти изменения и корректировать управляющие воздействия. В предложенной архитектуре обратная связь может быть реализована не только на уровне проверки полноты, но и на уровне повторного входа в алгоритм после выполнения назначенной диагностики или при поступлении новых клинических данных в БЗ. В этом случае при актуализации обобщенного алгоритма (рис. 4) возможно автоматическое возвращение к этапу сбора данных (А1), обновление R и повторное выполнение оценки (А3) и выбора метода (А4).
Уровень совпадения (92 %), полученный на предварительных данных, сопоставим с опубликованными результатами для аналогичных систем (например, более 80 % в работе [14] или обзоре [15]), но окончательное суждение о пригодности модели для клинического применения может быть сделано только после дополнительной валидации. Полученные предварительные данные позволяют предположить потенциальную возможность использования модели в качестве «второго мнения» для снижения риска врачебной ошибки.
Полученные результаты следует интерпретировать с учетом ограничений: относительно небольшой объем выборки (n = 50), ретроспективный дизайн, преобладание определенных нозологий. Кроме того, тестирование проводилось на обезличенных данных без учета динамики состояния в реальном времени, тогда как в клинической практике врачи учитывают изменение параметров за короткие интервалы. Дальнейшее развитие научной работы связано с проведением исследований на больших выборках с различной нозологической структурой.
Заключение
Разработанные модели и алгоритм формализуют процесс принятия врачебного решения в АСУ МТПХЛ с обеспечением реализации обратных связей во внутренних контурах управления данной системы (проверка полноты, оценка необходимости хирургической операции, выбор метода). Выделены специализированные подмножества методологического инструментария, которые должны быть реализованы в БЗ АСУ.
В пилотном ретроспективном тестировании на ограниченной выборке (50 историй) получено совпадение с реальными врачебными решениями в 92 % случаев (95 % доверительный интервал по методу Клоппера – Пирсона составил [80,8–97,8] %), а механизм обратной связи для запроса дополнительной диагностики показал эффективность в 83 % неопределенных ситуаций. Требуется внешняя и проспективная валидация на более представительных выборках.
Представленный методологический инструментарий может быть использован при построении интеллектуальных систем поддержки принятия решений в составе конкретных АСУ технологическими процессами хирургического профиля.
Conflict of interest
Financing
Библиографическая ссылка
Иващук О.А., Самофалов Д.А., Нестеров Д.В. ФУНКЦИОНАЛЬНОЕ МОДЕЛИРОВАНИЕ АВТОМАТИЗИРОВАННОГО ПРОЦЕССА ПРИНЯТИЯ ВРАЧЕБНЫХ РЕШЕНИЙ ПРИ ХИРУРГИЧЕСКОМ ЛЕЧЕНИИ // Современные наукоемкие технологии. 2026. № 7. С. 70-80;URL: https://top-technologies.ru/en/article/view?id=40861 (дата обращения: 12.08.2026).