Коротка відповідь: ШІ на медичних даних — це конвеєр із семи запитань, і більшість збоїв виникають через пропуск одного з них. Звідки беруться дані (запис 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 для запису та для структурованих результатів ШІ, протокол контексту моделі (Model Context Protocol) для керованого доступу до інструментів та даних, SMART on FHIR для авторизації, робота HL7 щодо життєвого циклу даних ШІ/ML для відстежуваності, 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 →