Это третья часть работы, она посвящена описанию онтологии ИИ-продуктов в области медицинской техники. Первая часть предлагает введение в проблему управления сложностью. Вторая часть работы посвящена теме управления сложностью при разработке продуктов как основного двигателя бизнеса. Четвертая часть работы посвящена описанию онтологии контрагентов — участников рынка медицинских ИИ-продуктов. Пятая часть работы посвящена описанию онтологии потребителей — участников рынка медицинских ИИ-продуктов.
Краткий обзор
Онтология ИИ-продуктов в контексте медицинских изделий представляет собой структурированную модель, фиксирующую взаимосвязи между участниками рынка, потребителями, продуктами, архитектуру и характеристики технической реализации продуктов. Она основана на стандарте ISO/IEC/IEEE 42010, который определяет архитектуру как «фундаментальную организацию системы, воплощенную в ее компонентах, их взаимосвязях и принципах проектирующего искусства». Ключевой вывод: правильная декомпозиция системы по границам предметных областей (компетенций) снижает сложность и предотвращает взрывной рост зависимостей. Для медицинской техники критически важны регуляторные требования (FDA, MDR, Росздравнадзор, Минздрав, ФСТЭК), что делает управление границами между разработкой, сертификацией и эксплуатацией обязательным элементом онтологии. Онтология, построенная по принципам ArchiMate и соответствующая ISO 42010, обеспечивает предсказуемость разработки и упрощает интеграцию с существующими ИТ-системами в области охраны здоровья и персональной медицинской помощи.
«Без четкой онтологии медицинские стартапы тратят до 60% ресурсов на исправление ошибок проектирования, которые можно было предотвратить на этапе моделирования», д.м.н. Мария Соколова из Charité Berlin.
Что такое онтология?
В философии онтология — это раздел метафизики, изучающий природу бытия, то есть как устроена реальность и из чего она состоит. Однако в компьютерных науках, особенно в контексте Semantic Web, где онтология является центральным понятием — это формализованное представление знаний о предметной области.
По определению Semantic Web, онтология — это формальная, явно выраженная спецификация общей концептуальной модели, определяющая понятия (классы), их свойства (атрибуты), отношения между ними и аксиомы, регулирующие эти понятия.
В Semantic Web онтология включает:
- Классы (классификации), например, «Человек», «Лекарство», «Болезнь».
- Свойства (атрибуты и отношения), например, «имеетВозраст», «являетсяПодклассом», «расположенВ».
- Экземпляры (реальные сущности), конкретные объекты, например, «Иван», «Москва».
- Ограничения и правила, например, «человек не может быть моложе 0 лет», «если X — подкласс Y, то все X — это Y».
- Иерархии наследования, например, «Врач ⊑ Человек».
В Semantic Web онтологии строятся с использованием стандартов W3C, таких как RDF (Resource Description Framework), RDFS (RDF Schema) и OWL (Web Ontology Language).
Почему онтологии так важны?
Современные ИИ-системы требуют сети машинно-понимаемых данных, а не просто документов для людей. Почему это так? Рассмотрим основные причины. Во-первых, автоматизация принятия решений требует от ИИ-системы делать выводы, а не просто извлекать текст из документов. Для этого нужно внутреннее представление структуры и семантики текста, а не только слов, собранных в предложения, абзацы и разделы. Во-вторых, ИИ-система должна обеспечить правильную интеграцию данных из разных источников. Без единой семантики машина не поймёт, что «patientID» в одной системе — это то же самое, что «идентификатор пациента» в другой. В-третьих, ИИ-система должна уметь делать прозрачный логический вывод (рассуждать), что требует трассировку рассуждения от начала до конца. Это возможно только на основе формализованного знания. В-четвертых, ИИ-системы должны обеспечивать межязыковую и межсистемную совместимость. То есть машина должна понимать, что «heart attack» (англ.) = «инфаркт миокарда» (рус.) = MyocardialInfarction (в онтологии). В-пятых, для обучения ИИ нужны качественные данные, что подразумевает, что сведения в документах должны быть согласованы (не противоречивы) и не содержать логических и/или фактических ошибок. В противном случае, ИИ будет наследовать ошибки, содержащиеся в документах, на которых он обучался.
В итоге, почему онтологии важны в современных ИИ-системах? Потому что ИИ должен не просто читать, а понимать, рассуждать, интегрировать и принимать решения. Документы для людей не содержат структуры и семантики, необходимых для автоматического принятия решений. Как онтологии обеспечивают это технически? Формализуют знания на языках вроде RDF, RDFS, OWL. Используют URI для однозначной идентификации терминов. Вводят иерархии, аксиомы и ограничения. Позволяют автоматические логические выводы с помощью программ-ризонеров. Обеспечивают семантическую совместимость между разными системами терминологий.
Предпосылки к разработке онтологии продукта
- Регуляторное доминирование — в медицинской технике процессы разработки и эксплуатации жестко регулируются (FDA 21 CFR Part 820, EU MDR, Росздравнадзор, Минздрав, ФСТЭК), что делает compliance неотъемлемой частью онтологии. Неверная декомпозиция систем ведет к нарушению требований и увеличению стоимости изменений. При этом 80% времени жизненного цикла при разработке медицинского изделия тратится на соответствие требованиям регуляторов.
- Жизненный цикл как основа — медицинские изделия имеют длительный жизненный цикл (10–15 лет), поэтому онтология должна учитывать этапы от разработки до утилизации, включая пост-маркетинговый мониторинг.
- Междисциплинарность — разработка требует интеграции знаний врачей, инженеров и регуляторных экспертов. Онтология преодолевает разрыв между предметной областью и техническими командами через четкое картирование компетенций.
- Иерархия рисков — классификация медицинских изделий (I–III классы риска) определяет границы сервисов: для ИИ-диагностики (III класс) требуется отдельный сервис валидации, изолированный от менее критичных компонентов.
- Интеграционная сложность — современные МИ втраиваются в экосистему медицинской организации и для этого взаимодействуют с 5-тью и более ИТ-системами (EMR, PACS, LIMS и тд).
- Рост количества ИИ-компонентов — 60% новых медицинских изделий содержат алгоритмы машинного обучения.
- Оказание услуг в приоритете — переход от продажи устройств к предоставлению медицинских услуг на основе продуктов.
- Персонализация — сегментация пациентов по 200+ нозологическим группам и медицинским целям.
Онтология продукта
Онтология продукта описывает комплексную сервисную архитектуру медицинского ИИ-продукта, охватывая стратегические, бизнес-ориентированные, технические и рыночные аспекты. Онтология демонстрирует, как компоненты взаимодействуют для создания ценности в регулируемой медицинской среде. Онтология продукта использует онтологию контрагентов и потребителей. Ниже предлагаем вашему вниманию сокращенное описание онтологии продукта.
Слой «Стратегические мотивы и целеполагание» (Strategy + Motivation)
Этот слой описывает вектор развития продукта, увязывая экспертные возможности компании с рыночными потребностями.
Узлы:
- Компетенция: конкретная экспертиза, необходимая для существования продукта
- Сегмент Потребителей: целевые группы потребителей
- Стратегическая Цель: долгосрочные бизнес-ориентиры компании, достигаемые при помощи продукта за счет обслуживания нужд Сегментов Потребителей.
Связи:
- Компетенция определяет Стратегические Цели.
- Стратегические Цели влияют на выбор Сегмента Потребителей.
- Компетенция обслуживает конкретные Сегменты Потребителей.
Слой «Реализация стратегии» (Business)
Этот слой обеспечивает описание стратегии через услуги и обеспечивающие их оказание бизнес-процессы.
Узлы:
- Медицинское Изделие: регистрируемый в государственной системе учета медицинский ИИ-продукт
- Услуга: клинико-технологические сервисы
- Бизнес-процесс: операционные потоки работ
- Канал Привлечения: способы взаимодействия с покупателями (потребителями)
- Канал Обслуживания: способы обеспечения сервисного обслуживания
Связи:
- Медицинское Изделие содержит Услуги, которые реализуются через Бизнес-процессы.
- Каналы Привлечения (Дистрибьютор и Телемедицинская Платформа) и Обслуживания (Сервисная Организация) интегрированы напрямую с Медицинским Изделием.
- Стратегические Цели достигаются через посредством Услуг.
Слой «Прикладные сервисы» (Application)
Этот слой обеспечивает описание услуг посредством прикладных сервисов (функций) продукта.
Узлы:
- Прикладной Сервис: программное обеспечение для решения конкретных медицинских или организационных задач.
Связи:
- Прикладные Сервисы напрямую поддерживают Услуги, обеспечивая функционал для клинического применения. Здесь реализуются ИИ-алгоритмы диагностики, анализа данных и поддержки решений.
Слой «Технологические сервисы» (Technology)
Этот слой обеспечивает описание технологической инфраструктуры продукта.
Узлы:
- Технологический Сервис: API, вычислительные ресурсы, иные объекты инфраструктуры.
Связи:
- Технологические Сервисы обеспечивают техническую основу для Прикладных Сервисов (например, облачные вычисления для ИИ-инференса).
- Технологические Сервисы связаны с Производителем как поставщиком инфраструктуры.
Слой «Характеристики продукта» (Key Product Characteristics)
Этот слой обеспечивает описание основных характеристик продукта.
Узлы (категории характеристик):
- Регуляторные: характеристики, обеспечивающие соответствие нормам регуляторов (Росздравнадзор/ФСТЭК/FDA).
- Клинические: характеристики, обеспечивающие клиническую эффективность (достижимость медицинских целей), и безопасность пациента.
- Технические: характеристики, обеспечивающие надежность и интероперабельность продукта.
- Жизненный Цикл: характеристики, обеспечивающие версионируемость и обновления продукта.
- ИИ-специфичные: характеристики, обеспечивающие необходимый уровень качества данных и соблюдение алгоритмами медицинской этики.
- Бизнес: характеристики, обеспечивающие необходимый уровень ROI и рыночную устойчивость.
Связи:
- Регуляторные характеристики привязаны к Медицинскому Изделию
- Технические характеристики привязаны к Прикладным Сервисам
- Клинические характеристики привязаны к Услугам.
Слой «Контрагенты» (Market Participants)
Этот слой обеспечивает описание основных акторов медицинской экосистемы как рынка медицинских изделий.
Узлы:
- Регулятор: утверждает соответствие медицинского изделия требованиям государственной регуляции.
- Производитель: создает технологические сервисы и их компоненты.
- Дистрибьюторские Организации: обеспечивают логистику и техническую поддержку продуктов.
- Сервисные Организации: обеспечивают техническое обслуживание продуктов.
- Закупочные Организации: оптовые покупатели продуктов.
- Медицинские Организации: розничные покупатели продуктов.
- Телемед Платформы: обеспечивают цифровые каналы сбыта продуктов.
Связи:
- Регулятор контролирует доступность Медицинского Изделия на рынке
- Производитель поставляет Технологические Сервисы
- Дистрибьюторские Организации обеспечивают логистику и техническую поддержку Медицинских Изделий
- Сервисные Организации выступают Каналами Обслуживания Медицинских Изделий
- Закупочные Организации выступают Каналами Привлечения Медицинских Изделий
- Медицинские Организации выступают Каналами Привлечения Медицинских Изделий
- Телемед Платформы выступают Каналами Привлечения и Обслуживания Медицинских Изделий.
Слой «Потребители» (Market Participants)
Этот слой обеспечивает описание источников спроса — потребителей услуг на рынке медицинских изделий.
Узлы:
- Пациент: конечный потребитель услуг.
- Нозологическая Группа: классификация пациентов по группе заболеваний. Принадлежность пациента к нозологической группе определяет характер потребляемых услуг.
Связи:
- Пациенты объединяются в Сегменты Потребителей
- Пациенты потребляют Услуги (диагностика, мониторинг)
- Пациенты обслуживаются в Медицинских Организациях.
Пример онтологии продукта
Экземпляр онтологии продукта сделан на основе примера — гипотетического ИИ-продукта «AI-Diagnostic Hub», платформы для анализа КТ-снимков с использованием ИИ.
| Слой ArchiMate | Элемент онтологии | Описание | Значения элемента онтологии | Кросс-зависимости |
|---|---|---|---|---|
| Strategy + Motivation | Компетенция | Ключевые способности организации в предметной области |
|
|
| Сегмент потребителей | Целевые группы пациентов и медицинских учреждений |
|
|
|
| Стратегические цели | Список стратегических целей в терминах S-V-O |
|
|
|
| Business | Медицинское изделие | Программно-аппаратный комплекс как целевой продукт | AI-Diagnostic Hub (платформа для анализа КТ-снимков с использованием ИИ) |
|
| Услуга | Функциональные возможности продукта для конечного пользователя |
|
|
|
| Бизнес-процесс | Последовательность действий для предоставления услуги |
|
|
|
| Канал привлечения | Способы продвижения и продажи продукта |
|
|
|
| Канал обслуживания | Способы поддержки и эксплуатации продукта |
|
|
|
| Application | Прикладной сервис | Программные компоненты, реализующие бизнес-логику |
|
|
| Technology | Технологический сервис | Инфраструктурные компоненты и стандарты |
|
|
| Межслоевые зависимости | Кросс-зависимости | Связи между элементами разных слоев |
|
|
Как читать онтологию продукта?
Ключевая ценность предлагаемой онтологии – в прямой демонстрации сквозной трансляции «от стратегических целей» через «технологические решения» к «конкретной клинической пользе» для пациентов при соблюдении регуляторных рамок. Учет ИИ-специфичных характеристик (качество данных, этика) и жизненного цикла продукта делает онтологию адаптивной для динамичного рынка медицинских инноваций.
Приведем пояснения к онтологии.
Стратегические мотивы и целеполагание
Этот слой — фундамент регуляторного соответствия. Центральный элемент — класс Компетенция, который напрямую связан с Сегментом Потребителей. Например, компетенция «Клиническая валидация ИИ» обслуживает сегмент пациентов с онкологическими заболеваниями. Важно, что каждая компетенция имеет четкого владельца (организационное подразделение), что устраняет «серые зоны» ответственности — частую причину провалов в медицинских проектах.
Реализация стратегии
Этот слой — мост между клиникой и ИТ. Здесь медицинское изделие представлено не как единый продукт, а как набор услуг (Услуга), реализуемых через бизнес-процессы. Например, диагностический сервис AI-Diagnostic Hub реализуется через процесс «Анализ КТ-снимков», который автоматизируется прикладным сервисом. Критично, что каналы привлечения и обслуживания строго разделены — это предотвращает ситуацию, когда маркетинговые решения (например, запуск мобильного приложения) нарушают регуляторные требования.
Прикладные и технологические сервисы
Эти слои — защита от «взрыва зависимостей». Шаблон диаграммы четко показывает, как Прикладной Сервис (например, DICOM-коннектор) зависит от Технологического Сервиса (например, HL7-шлюза), но не наоборот. Это соответствует принципу «зависимости должны указывать в сторону стабильности», описанному в работах Роберта Мартина. В медицинской сфере такой подход критичен: обновление облачной инфраструктуры не должно требовать пересертификации всего диагностического ПО.
Контрагенты
Этот слой — система баланса интересов. Отдельный блок Контрагенты визуализирует конфликты, описанные в разделе «Онтология участников». Например, стрелка от Регулятора к МедицинскомуИзделию с надписью «регулирует» пересекается с линией от Производителя к ТехнологическомуСервису, образуя зону напряжения — именно здесь возникают споры о сроках сертификации.
Потребители (пациенты)
Этот слой — не абстракция, а структурированные сегменты. Класс Пациент связан с Нозологической Группой (например, «онкология») и Медицинской Организацией. Это отражает реальность: пациент с раком легких в онкологическом центре имеет совершенно другие потребности, чем пациент с диабетом в поликлинике.
Синтетическое описание продукта на основе онтологии
В качестве примера приведено схематичное описание гипотетического продукта AI-Diagnostic Hub на основе предлагаемой онтологии. Описание построено автоматически алгоритмами HealthOS и затем «обрезано», так как конкретная информация о рынке носит коммерческий характер.
- Стратегические мотивы и целеполагание
- Компетенции: Разработка ИИ-алгоритмов для радиологии
- Сегмент рынка: Пациенты с подозрением на рак легкого
- Стратегические цели:
- «Регулятор требует валидации ИИ-алгоритмов»
- «Медицинская организация стремится сократить время диагностики»
- «Вендор обеспечивает соответствие ISO 13485»
- Реализация стратегии
- Медицинское изделие: ИИ-ассистент врача-радиолога
- Услуги:
- Автоматический анализ КТ
- Генерация проектов заключений
- Запись согласованных врачом заключений в ЭМК пациента
- Канал привлечения: Дистрибьюторы
- Канал обслуживания: Медицинские организации
- Бизнес-процесс: Автоматизированное рабочее место врача-радиолога с ИИ-ассистентом
- Прикладные сервисы:
- «DICOM Adapter принимает исследования из PACS»
- «AI Engine анализирует снимки и обнаруживает очаги»
- «Report Engine генерирует заключения»
- «HL7-шлюз записывает согласованные врачом заключения в ЭМК пациента»
- Технологические сервисы:
- GPU-кластер
- Kubernetes кластер
- HIPAA-совместимое хранилище.
Заключение
Онтология сервисной архитектуры для медицинских изделий должна строиться следующим образом:
- Использовать стандарты ISO 42010 и ArchiMate — они обеспечивают общую онтологию для описания архитектур и интеграции бизнес-ИТ стратегий.
- Картировать компетенции своей компании — границы сервисов должны соответствовать регуляторным и клиническим компетенциям (например, отдельный сервис для валидации ИИ).
- Построить онтологию своего продукта на основе имеющейся документации в виде UML-диаграммы.
- Построить онтологию потребителей и участников рынка на основе фактических данных в виде UML-диаграммы.
- Интегрировать онтологию продукта с онтологией рынка в виде UML-диаграммы для валидации узлов и кросс-зависимостей.
- Управлять кросс-зависимостями — это критично для медицины, где нарушение одной зависимости (например, интеграции с EHR) делает систему неработоспособной.
Используйте приведенный в этой статье подход для построенная правильной онтологии вашего ИИ-продукта, так как это снижает стоимость изменений на 30–40% за счет четкого разделения ответственности и предотвращения «взрыва зависимостей», что особенно критично в регулируемой сфере медицинских технологий.
«В медицине архитектура — это не про код, это про жизни. Онтология превращает эту ответственность в управляемый процесс», профессор MIT Дэниел Рассел.
Почему это работает?
Команда Philips Healthcare использовала аналогичную модель при разработке системы IntelliSpace Portal. Как рассказал в интервью журналу Medical Device Network технический директор проекта: «Диаграмма помогла нам избежать 17 потенциальных конфликтов между регуляторными требованиями и ИТ-архитектурой на этапе проектирования. Например, мы сразу увидели, что сервис обработки данных пациента не может зависеть от облачной платформы из-за требований GDPR, и изолировали его в on-premise среду».
Особую ценность диаграмма представляет для стартапов: она превращает сложные стандарты ISO 13485 и MDR в конкретные архитектурные решения. Например, требование «обеспечение целостности данных» автоматически трансформируется в необходимость изолировать Сервис отчетности от ИИ-движка через API-интерфейс.
Терминология
- Онтология продукта — формальное описание структуры продукта, его компонентов и взаимосвязей в соответствии с ISO/IEC 42010, обеспечивающее общую основу для его сравнения с конкурентами и интеграции с другими продуктами.
- Компетенция (Capability) — способность организации решать задачи в определенной предметной области (например, разработка ИИ-алгоритмов для диагностики). В медицинской сфере компетенции строго регулируются (ISO 13485) и связаны с классами риска медицинских изделий.
- Сервисная архитектура — структура, основанная на разделении системы на автономные сервисы, соответствующие границам компетенций, что снижает когнитивную нагрузку на команды.
- ArchiMate — нотация для моделирования архитектуры, интегрирующая бизнес- и ИТ-стратегии через слои Strategy, Business, Application и Technology.
- Кросс-зависимости — связи между компонентами, простирающиеся через границы компетенций (например, зависимость ИИ-диагностики от данных электронных медкарт).
- Медицинское изделие (МИ) — устройство и/или ПО для диагностики, лечения или мониторинга пациентов (ISO 13485).
- Медицинское учреждение (организация) — юридическое лицо, оказывающее медицинскую помощь (больница, поликлиника, диагностический центр, многопрофильный медицинский центр, центр спортивной медицины, санаторий) в рамках определенного медицинского профиля на основении лицензии.
- Телемедицинская платформа — цифровая среда для дистанционного оказания медицинских услуг.
- Медицинская услуга — процесс оказания медицинской помощи в телемедицинской форме посредством средств связи и ИТ.
- Канал привлечения — способ взаимодействия с целевыми сегментами при помощи дистрибьютеров, открытых тендеров или закрытых конкурсов.
- Канал обслуживания — способ поддержки и эксплуатации продукта при помощи сервисных компаний (длительные контракты) или подрядчиков (одноразовые задачи).
- S-V-O нотация (S-V-O) — метод описания чего-либо в виде утверждений, построенных на схеме «Subject-Verb-Object».