Краткий ответ: ИИ на медицинских данных — это конвейер из семи вопросов, и большинство сбоев происходит из-за пропуска одного из них. Откуда берутся данные (запись FHIR, документы, устройства, слова самого пациента)? Как модель получает к ним доступ (контекстный API, который собирает релевантное, сервер протокола контекста модели, извлечение из записи)? Кто разрешил это делать (согласие пациента, ограниченное целью и временем, зафиксированное)? Что защищает людей в данных (деидентификация для всего, что выходит за пределы контекста ухода, синтетические данные для разработки, псевдонимизация для исследований)? Можно ли отследить каждый результат (происхождение входных и выходных данных)? Как мы узнаем, что это работает (оценка по клинической истине, а не по ощущениям)? Какие правила применяются (статья 9 и 22 GDPR, MDR, если результат влияет на клинические решения, EU AI Act, HIPAA)? Эта страница — карта; каждый вопрос имеет свою страницу.
Конвейер
Конвейер для ИИ в области медицинских данных состоит из семи этапов, каждый из которых задает вопрос: источник (откуда поступают данные), доступ (как модель получает к ним доступ), контроль (кто принял решение о разрешении), конфиденциальность (что защищает людей, чьи данные используются), прослеживаемость (можно ли отследить результаты), оценка (как измеряется успех) и правила (какие законы применяются).
| Этап | Вопрос | Как выглядит хорошо | Страница |
|---|---|---|---|
| Источник | Откуда берутся данные? | Запись FHIR с кодами (LOINC, SNOMED CT, ATC), документы с извлеченной структурой, данные устройства с указанием происхождения; не только скриншоты и PDF | FHIR Observation, FHIR DiagnosticReport |
| Доступ | Как модель получает к ним доступ? | Контекстный API или сервер MCP, который возвращает ограниченный, помеченный происхождением фрагмент записи; извлечение с использованием структурированных фильтров, а не свалка | RAG on medical records, Healthcare API for AI, MCP server |
| Контроль | Кто разрешил это делать? | Согласие пациента по цели и продолжительности; ограничения, применяемые на стороне сервера; журнал доступа, который читает пациент; работающая отмена | Patient consent platform, Who viewed my record? |
| Конфиденциальность | Что защищает людей? | Идентифицированные данные остаются в контексте ухода; деидентифицированные или синтетические данные для разработки, аналитики и обучения моделей; псевдонимизированные данные для исследований по разрешениям | De-identification, Synthetic patient data |
| Отслеживаемость | Можно ли отследить результаты? | Происхождение каждого входного элемента (кто записал, когда, откуда) и каждого результата ИИ (модель, версия, использованные входные данные), хранящееся вместе с записью | Medical data provenance |
| Оценка | Как мы узнаем, что это работает? | Тестовые наборы с клинической истиной, соответствие источникам, анализ ошибок по подгруппам, мониторинг в продакшене, пути человеческого обзора | Evaluating clinical LLMs |
| Правила | Какие законы применяются? | Статьи 9 и 22 GDPR, DPIA; MDR, если результат влияет на диагностику или лечение; EU AI Act для высокорисковых систем для устройств и перечисленных применений; HIPAA в США | The EU AI Act and health AI, SaMD classes, GDPR Article 9 |
Три вида ИИ, три профиля риска
ИИ в области медицинских данных бывает трех видов с тремя профилями риска: вспомогательный и административный ИИ, такой как резюме простым языком и черновики заметок, где риск связан с конфиденциальностью и неуловленными ошибками; поддержка принятия решений, такая как оповещение о взаимодействиях или сортировка, где риск клинический и применяется MDR; а также ИИ для работы с популяциями и исследований, где риски связаны с повторной идентификацией и предвзятостью.
Вспомогательные и административные: суммирование записи для пациента простым языком, составление заметки о визите из транскрипта для редактирования врачом, ответ на вопрос "где мой последний анализ крови" по разрешенной записи. Риск связан с конфиденциальностью и ошибками, которые человек может не заметить; MDR не применяется до тех пор, пока не принимается клиническое решение, но применяются обязанности по прозрачности EU AI Act и GDPR.
Поддержка принятия решений: пометка взаимодействия, предложение дифференциального диагноза, триаж. Риск клинический; применяется MDR (обычно класс IIa или выше), следует высокорисковый режим EU AI Act, требуются IEC 62304 и клиническая оценка. См. CDS Hooks explained о том, как такие системы подключаются к EHR.
Популяционные исследования: поиск закономерностей в множестве записей, сигналы фармаконадзора, поиск когорт. Риск — повторная идентификация и предвзятость; данные должны быть анонимизированы или псевдонимизированы по разрешениям, агрегированы с минимальными размерами ячеек, а методы должны быть оценены на предмет искажений. См. Secondary use of health data.
Режимы сбоев
Распространенные режимы сбоев ИИ в области медицинских данных включают помещение всей записи в запрос, внедрение запроса через документы, молчаливое умозаключение, которое записывает предположение модели в запись как будто от врача, обучение на идентифицированных данных без законных оснований, оценку только на демонстрационном наборе поставщика и журналы отладки, полные данных пациентов.
- Перегрузка контекста: вставка всей записи в запрос. Дорого, утечка данных, и модель обращает внимание на неправильные части. Ограниченный, ранжированный контекст с указанием происхождения работает лучше и подлежит аудиту.
- Внедрение запроса через документы: отсканированное письмо с надписью "игнорировать предыдущие инструкции". Относитесь ко всему содержимому записи как к данным; никогда не позволяйте ему устанавливать политику. См. RAG on medical records.
- Тихий вывод: модель, выводящая диагноз на основе поведения и записывающая его в карту как будто от врача. Результаты помечаются как сгенерированные ИИ с указанием происхождения и никогда не становятся "Condition" без подтверждения человека. См. FHIR Condition explained.
- Обучение на идентифицированных данных без оснований: дообучение на записях пациентов требует юридического основания, выходящего за рамки "у нас были данные"; деидентифицированные или синтетические данные обычно подходят.
- Оценка на демонстрационном наборе поставщика: оценивайте на вашей популяции, ваших языках, ваших типах документов и продолжайте оценивать после развертывания.
- Журналы, полные PHI: запросы и ответы, записанные для отладки, становятся второй, незащищенной записью. Псевдонимизируйте или не записывайте содержимое.
Стандарты и строительные блоки
Стандарты и строительные блоки для ИИ в области медицинских данных включают FHIR для записей и структурированных результатов ИИ, протокол контекста модели для управляемого доступа к инструментам и данным, SMART on FHIR для авторизации, работу HL7 по жизненному циклу данных ИИ/МО для прослеживаемости, ISO/IEC 42001 для управления ИИ и гармонизированные стандарты AI Act.
FHIR для записи и для структурированных результатов ИИ (Observation с derivedFrom, DocumentReference для сгенерированных резюме, Provenance с моделью в качестве агента); Model Context Protocol для предоставления ассистентам управляемого доступа к инструментам и данным; SMART on FHIR для авторизации; HL7 AI/ML Data Lifecycle и работа над происхождением для отслеживаемости; ISO/IEC 42001 для системы управления ИИ; гармонизированные стандарты EU AI Act по мере их публикации.
В Anpheros
Для ИИ в области медицинских данных Anpheros предоставляет запись FHIR R4 с кодами и происхождением, API контекста, который возвращает срез записи с меткой происхождения в пределах лимита токенов, сервер MCP, через который ассистенты читают собственную запись человека с его согласия, а также журналы согласия и доступа, которыми управляет человек. Anpheros не запускает диагностический ИИ.
Anpheros предоставляет запись (FHIR R4, кодированную, с указанием происхождения), контекстный API, который возвращает помеченный происхождением фрагмент в пределах бюджетного лимита токенов, сервер MCP, чтобы ассистенты, такие как Claude, могли читать собственную запись человека с согласия этого человека, а также журналы согласия и доступа, которые контролирует человек. Он не запускает диагностический ИИ и не записывает выводы ИИ в карту как клинические факты. Подробности на сайте для разработчиков: healthcare API for AI, MCP server, LLMs on healthcare data.
Связанные страницы
- RAG on medical records: how retrieval over a FHIR record works
- The EU AI Act and health AI
- Healthcare API for AI: provenance-labelled patient context
- De-identification of health data
- AI and your medical record (for patients)
- Secondary use of health data
- Anpheros MCP server (developer site)
- LLMs on healthcare data (developer site)
Источники
- Model Context Protocol specification
- HL7 FHIR R4: Provenance
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex
- ISO/IEC 42001:2023, AI management system
- WHO: Ethics and governance of artificial intelligence for health, guidance on large multi-modal models (2024)
- HL7 SMART App Launch
Частые вопросы
Могу ли я дообучить модель на записях пациентов?
Только при наличии юридического основания для этой цели (согласие или основание для исследований по статье 9(2)(j) с мерами защиты), DPIA и, как правило, деидентификации; идентифицированные записи не могут использоваться для обучения, потому что они случайно оказались доступны. Синтетические и деидентифицированные данные удовлетворяют большинству потребностей в разработке.
Является ли ИИ-резюме записи медицинским устройством?
Нет, если оно просто пересказывает содержимое записи для пациента или врача, не интерпретируя его для диагностики или лечения. В тот момент, когда оно предлагает клиническое значение результатов, оно становится средством поддержки принятия решений по MDR.
Что такое MCP и почему это важно здесь?
Model Context Protocol — это открытый стандарт для подключения ИИ-ассистентов к инструментам и источникам данных через серверы с определенными возможностями. Для медицинских данных он позволяет ассистенту читать запись человека через управляемый сервер, с согласия человека и с ведением журнала, вместо того чтобы вставлять данные в чат.
Как оценить функцию клинического LLM?
С помощью отдельного набора реальных случаев из вашей популяции, размеченных врачами, метрик корректности и соответствия источникам, анализа по подгруппам и языкам, обзора случаев сбоев и мониторинга после запуска. Бенчмарки поставщиков — это отправная точка, а не доказательство.
Попробуйте бесплатно в песочнице
Первый запрос FHIR за 5 минут. API HL7 FHIR R4 с встроенным согласием пациента: попробуйте в песочнице, затем подключите свое приложение или систему клиники.
Бесплатно · 30 синтетических пациентов · без карты
Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.
О Anpheros →