CC BY
24
УПРАВЛЕНИЕ В МЕДИЦИНЕ И БИОЛОГИИ /
УДК 004.895
doi:10.31799/1684-8853-2019-5-64-75
Применение автоматного подхода для персонализированной поддержки клинических процессов в медицине
Ю. В. Аксенова, студент orcid.org/0000-0002-1835-2237
Н. В. Добренкоа, старший преподаватель, orcid.org/0000-0001-6206-8033
А. С. Ватьяна, ассистент, orcid.org/0000-0002-5483-716X
Р. О. Капустина студент, orcid.org/0000-0003-3027-2704
С. В. Осипова, студент, orcid.org/0000-0002-5761-4703
П. Ю. Маврина, студент, orcid.org/0000-0001-8530-0077
Н. Ф. Гусароваа, канд. техн. наук, доцент, orcid.org/0000-0002-1361-6037
А. А. Шалытоа, доктор техн. наук, профессор orcid.org/0000-0002-2723-2077, shalyto@mail.ifmo.ru аСанкт-Петербургский национальный исследовательский университет информационных технологий, механики и оптики, Кронверкский пр., 49, Санкт-Петербург, 197101, РФ
Введение: в рамках Национального проекта «Здравоохранение» большая роль отводится персонализации деятельности врача, для чего требуются системы поддержки принятия клинических решений. В существующих системах отсутствуют функции подсказки действий врача в ходе клинического процесса и выявления возможных противоречий между различными видами медицинских мероприятий, предлагаемых пациенту. Цель: разработка решения для персонализированной поддержки клинических процессов, свободного от указанных проблем. Методы: автоматный подход, который представляет клинический процесс как набор автоматных состояний и возможных переходов между ними, и набор паттернов проектирования Abstract Factory, Facade, Adapter и Visitor. Результаты: предложено решение для персонализированной поддержки клинических процессов на базе автоматного подхода и паттернов проектирования. Автоматный подход позволяет разделить клинический процесс на отдельные этапы и автоматически контролировать возможные переходы и условия их осуществления, включая проверку на наличие противопоказаний. Использование паттернов проектирования обеспечивает достаточную степень обобщенности, в результате можно, не затрагивая структуру основного кода приложения, оперативно подключать к системе необходимые источники информации, а также вносить в систему информацию о противоречиях различного генеза и учитывать их при принятии решения о ведении конкретного пациента. Практическая значимость: разработанное решение более эффективно, нежели в имеющихся системах, реализует подсказку действий врача в ходе клинического процесса и выявляет возможные противоречия между различными видами медицинских мероприятий, предлагаемых пациенту.
Ключевые слова — автоматное программирование, управляющие конечные автоматы, клинические протоколы, поддержка принятия решения, медицинские процессы.
Научные статьи Articles
Для цитирования: Аксенов Ю. В., Добренко Н. В., Ватьян А. С., Капустин Р. О., Осипов С. В., Маврин П. Ю., Гусарова Н. Ф., Шалыто А. А. Применение автоматного подхода для персонализированной поддержки клинических процессов в медицине. Информационно-управляющие системы, 2019, № 5, с. 64-75. doi:10.31799/1684-8853-2019-5-64-75
For citation: Aksenov I. V., Dobrenko N. V., Vatyan A. S., Kapustin R. O., Osipov S. V., Mavrin P. Y., Gusarova N. F., Shalyto A. A. Automata approach for personalized support of clinical processes in healthcare. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2019, no. 5, pp. 64-75 (In Russian). doi:10.31799/1684-8853-2019-5-64-75
Введение
Одним из ключевых направлений Национального проекта «Здравоохранение» на 2018-2024 гг. является развитие электронного здравоохранения. В рамках обширного комплекса задач этого направления Минздрав РФ выделяет создание систем поддержки принятия клинических решений (СПКР) для врачей в форме «...рабочего стола как клинического протокола, который подсказывает алгоритмы дальнейших действий — в плане и тактических лечебных (что нужно и как провести), и дополнительного обследования» [1]. Среди большого и во многом противоречивого набора ограничений (О), которому должна удовлетво-
рять СПКР, ключевыми представляются следующие.
01. Стандартизация. СПКР должна соответствовать рамочным стандартам, принятым в здравоохранении, в том числе в аспекте терминологии, и в то же время адаптироваться под конкретные стандарты лечебного учреждения. Так, в настоящее время в медицинских учреждениях РФ используются разные информационные стандарты (например, 13606/OpenEHR Archetypes [2], Health Level 7 [3]), различающиеся не только по модели данных, но даже по терминологии.
02. Персонализация. СПКР должна предоставить врачу возможность при каждом принятии решения учитывать специфические особенности
конкретного пациента, в том числе индивидуальные реакции на лекарственные препараты и другие потенциально возможные противопоказания.
О3. Безопасность и целостность данных. В РФ действует комплекс законодательных актов, направленных на защиту медицинской информации (в том числе № 323-ФЭ и 152-ФЗ), обеспечивающий конфиденциальность персональных данных. Как показывает практика, не менее важной проблемой является защита от несанкционированного изменения и предумышленной фальсификации, причем со стороны не только медицинского, но и технического персонала, и даже самого пациента.
Учитывая эти ограничения, можно сформулировать концептуальные требования (Т) к архитектурному решению СПКР:
Т1) гибкое взаимодействие со сложной и многосвязной структурой медицинских данных в целом, при этом изменения в структуре данных должны как можно меньше влиять на прикладной программный код;
Т2) гибкая структура запросов, организуемых, как правило, по сценарному типу;
Т3) расширяемость в соответствии с вновь возникающими классами задач, характерными для конкретного пациента.
На рынке и в литературе представлены разнообразные системы, поддерживающие различные аспекты электронного здравоохранения (их краткий обзор приведен в первом разделе). Но, как показывает анализ и подтверждает практика, среди них отсутствуют системы, полномасштабно удовлетворяющие сформулированным выше требованиям и ограничениям. В настоящей статье предлагается решение для разработки таких систем на базе автоматного подхода [4].
Терминология и существующие решения
Выбор понятийной и терминологической базы во многом предопределяет эффективность любой медицинской информационной системы, и СПКР в том числе [5]. В настоящей работе мы опираемся на терминологию системы стандартов ИСО «Медицинская информатика», одним из разработчиков которой явилась РФ, в частности, на стандарт [6], который определяет следующие понятия:
— клинический процесс (clinical process — CР) — медицинский процесс, охватывающий все действия поставщиков медицинских услуг;
— состояние здоровья (health state — HS) — физические и психические функции, структура тела, личностные факторы, активность, участие и экологические аспекты как составляющие эле-
менты здоровья субъекта; в рамках клинического процесса рассматриваются отдельные клинические состояния здоровья;
— клинические симптомы (health condition — HC) — наблюдаемые или потенциально наблюдаемые аспекты состояния здоровья в данный момент времени;
— клиническое мероприятие (healthcare activity — HA) — деятельность, направленная прямо или косвенно на улучшение или поддержание состояния здоровья; оно может состоять из нескольких компонентов;
— клинический факт (healthcare matter — HM) — факт, который определен одним из субъектов клинического процесса как относящийся к здоровью пациента.
Преимущество этой системы терминов состоит в том, что она, с одной стороны, легко интерпретируется врачом, а с другой стороны, может быть непосредственно транслирована в концепты информационной системы. В качестве примера в табл. 1 представлен фрагмент описания клинического процесса бронхиальной астмы [7, 8], а в табл. 2 — формализованное описание его компонентов через клинические факты.
На российском рынке достаточно широко представлены различные СПКР [9]. Детальный анализ показал, что в них по отдельности или в комбинации реализуется следующий функционал: поддержка отдельных диагностических процедур (например, автоматизированный анализ рентгенограмм, КТ- и МРТ-изображений); статистическая оценка показателей и доступ к медицинским калькуляторам; информационно-справочные функции (например, проверка совместимости лекарств, структурированный доступ к медицинской информации); протоколирование показателей в ходе удаленного мониторинга пациентов; ручное протоколирование выполнения назначений (в ходе лечения в клинике). Однако функцию подсказки алгоритмов действий врача в ходе клинического процесса, заявленную в работе [1], в них обнаружить не удалось.
Недостаточное внимание в существующих СПКР уделяется также персонализации. Обзор решений в области медицинских информационных систем показывает, что в них преобладает подход типизации различных аспектов клинического процесса, т. е. формирование и поддержка единого процесса для определенных групп пациентов. Например, в работе [10] предлагается система многосторонней поддержки типичного хирургического процесса, а в [11, 12] — группирование пациентов в процессе лечения в зависимости от того, какую помощь они получали ранее. С другой стороны, системы типа [13], нацеленные на персонализацию диагностического процесса, обычно строго адаптированы к узкому заболева-
■ Таблица 1. Содержательное описание клинического процесса
■ Table 1. Overall description of the clinical process
Состояние здоровья Клинические симптомы Клинические мероприятия
HS0 НС0. Исчезновение свистящих хрипов, пиковая скорость выхода (ПСВ) > 80 % от лучшей или должной НА0. Амбулаторное лечение
HS1 НС1. Признаки приступа бронхиальной астмы НА1. Продолжить прием ß2 агонистов длительного действия (LABA) каждые 3-4 часа
HS2 НС2. Свистящие хрипы остаются, ПСВ = 60-80 % от лучшей или должной НА2.1. Предложить госпитализацию в стационар НА2.2. При отказе от госпитализации: продолжить LABA в прежней дозе каждый час + преднизолон внутрь 30 мг + осмотр пульмонолога для коррекции базовой терапии
HS3 НС3. Нарастание симптоматики, ПСВ < 60 % от лучшей или должной НА3.1. Предложить госпитализацию в стационар НА3.2. Продолжить LABA + глюкокортикостероиды (ГКС) перорально (преднизолон 30 мг) + ингаляции атровента 40 мг через дозированный аэрозоль, или 0,5 мг через небулайзер, или эуфиллин 2,4 % — 10,0 внутривенно медленно
HS4 НС4. Стационарный этап, среднетяжелое обострение (нарастание симптоматики, ПСВ < 60 % от лучшей или должной, вр02 < 90 %) HA4.1. ß2 агонисты короткого действия (SABA) через небулайзер по одной дозе (вентолин 2,5 мг или беротек 0,5 мг) каждые 20 мин в течение первого часа (если не проводились амбулаторно), далее SABA в прежних дозах каждые 60 мин через небулайзер HA4.2. Оксигенотерапия для достижения сатурации SpO2 > 90 %
HS5 Стационарный этап лечения, неполный ответ (ПСВ = 50-70 % от лучшей или должной, вр02 < 90 %) HA5. Системные кортикостероиды (СКС) внутривенно (преднизолон 90 мг, солюкортеф 100-200 мг), эуфиллин внутривенно капельно (мониторинг эуфиллина)
HS6 Отсутствие улучшения HA6. Перевод в отделение интенсивной терапии (ОИТ)
■ Таблица 2. Формализованное описание компонентов клинического процесса
■ Table 2. Formalized description of the components of the clinical process
Наименование Содержание Значения
НМС — клинические факты, отражающие клинические симптомы НМ1. Свистящие хрипы (СХ) НМ2. ПСВ НМ1.1. <есть СХ> НМ1.2. <нет СХ> НМ2.1. <ПСВ = 100-80 %> НМ2.1. <ПСВ = 80-60 %> НМ2.3. <ПСВ <60 %> НМ2.4. <ПСВ = 50-70 %>
НМ3. Бр02 НМ3.1. <SpO2 = 100-90 %> НМ3.2. <SpO2 <90 %>
НМ4. Этап лечения НМ4.1. <на дому> НМ4.2. <амбулатория> НМ4.3. <стационар> НМ4.4. <ОИТ> НМ4.5. <отказ от госпитализации>
НМ5. Динамика состояния НМ5.1. <есть улучшение> НМ5.2. <нет улучшения> НМ5.3. <нарастание симптоматики>
■ Окончание табл. 2
■ Table 2 (compl.)
Наименование Содержание Значения
НМА — клинические НМ6. LABA НМ6.1. ^АБА, М = 3-4 ч>
факты, отражающие клинические мероприятия НМ7. SABA НМ7.1. <ЯАБА, М = 0,3 ч> НМ7.2. <ЯАБА, М = 1 ч>
НМ8. ГКС НМ8.1. <преднизолон, 30 мг>
НМ9. СКС НМ9.1. <преднизолон, 90 мг, в/в> НМ9.2. <солу-кортеф, 100-200 мг, в/в> НМ9.3. <атровент, ингаляции>
НМ10. Оксигенотерапия НМ 10.1. <оксигенотерапия>
НМ11. Эуфиллин НМ11.1 <эуфиллин, в/в>
НМ12. Осмотр пульмонолога НМ12.1 <осмотр пульмонолога>
НА — клинические НА0 НМ4.1 + НМ6.1
мероприятия НА1 НМ4.1
НА2.1 НМ4.3
НА2.2 НМ6.1 + НМ8.1 + НМ12.1
НА3.1 НМ4.3
НА3.2 НМ6.1 + НМ8.1 + НМ9.3 + НМ11.1
НА4.1 НМ7.1 + НМ7.2 + НМ10
НА5 НМ9.1 + НМ9.2 + НМ11.1
НА6 НМ4.4
НС — клинические НС0 НМ1.2 + НМ2.1
симптомы НС1 <диагностические признаки + анамнез>
НС2 НМ1.1 + НМ2.1
НС3 НМ2.3
НС4 НМ2.3 + НМ3.2
НС5 НМ2.4 + НМ3.2
НС6 НМ2.4 + НМ3.2
нию и не обеспечивают необходимой вариативности в принятии врачебных решений.
Существенную роль в персонализации клинического процесса играют возможные противоречия между различными видами медицинских мероприятий, предлагаемых пациенту, выявить которые еще на стадии принятия решения — одна из задач СПКР. Например, назначаемое лекарство может ухудшить течение другой болезни, которой страдает пациент (противоречие НА-СР), может быть противопоказано ему в связи с некоторыми параметрами анамнеза (противоречие НА-НЯ) или вступать в нежелательные взаимодействия с другими лекарствами, которые принимает пациент (противоречие НА-НА). Для выявления таких противоречий предложены два подхода.
Первый подход основан на объединении всей доступной информации о противопоказаниях в единую базу данных, к которой врач должен самостоятельно формировать запросы [14-16]. Очевидно, что такая интегрированная база становится очень «тяжелой», соответствующие системы являются проприетарными (см. примеры [15]), врачи не могут вносить в них изменения и с трудом осваивают их на практике.
Предлагаются также «легкие» решения для выявления противоречий по конкретному пациенту или заболеванию. Для этого использованы, например, онтологический подход — связывание интересующих терминов (названий лекарств и диагнозов) с собственными и (или) сторонними он-тологиями и SPARQL-запрос на поиск лекарств, которые могут вступить во взаимодействие [17]. Применяются также системы продукционных правил или логические выражения [18-20]. Такие системы создаются вручную для конкретной задачи и не допускают масштабирования.
Выбранный концептуальный и терминологический подход к описанию клинических процессов, проиллюстрированный табл. 1, позволяет применить для их моделирования в рамках СПКР такой мощный подход, как автоматное программирование [4, 21]. Концепция автоматов достаточно широко используется в здравоохранении, например, для оценки распространения бактерий при заболевании [22], для планирования удаленного ухода за пациентами [23], для анализа эффективности взаимодействия между отдельными органами [24]. Однако при моделировании собственно клинических процессов автоматный подход использу-
ется только как жестко детерминированная конструкция [10, 11, 25], в то время как современные средства поддержки автоматного программирования предоставляют широкие возможности для моделирования процессов принятия решения [26].
Таким образом, проведенный обзор подтвердил, что сформулированные во введении требования к СПКР остаются в значительной степени невыполненными, и в то же время позволил определить адекватную терминологическую структуру и программный подход для их моделирования.
Предлагаемое решение
Автоматная модель
Решение базируется на автоматной модели, которая представляет клинический процесс как набор автоматных состояний и возможных переходов между ними. На рис. 1 изображена диаграмма состояний автомата, описывающего фрагмент клинического процесса бронхиальной астмы в соответствии с табл. 1. Конкретному клиническому состоянию (НЯ) может соответствовать несколько автоматных состояний (АЯ), каждое из которых описывается набором клинических фактов (НМА), отражающих клинические мероприятия (НА). Условия переходов между состояниями задаются наборами клинических фактов (НМС), отражающих клинические симптомы (НС).
В табл. 3 представлены компоненты диаграммы состояний в терминах типовой автоматной модели [4]:
А = (Е, Я, ТБ, Р),
где 2 — входной алфавит; Я — конечное множество состояний автомата; — начальное состоя-
■ Таблица 3. Компоненты диаграммы состояний в терминах автоматной модели
■ Table 3. Components of the state diagram in terms of automata model
Компонент автоматной модели Компоненты модели клинического процесса
X НС0, НС1, НС2, НС3, НС4, НС5, НС6
Q НА0, НА1, НА2.1, НА2.2, НА3.1, НА3.2, НА4.1, НА5, НА6
% НМ4.1
TS Нвд0£ (Not asthma), Нв0£ (Ambulatory treatment), Нв3£ (Ambulatory treatment), Нв4£ (Ambulatory treatment), Нвб£ (Intensive care unit)
р Р1-Р30
ние; ТБ — множество конечных состояний; Р — функции переходов.
Выделим специфику предложенной автоматной модели в связи с ее применением в клиническом процессе. Все функции переходов здесь яв-
Яо
Диагностика
[HC1]
t1 = 0,25-0,5 ч
I
HS1
dO/HA1
[HC0]
HSOi Амбулаторное лечение
HSqot
[Астма не обнаружена]
HS3i Амбулаторное лечение
HS4t Амбулаторное лечение
■ Рис. 1. Диаграмма состояний автомата
■ Fig. 1. The generalized automata model
ляются не абсолютными, а информирующими — в определенный момент инициируют оповещение врача о необходимости перехода. Момент принятия врачебного решения о переходе может быть установлен таймером или счетчиком возвратов, который соотнесен с соответствующим клиническим симптомом.
Применение автоматной модели дает следующие преимущества:
— возможна формальная проверка и протоколирование действий всех участников клинического процесса;
— улучшается наблюдаемость клинического процесса за счет использования одной внутренней переменной;
— внутри каждого состояния легко организовывать новые и взаимозаменяемые исследования, что позволяет гибко адаптировать клинический процесс к изменяющимся внешним условиям.
Модель системы
Опишем функциональность предлагаемой системы, приведем ее общую схему, а затем подробно рассмотрим все этапы ее работы.
Идея функционирования системы заключается в следующем. Она агрегирует в себе информацию о пациенте: анамнез, медицинские противопоказания, результаты медицинских исследований, сдачи анализов и измерений. На основе этих данных с учетом противопоказаний, анамнеза и текущего состояния автоматной модели формируются списки доступных переходов автоматной модели, рекомендуемых переходов и возможных противопоказаний.
Пользователь системы делает выбор следующего состояния из предложенного списка доступных переходов. Процесс смены состояний длится до момента достижения одного из терминальных состояний. Каждое такое состояние соответствует определенному мероприятию, например выздоровление, госпитализация, изменение поставленного ранее диагноза и, соответственно, лечения.
Противопоказания могут быть сформированы на основе данных, хранящихся в различных источниках. Это может быть база данных, кэш-системы, внешние онтологии и EHR (электронная медицинская карта). На основе анализа внешних источников информации формируются новые пары противопоказаний.
Можно выделить следующие основные этапы работы системы:
1) инициализация нового клинического процесса;
2) создание новой сущности пациента;
3) вход в текущее состояние, оповещение о нем;
4) заполнение анамнеза пациента;
5) фиксация медицинских противопоказаний пациента;
6) внесение результатов анализов и измерений, получение необходимой внешней информации;
7) проверка условий выхода из текущего состояния;
8) формирование оповещения о необходимости перехода;
9) оценка рекомендуемых состояний на основе информации о противопоказаниях;
10) предоставление информации о доступных состояниях, рекомендованном состоянии и противопоказаниях;
11) переход в новое состояние автоматной модели;
12) достижение одного из терминальных состояний.
Модель данных разработанной системы представлена на рис. 2. Базовыми сущностями являются классы Patient и ClinicalProcess. В классе Patient аккумулируются три типа информации о пациенте:
— информация о клинических симптомах, отражающих течение клинического процесса; класс Patient содержит коллекцию экземпляров класса Measurements;
— информация из анамнеза пациента, относящаяся к данному клиническому процессу; она хранится в классе CaseHistory, ассоциированном с классом Patient;
— информация о специфичных для данного пациента последствиях перехода в то или иное состояние; она поступает из интерфейсного класса Contradiction.
Класс ClinicalProcess содержит коллекцию экземпляров класса State, которые базируются на информации только первого типа. Возможности персонализации клинического процесса обеспечиваются ассоциативной связью классов ClinicalProcess и Patient.
Таким образом, предлагаемая система поддерживает работу врача в соответствии с базовым клиническим процессом, определяемым после-
■ Рис. 2. Модель данных
■ Fig. 2. Data model
довательностью состояний автоматной модели, и в то же время позволяет, при необходимости и (или) при наличии соответствующей информации, производить персонализацию клинического процесса, учитывая данные анамнеза конкретного больного и сведения о возможных противоречиях в назначениях.
Паттерны проектирования
как средство описания противоречий
В ходе клинического процесса между различными медицинскими мероприятиями могут возникать противоречия, о которых желательно информировать врача еще на стадии принятия врачебного решения о переходе в следующее состояние. Как показал анализ, описанные выше подходы к их выявлению не в полной мере отвечают сформулированным выше требованиям к СПКР, особенно к Т2 и Т3. Следуя реальной клинической практике, в разрабатываемом решении предлагается постепенное наращивание перечня клинических фактов и (или) медицинских мероприятий, которые врач считает нужным принимать во внимание при оценке потенциальных противоречий в ходе лечения конкретного больного. С этой целью решение строится с использованием паттерна проектирования Абстрактная фабрика (Abstract Factory) [27, 28], который предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя их конкретных классов. Пример структуры классов для описания противоречий на основе паттерна Abstract Factory представлен на рис. 3.
Интерфейсный класс IMedicalFactory (см. рис. 3) порождает конкретные фабрики, каждая из которых соответствует одной из вышеупомянутых пар источников противоречий: Disease-Factory содержит описание противоречия НА-НР, DrugFactory — противоречия НА-НА, Anamnesis-Factory — противоречия НА-Нв.
Достоинством паттерна Abstract Factory применительно к решаемой задаче является то, что он позволяет конфигурировать систему в целом любым семейством составляющих ее объектов. В зависимости от того, какой именно клинический факт врач выбирает в качестве приоритетного источника противоречий, управление передается той или иной конкретной фабрике, которая инициирует формирование соответствующего списка противопоказаний и возможных замен. Например, если врач считает, что главным источником проблем при переходе к следующему состоянию, т. е. при назначении конкретного лекарства, будет возраст пациента, то создается экземпляр фабрики AnamnesisFactory, которая покажет противопоказания к применению конкретного лекарства по возрасту, а также возможные альтернативы.
Паттерн Посетитель (Visitor) используется для того, чтобы вынести логику принятия решения из самих состояний, что позволяет проектировщику системы добавлять операции обработки конкретных состояний, не изменяя классы самих состояний. Например, если в качестве источника противоречий требуется реализовать обработку какого-либо компонента анамнеза, то при отсутствии паттерна Visitor нужно было бы добавить метод обработки этого компонента в каждый дочерний класс класса BaseState (см. рис. 3).
В системе обрабатываются события различных типов: как связанные с динамикой клинических фактов, так и инспирируемые врачом и связанные с принятием врачебных решений. Прием событий первого типа осуществляется производными классами интерфейсов IVisitor и IContradictionProvider. На основе этих данных они принимают решение о возможности перехода в доступные состояния и наличии противопоказаний. Для управления обработкой событий, поступающих от врача, служит класс AutomataDispatcher. Методы этого класса setFactory() и setState() устанавливают текущую фабрику (в соответствии с решением врача о приоритете лекарства, болезни или анамнеза пациента) и выбранное врачом состояние, относительно которого формируется желаемая информация. Методы getAvailableStates() и getContradictions() возвращают информацию о доступных для перехода в данный момент состояниях и текущих противопоказаниях.
Для принятия клинических решений врачу должен быть предоставлен оперативный доступ к разнообразным источникам информации. С этой целью используется паттерн Адаптер (Adapter), который позволяет получить доступ к различным источникам данных, в том числе к EHR пациента и к внешним онтологиям, в унифицированном формате.
Класс AutomataDispatcher, реализующий паттерн Фасад (Facade), позволяет скрыть сложность системы путем агрегирования всех возможных внешних вызовов к объекту данного класса.
Таким образом, использование паттернов проектирования Abstract Factory, Facade, Adapter и Visitor в предложенном решении обеспечивает достаточную степень обобщенности, позволяя тем самым, не затрагивая структуру основного кода приложения, оперативно подключать к системе необходимые источники информации, а также вносить в систему информацию о противоречиях различного генеза и учитывать их при принятии решения о ведении конкретного пациента.
Интерфейс взаимодействия с врачом
Как подчеркивалось выше, разрабатываемая система предназначается не для замены врача, а для поддержки принятия им персонализиро-
I
в о
"О
S >
С
s
0
1 I
о
£ m
5
Е s
m n S n H
«lnterface>> IMedical Factory
HgetVisitor() : IVisitor
HgetContradictionProvider() : IContradictionProvider
DiseaseFactory
HgetVisitor() : IVisitor
HgetContradictionProvider() : IContradictionProvider
««instantiate»^ ^
Drug Factory
HgetVisitor() : IVisitor
HgetContradictionProvider() : IContradictionProvider
^ <<instantiate>>
/
AnamnesisFactory
HgetVisitor() : IVisitor
HgetContradictionProvider() : IContradictionProvider
/
Statel
+accept(visitor : IVisitor) : BaseState[]
State2
+accept(visitor : IVisitor) : BaseState[]
A
\
\ \
^ ««instantiate» / ----/
\ ' ««instantiate»
\----->
\ \
\ \ ««instantiate»
\
\
\ ««instantiate»
DiseaseVisitor
+visit(state +visit(state +visit(state Statel) : BaseStateQ State2) : BaseStateQ StateN) : BaseStateQ
DrugVisitor
+visit(state +visit(state +visit(state Statel) : BaseStateQ State2) : BaseStateQ StateN) : BaseStateQ
AnamnesisVisitor
+visit(state +visit(state +visit(state Statel) : BaseStateQ State2) : BaseStateQ StateN) : BaseStateQ
->I
-> ->
««lnterface>> IVisitor
+visit(state +visit(state +visit(state Statel) : BaseStateQ State2) : BaseStateQ StateN) : BaseStateQ
DiseaseContradictionProvider
-getContradictions(params) : Contradiction!]
>
>
----->
DrugContradictionProvider
-getContradictions(params) : Contradiction!]
AnamnesisContradictionProvider
-getContradictions(params) : Contradiction!]
StateN
+accept(visitor : IVisitor) : BaseState[]
H>
V
г "
V
««instantiate>>
BaseState
-nextStates : BaseState[]
->
««Interface» IVisitable
-accept(visitor : IVisitor) : BaseState[]
DataDispatcher
~[> \>
AutomataDispatcher
-currentFactory : IMedicalFactory -patientData : DataDispatcher
getAIIStatesO : BaseStateQ getAllowedStatesO : BaseStateQ getRecommendedStates() : BaseStateQ getContradictions(params) : Contradiction!] setFactory(factory : IMedicalFactory) setState(state : BaseState)
ExtemalDataStorage
7Y
««Interface» IContradictionProvider
-getContradictions(params) : Contradiction!]
EHRStorageAdapter
OntologicalStorageAdapter
Contradiction
Рис. 3. Структура классов для описания противоречий на основе паттерна Abstract Factory Fig. 3. Class structure for contradictions description based on the Abstract Factory pattern
< □
ГО
>
m I
s m го
m >
I m
го s
о g
ванных клинических решений. В соответствии с этой целью система предоставляет врачу следующую интерфейсную информацию:
— о текущем состоянии клинического процесса (в соответствии с номером состояния НЯ);
— о необходимости принятия очередного клинического решения (в соответствии с таймером или счетчиком возвратов, предусмотренным в каждом состоянии НЯ);
— о доступных переходах (в соответствии с методом getAvailableStates());
— о рекомендуемых переходах (в соответствии с методом getRecommendedStates());
— о возможных противопоказаниях или других противоречиях при выбираемом врачом переходе (в соответствии с методом getContradictions()).
Проиллюстрируем реализацию предложенного решения на типичном примере из клинической практики.
Пусть клинические симптомы пациента соответствуют НС4. В соответствии с автоматной моделью врачу сообщается информация, что пациент находится в состоянии НЯ4 и к нему необходимо применить клинические мероприятия НА4.1. Однако в комплекс мероприятий НА4.1 входят два препарата на выбор — беротек и вентолин. Пусть врач считает, что главным фактором для указанного выбора является анамнез пациента. В этом случае вызывается метод setFactory() и в него передается экземпляр AnamnesisFactory. Далее вызывается метод getAllowedStates(), и фабрика выпускает экземпляр AnamnesisVisitor (рис. 4). Для текущего состояния автомата запускается метод accept(), в который передается экземпляр AnamnesisVisitor. Соответствующий метод из AnamnesisVisitor проверяет наличие доступных переходов и возвращает список тех состояний, которые удовлетворяют предикатам, записанным на переходах. Например, если удовлетворяется только предикат НС3, то рекомендуется перейти в состояние НЯ3. При этом врачу демонстрируется список доступных состояний, а также рекомендуемое для перехода состояние.
Для получения информации о противопоказаниях производится вызов метода getContra-dictions(), в который передается экземпляр объекта DataDispacher (см. рис. 4), и система производит оценку взаимодействий беротека и вентолина с компонентами анамнеза пациента. Обращаясь к EHR пациента через EHRStorageAdapter (см.
1. Брифинг Министра Вероники Скворцовой. 13 декабря 2017. https://www.rosminzdrav.ru/news/2017/12/ 13/6603-brifing-ministra-veroniki-skvortsovoy-po-zavershenii-zasedaniya-prezidiuma-soveta-pri-
рис. 4), система находит у пациента в анамнезе гипертрофическую обструктивную кардиомио-патию и ищет информацию о противопоказаниях к применению беротека и вентолина у пациентов с данным заболеванием. Система может либо найти ее в своей базе данных, либо обратиться к классу DataDispatcher, который, в свою очередь, осуществляет поиск нужной информации в своем кэше или делает запрос к источнику онтологии. Последний через OntologyStorageAdapter реализует паттерн Adapter для представления запрашиваемой информации в требуемом формате. В результате система находит информацию о противопоказаниях к применению беротека у пациентов с данным заболеванием и не находит таковую по отношению к вентолину. Система сообщает данную информацию врачу и рекомендует использовать вентолин.
Заключение
В статье предложено решение для персонализированной поддержки клинических процессов, построенное на основе концепции автоматного программирования с использованием шаблонов проектирования. Решение удовлетворяет требованиям, предъявляемым к СПКР, а именно:
— терминология соответствует спецификациям и стандартам, принятым в медицинской практике, что обеспечивает ее прозрачность и простоту использования для медицинских работников;
— поддерживается работа врача в соответствии с базовым клиническим процессом, определяемым последовательностью состояний автоматной модели; в то же время врач имеет возможность при необходимости и (или) при наличии соответствующей информации производить пер-сонализацию клинического процесса, учитывая данные анамнеза конкретного больного и сведения о возможных противоречиях в назначениях;
— применение паттернов проектирования обеспечивает гибкость и расширяемость спецификаций медицинского процесса;
— гибко и независимо подключаются внешние источники данных, в том числе онтологические системы, с возможностью их активации и деактивации во время работы.
Результаты работы частично докладывались на международной конференции [29].
prezidente-rossiyskoy-federatsii-po-strategicheskomu-razvitiyu-i-prioritetnym-proektam-pod-predseda-telstvom-dmitriya-medvedeva (дата обращения: 31.05.2019).
2. OpenEHR Architecture Overview, openEHR 2007. Eds. S. Heard & T. Beale. https://specifications.
openehr.org/releases/1.0.2/architecture/overview. pdf (дата обращения: 31.05.2019).
3. HL7 standard description. http://www.mcis.duke. edu/standarts/HL7/hl7.htm (дата обращения: 31.05.2019).
4. Поликарпова Н. И., Шалыто А. А. Автоматное программирование. СПб., Питер, 2009. 176 с.
5. Ваганова Е. В. Медицинские информационные системы как объект оценки: факторы и тенденции развития. Вестник Томского государственного университета. Экономика, 2017, № 37, с. 113-130.
6. ISO 13940-2016 Health informatics — system of concepts to support continuity of care (ISO 13940:2015). https://www.iso.org/standard/58102.html (дата обращения: 31.05.2019).
7. Tsung-Hsien Yu, Pin-Kuei Fu, and Yu-Chi Tung. Using medication utilization information to develop an asthma severity classification model. BMC Medical Informatics and Decision Making, Dec. 2017, vol. 17, p. 177. https://doi.org/10.1186/s12911-017-0571-9
8. Назаренко Г. И., Осипов Г. С. Основы теории медицинских технологических процессов. Ч. 1. М., Физ-матлит, 2005. 144 с.
9. Гусев А. Обзор российских систем поддержки принятия врачебных решений. 30 Сент. 2018. http:// www.kmis.ru/blog/obzor-rossiiskikh-sistem-podderzhki-priniatiia-vrachebnykh-reshenii (дата обращения: 31.05.2019).
10. Neumuth T. Surgical Process Modeling — Theory, Methods, and Applications. The Universität Leipzig,
2012. 279 р.
11. Hommersom A., Verwer S., Lucas P. J. F. Discovering Probabilistic Structures of Healthcare Processes. Process Support and Knowledge Representation in Health Care. ProHealth, 2013, AIME 2013 Joint Workshop, KR4HC 2013/ProHealth 2013, Murcia, Spain, June 1,
2013, Revised Selected Papers, рр. 53-67.
12. Ferrante S., Bonacina S., Pozzi G., Pinciroli F., Mar-ceglia S. A design methodology for medical processes. Appl Clin Inform., 2016, vol. 7, pp. 191-210. http:// dx.doi.org/10.4338/ACI-2015-08-RA-0111
13. Zhaoyi Chen, Victoria Y. Bird, Rupam Ruchi, Mark S. Segal, Jiang Bian, Saeed R. Khan, Marie-Carmel-le Elie, and Mattia Prosperi. Development of a personalized diagnostic model for kidney stone disease tailored to acute care by integrating large clinical, demographics and laboratory data: the diagnostic acute care algorithm — kidney stones (DACA-KS). BMC Medical Informatics and Decision Making, 2018, vol. 18, no. 72. https://doi.org/10.1186/s12911-018-0652-4
14. Boussadi A., Zapletal E. A Fast Healthcare Interoperability Resources (FHIR) layer implemented over i2b2. BMC Medical Informatics and Decision Making, 2017, vol. 17, no. 120. https://doi.org/10.1186/ s12911-017-0513-6
15. Monica K. Top Clinical Decision Support System (CDSS) companies by ambulatory, inpatient settings. April 07, 2017. https://ehrintelligence.com/news/
top-clinical-decision-support-system-cdss-compa-nies-by-ambulatory-inpatient (дата обращения: 31.05.2019).
16. Olah P., et al. Exploring hierarchical medical data stored as multi-trees in a relational database. Proceedings of International Conference on Advancements of Medicine and Health Care through Technology, October 12-15, 2016, Cluj-Napoca, Romania, IFMBE, vol. 59, S. Vlad, N. Roman (eds), Cham, Springer, 2016, pp. 219-222.
17. Лебедев С. В., Жукова Н. А. Слияние медицинских данных на основе онтологий. Онтология проектирования, 2017, т. 7, № 2(24), с. 145-159. doi:10. 18287/2223-9537-2017-7-2-145-159
18. Kaiser K., Marcos M. Leveraging workflow control patterns in the domain of clinical practice guidelines. BMC Medical Informatics and Decision Making,
2016, vol. 16, no. 20. https://doi.org/10.1186/s12911-
016-0253-z
19. Ong T. C., et al. Dynamic-ETL: a hybrid approach for health data extraction, transformation and loading. BMC Medical Informatics and Decision Making,
2017, vol. 17, no. 134. https://doi.org/10.1186/s12911-
017-0532-3
20. Sylvestre Е., et al. Combining information from a clinical data warehouse and a pharmaceutical database to generate a framework to detect comorbidities in electronic health records. BMC Medical Informatics and Decision Making, 2018, vol. 18, no. 9. https:// doi.org/10.1186/s12911-018-0586-x
21. Новиков Ф. А., Афанасьева И. В. Кооперативное взаимодействие автоматных объектов. Информационно-управляющие системы, 2016, № 6, с. 50-64. https://doi.org/10.15217/issn1684-8853.2016.6.50
22. Prieto-Langarica A., et al. A cellular automata model of infection control on medical implants. Appl Appl Math., Jun. 1, 2011, vol. 6, no. 1, pp. 1-10.
23. Misra S., Tiwari V., Obaidat M. S. LACAS: Learning automata-based congestion avoidance scheme for healthcare wireless sensor networks. IEEE Journal on Selected Areas in Communications, May 2009, vol. 27, no. 4, рр. 466-479.
24. Rahmaniheris M., Yu Jiang, Lui Sha. Model-driven design of clinical guidance systems. arXiv:1610.06895v1 [cs.CY], Oct. 21, 2016. https://arxiv.org/pdf/1610.06895. pdf (дата обращения: 31.05.2019).
25. Bowles J. K. F., Silvina A. Model Checking Cancer Automata. https://core.ac.uk/download/pdf/31299773. pdf (дата обращения: 31.05.2019).
26. Митькин С. Б. Автоматное программирование на языке ДРАКОН. Программная инженерия, 2019, т. 10, № 1, с. 3-13.
27. Gamma E., Helm R., Johnson R., Vlissides J. M. Design Patterns: Elements of Reusable Object-Oriented Software. 1st ed. Addison-Wesley Professional, 1994. 417 р.
28. Тепляков С. Погружение в паттерны проектирования. https://refactoring.guru/ru/design-patterns/ book (дата обращения: 31.05.2019).
29. Vatian A., Dudorov S., Chikshova E., Lobantsev A., Parfenov V., Gusarova N., Shalyto A. Design patterns for personalization of healthcare process. 2nd
International Conference on Software and Services Engineering, Prague, Czech Republic, March 15-17, 2019, pp. 83-88.
UDC 004.895
doi:10.31799/1684-8853-2019-5-64-75
Automata approach for personalized support of clinical processes in healthcare
I. V. Aksenova, Student, orcid.org/0000-0002-1835-2237
N. V. Dobrenkoa, Senior Lecturer, orcid.org/0000-0001-6206-8033
A. S. Vatyana, Assistant Professor, orcid.org/0000-0002-5483-716X
R. O. Kapustina, Student, orcid.org/0000-0003-3027-2704
S. V. Osipova, Student, orcid.org/0000-0002-5761-4703
P. Y. Mavrina, Student, orcid.org/0000-0001-8530-0077
N. F. Gusarovaa, PhD, Tech., Associate Professor, orcid.org/0000-0002-1361-6037 A. A. Shalytoa, Dr. Sc., Tech., Professor, orcid.org/0000-0002-2723-2077, shalyto@mail.ifmo.ru aSaint-Petersburg National Research University of Information Technologies, Mechanics and Optics, 49, Kronverkskii Pr., 197101, Saint-Petersburg, Russian Federation
Introduction: Within the framework of the National Healthcare Project, personalization of a physician's activity is very important, forming a demand for a Clinical Decision Support System. The available systems miss the functions of prompting a doctor during the clinical process or identifying possible contradictions between different types of medical treatment offered to the patient. Purpose: Development of a solution, free from the above-mentioned problems, for personalized support of the clinical process. Methods: Automata (state machine) approach presenting the clinical process as a set of automata states and possible transitions between them, and a set of design patterns, namely: Abstract Factory, Facade, Adapter and Visitor. Results: A solution for personalized support of clinical processes is proposed, based on the automata approach and design patterns. The automata approach allows you to divide the clinical process into separate stages and automatically control the possible transitions and conditions for their implementation, including checking for contraindications. The use of design patterns provides a sufficient degree of generalization, allowing you, without affecting the structure of the main application code, to promptly connect the system to the necessary sources of information, and to enter the data about contradictions of various origins, taking them into account when making decisions on the treatment of a particular patient. Practical relevance: The developed solution, as compared to the available systems, is more efficient at prompting the doctor during a clinical process, and at identifying possible contradictions between the various types of medical treatment offered to the patient.
Keywords — automata programming, state machine, clinical protocols, decision support, medical processes.
For citation: Aksenov I. V., Dobrenko N. V., Vatyan A. S., Kapustin R. O., Osipov S. V., Mavrin P. Y., Gusarova N. F., Shalyto A. A. Automata approach for personalized support of clinical processes in healthcare. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2019, no. 5, pp. 64-75 (In Russian). doi:10.31799/1684-8853-2019-5-64-75
References
1. Brifing Ministra Veroniki Skvorczovoj. 13 dekabrya 2017 [Briefing by Minister Veronika Skvortsova. December 13, 2017]. Available at: https://www.rosminzdrav.ru/news/2017/ 12/13/6603-brifing-ministra-veroniki-skvortsovoy-po-zaver-shenii-zasedaniya-prezidiuma-soveta-pri-prezidente-rossiys-koy-federatsii-po-strategicheskomu-razvitiyu-i-prioritet-nym-proektam-pod-predsedatelstvom-dmitriya-medvedeva (accessed 31 May 2019).
2. OpenEHR Architecture Overview, openEHR 2007. Eds. S. Heard & T. Beale. Available at: https://specifications. openehr.org/releases/1.0.2/architecture/overview.pdf (accessed 31 May 2019).
3. HL7 standard description. Available at: http://www.mcis. duke.edu/standarts/HL7/hl7.htm (accessed 31 May 2019).
4. Polikarpova N. I., Shalyto A. A. Avtomatnoe program-mirovanie [Automatic programming]. Saint-Petersburg, Piter Publ., 2009. 176 p. (In Russian).
5. Vaganova E. V. Hospital information systems as the object of evaluation: factors and development tendencies. Vestnik Tomskogo gosudarstvennogo universiteta. E^konomika, 2017, no. 37, pp. 113-130 (In Russian).
6. ISO 13940-2016 Health informatics — system of concepts to support continuity of care (ISO 13940:2015). Available at: https://www.iso.org/standard/58102.html (accessed 31 May 2019).
7. Tsung-Hsien Yu, Pin-Kuei Fu, and Yu-Chi Tung. Using medication utilization information to develop an asthma severity classification model. BMC Medical Informatics and
Decision Making, Dec. 2017, vol. 17, p. 177. https://doi. org/10. 1186/s12911-017-0571-9
8. Nazarenko G. I., Osipov G. S. Osnovy teorii medicinskix tex-nologicheskix processov [Fundamentals of the theory of medical technological processes]. Part 1. Moscow, Fizmatlit Publ., 2005. 144 p. (In Russian).
9. Gusev A. Obzor rossijskix sistem podderzhki prinyatiya vrachebnyx reshenij [Overview of russian medical decision support systems]. Sent. 30, 2018. Available at: http://www. kmis.ru/blog/obzor-rossiiskikh-sistem-podderzhki-prini-atiia-vrachebnykh-reshenii (accessed 31 May 2019).
10. Neumuth T. Surgical Process Modeling — Theory, Methods, and Applications. The Universität Leipzig, 2012. 279 p.
11. Hommersom A., Verwer S., Lucas P. J. F. Discovering probabilistic structures of healthcare processes. Process Support and Knowledge Representation in Health Care. Pro-Health 2013, AIME 2013 Joint Workshop, KR4HC 2013/ ProHealth 2013, Murcia, Spain, June 1, 2013, Revised Selected Papers, pp. 53-67.
12. Ferrante S., Bonacina S., Pozzi G., Pinciroli F., Marceglia S. A design methodology for medical processes. Appl Clin Inform., 2016, vol. 7, pp. 191-210. http://dx.doi.org/10.4338/ ACI-2015-08-RA-0111
13. Zhaoyi Chen, Victoria Y. Bird, Rupam Ruchi, Mark S. Segal, Jiang Bian, Saeed R. Khan, Marie-Carmelle Elie, and Mattia Prosperi. Development of a personalized diagnostic model for kidney stone disease tailored to acute care by integrating large clinical, demographics and laboratory data: the diag-
nostic acute care algorithm — kidney stones (DACA-KS). BMC Medical Informatics and Decision Making, 2018, vol. 18, no. 72. https://doi.org/10.1186/s12911-018-0652-4
14. Boussadi A., Zapletal E. A Fast Healthcare Interoperability Resources (FHIR) layer implemented over i2b2. BMC Medical Informatics and Decision Making, 2017, vol. 17, no. 120. https://doi.org/10.1186/s12911-017-0513-6
15. Monica K. Top Clinical Decision Support System (CDSS) companies by ambulatory, inpatient settings. April 07, 2017. Available at: https://ehrintelligence.com/news/top-clini-cal-decision-support-system-cdss-companies-by-ambulato-ry-inpatient (accessed 31 May 2019).
16. Olah P., et al. Exploring hierarchical medical data stored as multi-trees in a relational database. Proceedings of International Conference on Advancements of Medicine and Health Care through Technology, October 12-15, 2016, Cluj-Na-poca, Romania, IFMBE, vol. 59, S. Vlad, N. Roman (eds), Cham, Springer, 2016, pp. 219-222.
17. Lebedev S. V., Zhukova N. A. Ontology-driven approach to medical data fusion. Ontology of Designing, 2017, vol. 7, no. 2, pp. 145-159 (In Russian). doi:10.18287/2223-9537-2017-7-2-145-159
18. Kaiser K., Marcos M. Leveraging workflow control patterns in the domain of clinical practice guidelines. BMC Medical Informatics and Decision Making, 2016, vol. 16, no. 20. https://doi.org/10.1186/s12911-016-0253-z
19. Ong T. C., et al. Dynamic-ETL: a hybrid approach for health data extraction, transformation and loading. BMC Medical Informatics and Decision Making, 2017, vol. 17, no. 134. https://doi.org/10.1186/s12911-017-0532-3
20. Sylvestre E., et al. Combining information from a clinical data warehouse and a pharmaceutical database to generate a framework to detect comorbidities in electronic health records. BMC Medical Informatics and Decision Making, 2018, vol. 18, no. 9. https://doi.org/10.1186/s12911-018-0586-x
21. Novikov F. A., Afanasieva I. V. Cooperative interaction of automata objects. Informatsionno-upravliaiushchie sistemy [Information and Control Systems], 2016, no. 6, pp. 50-64 (In Russian). https://doi.org/10.15217/issn1684-8853.2016.6.50
22. Prieto-Langarica A., et al. A cellular automata model of infection control on medical implants. Appl Appl Math., Jun. 1, 2011, vol. 6, no. 1, pp. 1-10.
23. Misra S., Tiwari V., Obaidat M. S. LACAS: Learning automata-based congestion avoidance scheme for healthcare wireless sensor networks. IEEE Journal on Selected Areas in Communications, May 2009, vol. 27, no. 4, pp. 466-479.
24. Rahmaniheris M., Yu Jiang, Lui Sha. Model-driven design of clinical guidance systems. arXiv:1610.06895v1 [cs.CY], 21 Oct. 2016. Available at: https://arxiv.org/pdf/1610. 06895.pdf (accessed 31 May 2019).
25. Bowles J. K. F., Silvina A. Model Checking Cancer Automata. Available at: https://core.ac.uk/download/pdf/ 31299773.pdf (accessed 31 May 2019).
26. Mitkin S. Automata-based programming in DRAKON language. Programmnaya Ingeneria, 2019, vol. 10, no. 1, pp. 3-13 (In Russian). doi:10.17587/prin.10.3-13
27. Gamma E., Helm R., Johnson R., Vlissides J. M. Design Patterns: Elements of Reusable Object-Oriented Software. 1st ed. Addison-Wesley Professional, 1994. 417 p.
28. Teplyakov S. Pogruzhenie v patterny proektirovaniya [Immersion in design patterns]. Available at: https://refactor-ing.guru/ru/design-patterns/book (accessed 31 May 2019).
29. Vatian A., Dudorov S., Chikshova E., Lobantsev A., Parfenov V., Gusarova N., Shalyto A. Design patterns for personalization of healthcare process. 2nd International Conference on Software and Services Engineering, Prague, Czech Republic, March 15-17, 2019, pp. 83-88.
Научный журнал «ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ» выходит каждые два месяца.
Стоимость годовой подписки (6 номеров) для подписчиков России — 6000 рублей,
для подписчиков стран СНГ — 6600 рублей, включая НДС 20%, таможенные и почтовые расходы.
Подписку на печатную версию журнала можно оформить в любом отделении связи по каталогу:
«Пресса России»: № 15385 — полугодовой индекс,
а также через посредство подписных агентств:
«Северо-Западное агентство „Прессинформ"»
Санкт-Петербург, тел.: (812) 335-97-51, 337-23-05,
эл. почта: press@crp.spb.ru, zajavka@crp.spb.ru,
сайт: http://www.pinform.spb.ru
«МК-Периодика» (РФ + 90 стран)
Москва, тел.: (495) 681-91-37, 681-87-47,
эл. почта: export@periodicals.ru, сайт: http://www.periodicals.ru «Деловая пресса»
Москва, тел.: (495) 962-11-11, эл. почта: podpiska@delpress.ru, сайт: http://delpress.ru/contacts.html «Коммерсант-Курьер»
Казань, тел.: (843) 291-09-99, 291-09-47, эл. почта: kazan@komcur.ru,
сайт: http://www.komcur.ru/contacts/kazan/
«Урал-Пресс» (филиалы в 40 городах РФ)
Сайт: http://www.ural-press.ru
«Идея» (Украина)
Сайт: http://idea.com.ua
«ВТЪ» (Узбекистан)
Сайт: http://btl.sk.uz/ru/cat17.html и др.
На электронную версию нашего журнала (все выпуски, годовая подписка, один выпуск, одна статья) вы можете подписаться на сайтах НЭБ: http://elibrary.ru; РУКОНТ: http://www.rucont.ru; ИВИС: http://www.ivis.ru; Некс-Медиа: http://biblioclub.ru/index.php?page=news&id=11l96
Полнотекстовые версии журнала за 2002-2017 гг. в свободном доступе на сайте журнала (http://www.i-us.ru), НЭБ (http://www.elibrary.ru)
и Киберленинки (http://cyberleninka.ru/journal/n/informatsionno-upravlyayuschiesistemy).
