Интеграция Epic с ChatGPT: как безопасно подключить данные EHR

Интеграция Epic с ChatGPT теперь позволяет медицинским командам использовать разрешённый контекст электронной медицинской карты (EHR) непосредственно в ChatGPT, не перенося данные карты вручную. OpenAI выпустила это подключение 1 сентября 2026 года вместе с девятью приложениями для работы с открытыми медицинскими данными. Подключение Epic доступно только для чтения, наследует действующие права каждого врача и может работать как внутри ChatGPT, так и — в поддерживаемых конфигурациях — внутри рабочего процесса EHR. В результате меньше времени уходит на сопоставление записей, анализов, лекарств и обновлений от профильных специалистов. Но условие принципиально: любой ответ остаётся черновиком, пока врач не сверит его с исходной картой, датами и возможными пробелами в данных.

Интеграция Epic с ChatGPT: краткий ответ — два защищённых контура данных

В рамках этого релиза «подключить EHR» означает настроить плагин Epic от OpenAI для одобренного корпоративного рабочего пространства. Это не означает, что ChatGPT умеет подключаться к любой EHR. Плагин получает только те данные карты, к которым уже имеет доступ вошедший в Epic пользователь, и не может записывать данные обратно, оформлять назначения, отправлять сообщения пациенту или расширять права доступа к карте. Главный источник требований к доступности и настройке — руководство OpenAI по подключению Epic.

Второй контур — плагин Healthcare Public Data. В него входят девять приложений, работающих только на чтение: PubMed, ClinicalTrials.gov, DailyMed, RxNorm, openFDA, CMS Coverage, CMS Open Data, Medicare Care Compare и NPI Registry. Они ищут информацию в открытых источниках, а не в картах пациентов. Имена пациентов, номера медицинских карт, даты рождения, номера участников страховых программ и другие идентификаторы нельзя включать в такие запросы.

Удобно представить эту схему как две двери в один клинический кабинет. Дверь Epic открывается личным пропуском каждого врача. Дверь к открытым данным ведёт в справочную библиотеку. Передавать идентификатор пациента через «библиотечную» дверь всё равно нельзя — даже если для рабочего пространства заключено Business Associate Agreement.

Чек-лист внедрения, который выдержит проверку службы безопасности

Правильный результат внедрения — не скриншот удачного ответа, а непрерывная цепочка доказательств: какие данные разрешалось использовать, кто имел к ним доступ, чем этот доступ был ограничен, что проверил врач и как система повела себя при неполном контексте.

1. Подтвердите допустимость рабочего пространства и юридические основания

Начните с письменного решения о запуске или отказе от него. Плагин Epic доступен только в одобренных рабочих пространствах ChatGPT for Healthcare и Enterprise с поддержкой HIPAA — с учётом порядка развёртывания в организации и конфигурации Epic. Для индивидуальных аккаунтов ChatGPT for Clinicians он недоступен.

До того как защищённая медицинская информация (PHI) попадёт в рабочий процесс, подтвердите применимое Business Associate Agreement (BAA) — договор, регулирующий обработку PHI в пределах своего действия, — а также допустимость рабочего пространства и функций, авторизацию Epic и все соглашения, необходимые для выбранного сценария. Сам факт доступности функции ещё не означает, что на неё распространяется BAA. В перечне функций, совместимых с HIPAA OpenAI намеренно перечисляет конкретные возможности и отдельно указывает: улучшенная память не покрывается BAA, поэтому, если администратор включит её, передавать туда PHI нельзя.

В документе об одобрении должны быть указаны четыре ответственных: владелец рабочего пространства, администратор Epic, владелец направления конфиденциальности или безопасности и клинический руководитель, уполномоченный остановить пилот.

2. Проведите инвентаризацию источников до подключения

Составьте матрицу источников: по одной строке на каждую систему или приложение. Для Epic укажите среду, одобренные ресурсы FHIR, популяцию пациентов, пользовательские роли и место запуска ChatGPT — в собственном рабочем пространстве или в поддерживаемом интерфейсе EHR. FHIR — стандартный адрес интерфейса, через который запрашиваются ресурсы медицинской карты. Сам по себе он открывает путь к данным, но не даёт прав на них.

Каждое из девяти приложений с открытыми данными одобряйте отдельно. Доступность плагина, включение приложения, разрешение для роли и подключение пользователем — разные переключатели. Установка плагина не подключает автоматически все приложения. Руководство по настройке открытых данных также предупреждает: запрос может покинуть рабочее пространство и попасть к организации — оператору источника. Поэтому правила хранения и размещения данных требуют отдельной проверки.

Зафиксируйте в матрице чёткую границу: через Epic можно передавать разрешённый контекст пациента, а запросы к открытым данным не должны содержать PHI. Если процессу нужны оба контура, сформулируйте вопрос к открытому источнику в общем виде, после чего врач сопоставит ответ со ссылками и картой внутри одобренного процесса работы с контекстом пациента.

3. Привяжите доступ к реальной личности пользователя

Администраторы рабочего пространства и Epic настраивают приложение EHR с базовым URL FHIR R4 организации, OAuth client ID, OAuth client secret и точным callback URL, показанным во время настройки. OAuth передаёт вход Epic, позволяя предоставить доступ без ввода пароля в чате.

Затем каждый врач подключает собственный аккаунт Epic. Установка плагина для роли не подключает ничью учётную запись и не расширяет права этого человека в Epic. Учётные данные, клиентские секреты и токены доступа должны оставаться в одобренных процессах настройки и входа — им не место в диалоге ChatGPT или задаче Codex.

До клинического пилота проверьте приём новых сотрудников, смену ролей и увольнение. Единый вход SAML и автоматическое управление аккаунтами через SCIM могут обслуживать жизненный цикл идентификационных данных в рабочем пространстве, но приёмочное испытание должно также доказать: после удаления пользователя из роли Epic соответствующий доступ к карте через ChatGPT исчезает.

4. Превратите принцип минимальных привилегий в конкретные настройки

Режим «только чтение» снижает риск, но не равнозначен минимальным привилегиям. Если роли и области доступа слишком широки, пользователь и без права записи может увидеть лишнее.

Установите для плагина Epic статус Available или Installed только для одобренных ролей. Вместе с администратором Epic проверьте каждую область OAuth. OpenAI перечисляет типовые области чтения для пациентов, диагнозов, аллергий, запросов на лекарства и их отпуска, наблюдений, документов, диагностических отчётов, обращений и связанных бинарных файлов. Добавляйте области для приёмов, процедур, вакцинаций или планов лечения только тогда, когда они нужны одобренному рабочему процессу.

В контуре открытых данных выдавайте каждое приложение лишь тем ролям, которым оно необходимо. Фармацевтической команде могут понадобиться DailyMed и RxNorm. Исследовательской — PubMed и ClinicalTrials.gov. Ни одной из них автоматически не нужны все наборы CMS. Записывайте, кто и когда одобрил каждое разрешение, а также дату следующего пересмотра.

5. Встройте врачебную проверку в структуру ответа

Каждый шаблон с контекстом пациента должен требовать пять полей:

1. Что изменилось.
2. Подтверждающие записи из карты.
3. Значимые даты.
4. Отсутствующий или недоступный контекст.
5. Решение врача и подтверждение проверки.

По информации OpenAI, ответ Epic содержит ссылки на подтверждающие данные карты и предписывает врачу проверить исходную запись и соответствующие даты, прежде чем опираться на результат. Такая сверка с источником и есть контрольный механизм. Даже безупречно написанное резюме не должно проходить проверку, если его нельзя проследить до подтверждающих записей карты.

OpenAI сообщает, что врачи признали безопасными 99.1% из 4,363 ответов в 27 сценариях использования подключённой EHR. Это полезное подтверждение качества оценки, но не основание пропускать локальную валидацию. Кроме того, «безопасный» не означает «полный, актуальный и правильный для конкретного пациента».

6. Собирайте аудиторские доказательства и безопасно останавливайтесь при нехватке контекста

Диалоги с приложениями доступны через Compliance API — интерфейс экспорта для систем управления, — а вызовы приложений фиксируются в Compliance Logs. До запуска убедитесь, что там действительно присутствуют поля, необходимые аудиторам. Как минимум комплект доказательств должен связывать пользователя, роль, приложение, время, класс источника, шаблон сценария, результат проверки и тикет исключения, при этом не копируя во вторую систему больше PHI, чем требуется для аудита.

Резервный сценарий должен быть явно виден в рабочем процессе. Доступные данные зависят от конфигурации Epic, одобренных ресурсов и текущих прав пользователя на карту. Если отсутствует карта пациента или необходимый ресурс, в ответе должно появиться сообщение «Недостающий контекст» с указанием отсутствующей категории источника и инструкцией вернуться в Epic. Заполнять пробел по памяти или с помощью поиска по открытым данным нельзя.

Если открытый источник ничего не нашёл, сузьте или переформулируйте запрос без PHI, проверьте заявленную область покрытия источника и повторите попытку позже, если сервис недоступен или ограничивает частоту запросов. Отсутствие результата не доказывает, что нужного исследования, предупреждения, правила или записи о поставщике медицинских услуг не существует.

Рассчитайте экономику до масштабного внедрения

OpenAI не публикует фиксированную цену ChatGPT for Healthcare. Стоимость зависит от размера организации и требований к внедрению, а расширенные функции в рабочих пространствах Enterprise расходуют общий пул кредитов на уровне контракта. Поэтому убедительное экономическое обоснование строится на коммерческом предложении и измеримом пилоте, а не на условном сравнении цены одного места.

Используйте формулу:

monthly workflow value = completed reviews x verified minutes saved x loaded clinician cost / 60

Затем вычтите полную стоимость эксплуатации: корпоративный контракт, настройку Epic и OAuth, проверку безопасности, проектирование процесса, обучение, клиническую валидацию, аудит и поддержку. Вместе с экономией времени измеряйте количество исправленных резюме и эскалаций. Черновик, который готовится быстрее, но требует дополнительной проверки, экономией не является.

Смежный рынок даёт полезный ценовой ориентир. В официальном прайс-листе Freed тариф Premier для врачей, включающий контекст пациента и отправку данных в EHR, стоит $119 в месяц или $104 в месяц при годовой оплате. Это не прямой аналог цены для медицинской системы. Но ориентир показывает, что врачи уже платят за сбор контекста визита. Экономический вопрос для ChatGPT звучит так: способно ли одно управляемое рабочее пространство решать эту задачу в одобренных клинических, исследовательских и операционных процессах, не создавая ещё один разрозненный инструмент.

Семь сценариев по ожидаемой операционной отдаче

1. Подготовка к приёму пациента со сложной историей

Врач первичного звена или профильный специалист, работающий с объёмной картой, может запросить изменения с прошлого визита, недавние анализы, требующие внимания, смены лекарств и невыполненные рекомендации других специалистов. ChatGPT подготовит черновик справки на основе разрешённых записей, лекарств, диагнозов, обращений и лабораторных результатов, а затем укажет подтверждающие места в карте.

Этот сценарий на первом месте, потому что работа повторяется перед каждым соответствующим приёмом и отнимает дорогое время врача. Лучший запрос здесь — не «резюмируй всё», а краткая сводка изменений с датами, ссылками на источники и явным разделом о недостающем контексте.

2. Передача смены и пациента между службами

Стационарный врач или замещающий специалист может запросить хронологию недавних обращений, текущие проблемы, изменения лекарственной терапии и незавершённые последующие действия по пациенту, к данным которого у него есть доступ. Принимающий врач сверяет каждый важный пункт с картой, прежде чем принять передачу.

Польза — более единообразная отправная точка при переходе пациента от одного специалиста к другому. Риск столь же очевиден: если тип записи или обращение находится за пределами разрешённой области, сводка должна отметить пробел, а не создавать впечатление полной картины.

3. Проверка изменений лекарственной терапии

Фармацевтическая или клиническая команда может сопоставить текущие запросы на лекарства, записи об отпуске, аллергии, последние анализы и релевантные заметки из Epic, а затем отдельно обратиться к DailyMed или RxNorm за открытой информацией о маркировке и идентификаторах. Контур пациента отвечает на вопрос «что находится в этой разрешённой карте?», а открытый контур — «что говорит официальный справочник?».

Такое разделение сокращает переключения между вкладками и сохраняет границу между PHI и открытыми запросами. Оно не определяет дозировку, взаимозаменяемость, покрытие по лекарственному формуляру или лечение. Эти решения остаются за квалифицированными специалистами.

4. Отслеживание направлений и нерешённых вопросов

Координатор лечения может запросить найденные в разрешённой карте недавние направления, рекомендации специалистов и открытые последующие действия. Результат можно оформить как список задач, снабдив каждый пункт подтверждающей записью и датой.

Это сокращает ручной поиск в длинной карте. Но координатор всё равно проверяет, не была ли задача выполнена в другом месте: подключённые ресурсы могут охватывать не все события, связанные с записью на приём, сообщениями или лечением во внешней организации.

5. Подготовка доказательств для предварительного страхового согласования

Команда согласования может использовать разрешённый контекст карты, чтобы составить черновик фактов о пациенте в поддержку запроса, а затем отдельным открытым запросом без PHI найти нужную версию правила в CMS Coverage. Перед отправкой человек должен сверить обе части.

Это ускоряет сбор данных и подготовку текста, но не позволяет определить страховые льготы конкретного человека. Источники правил покрытия ограничены по объёму и версиям, а итоговый запрос должен соответствовать действующим требованиям страховщика. Небольшим практикам, которые пока не готовы к корпоративному подключению EHR, могут быстрее принести пользу более простые процессы из материала «Автоматизация стоматологической клиники с помощью ИИ».

6. Отбор клинических исследований и доказательств

Исследовательская команда может искать набирающие участников исследования через ClinicalTrials.gov и сопоставлять критерии включения, а в PubMed находить связанные публикации. Затем врач сможет сравнить эти открытые критерии с разрешённой картой, не передавая идентификаторы пациента в запрос к открытому источнику.

Польза — более быстрый первичный просмотр разрозненных источников. Статус исследования и соответствие критериям всё равно необходимо подтверждать у его команды, а записи в источниках могут меняться.

7. Планирование программ управления здоровьем населения

Команда, которая планирует программу по диабету, сердечно-сосудистым заболеваниям или безопасности лекарств, может объединить открытые исследования, активные испытания, сведения о покрытии Medicare, показатели учреждений и записи о поставщиках медицинских услуг. Так руководители программы получат справку со ссылками на источники без использования данных отдельных пациентов в открытых приложениях.

Этот сценарий даёт меньшую немедленную отдачу, поскольку запускается периодически, а не при каждом визите. Однако он способен повысить качество и прослеживаемость планирования на стыке исследований и операционной работы.

Два продукта, которые стоит построить вокруг подключения

1. Самая сильная возможность: консоль доказательств для внедрения EHR

Создайте для ИТ-службы, команды конфиденциальности и органов клинического управления медицинской системы единый центр контроля внедрения. Он будет учитывать одобренные источники, роли, области Epic, тестовые сценарии, исключения и аудиторские выгрузки, а затем формировать по каждому релизу рабочего процесса комплект доказательств, готовый к проверке.

Для столь узкой инфраструктурной задачи спрос выглядит необычно коммерческим. Запрос «EHR integration» получает около 590 поисков в месяц в США при цене клика $42.25. У «EHR integration services» около 140 поисков и цена клика $80.68, а ставка для верхней позиции достигает $78.96. Покупатели уже ищут помощь, а поставщики дорого платят за возможность до них достучаться.

Минимальная продаваемая версия поддерживает одну среду Epic и одно рабочее пространство ChatGPT. Она импортирует или фиксирует одобренные области FHIR и матрицу ролевого управления доступом (RBAC), запускает фиксированный набор приёмочных тестов, хранит подтверждения и экспортирует отчёт об исключениях. Честный недостаток — длинный цикл корпоративных продаж и постоянные изменения платформы. Продукт не заменит BAA, локальный анализ рисков или клиническую ответственность. Его защитой от копирования должны стать качество модели доказательств и библиотека внедрений, а не поверхностная панель.

2. Пакет подготовки к приёму со сверкой источников

Создайте набор многократно используемых шаблонов ChatGPT for Healthcare для клиник, ведущих сложных пациентов, и дополните его протоколом проверки. Каждая справка будет включать изменения, лекарства, анализы, последующие действия, ссылки на карту, даты и блок «Недостающий контекст» перед подтверждением врача.

Запрос «AI medical assistant» получает около 140 поисков в месяц в США, имеет коммерческий интент и цену клика $24.01. Тариф Freed Premier за $119 в месяц включает сводки визитов, контекст пациента и отправку данных в EHR. Это прямое доказательство готовности платить за такую задачу, хотя и не за эту конкретную модель внедрения.

MVP — три шаблона для разных специальностей, карта ролей, чек-лист проверки источников и дат и система показателей пилота. Сначала продавайте его как пакет внедрения, а не как отдельное ПО. Слабое место — защищённость от конкурентов: шаблоны легко скопировать, и реальную ценность они приобретают лишь вместе с управлением изменениями, валидацией и отраслевым управлением для каждой специальности.

Какие задачи это подключение не решает

Подключение хорошо подходит для синтеза информации и проверки. Для автономных клинических решений или незаметного выполнения действий оно не годится.

• Оно не подключается к любой EHR. Документированная интеграция с картой пациента работает с Epic.
• Оно не записывает данные в карту, не оформляет назначения и не отправляет сообщения пациентам.
• Оно не гарантирует полноту контекста. Доступные данные определяются конфигурацией, одобренными ресурсами и правами пользователя.
• Оно не превращает BAA в безусловное разрешение для любой функции или стороннего сервиса.
• Оно не делает открытые наборы данных персонализированными для пациента, полными или достаточными для клинического решения.
• Оно не снимает с врача обязанность проверять исходную карту и даты.
• Оно не доказывает, что существующие поля аудита соответствуют требованиям организации к доказательствам.

Вывод для конфиденциальности тот же, что и для других функций ChatGPT с богатым контекстом: чем шире доступ, тем больше практическая польза — и тем важнее становятся архитектура разрешений и границы хранения. Этот компромисс в другом сценарии с большим объёмом контекста разбирает материал «Конфиденциальность истории действий ChatGPT на компьютере».

Показатель безопасности 99.1% и доля оценок «хорошо или лучше» выше 93% по каждому из пяти протестированных открытых источников выглядят обнадёживающе. Но они не заменяют локальное тестирование с вашими ролями, ресурсами, специальностями и сценариями отказа.

Часто задаваемые вопросы

Что означает интеграция EHR?

Интеграция EHR — это подключение электронной медицинской карты к другой одобренной системе, чтобы разрешённые данные могли передаваться между ними. В этом релизе ChatGPT документированный путь к EHR реализован через плагин Epic только для чтения, который соблюдает действующие права каждого пользователя в Epic.

Как интегрировать EHR с ChatGPT?

Сначала подтвердите наличие одобренного рабочего пространства ChatGPT for Healthcare или Enterprise с поддержкой HIPAA и необходимое юридическое покрытие. Затем согласуйте работу с OpenAI и администратором Epic, настройте приложение EHR для конкретного рабочего пространства с URL FHIR R4 и данными OAuth, проверьте области и роли, опубликуйте приложение и попросите каждого одобренного пользователя подключить собственный аккаунт Epic.

Что такое услуги по интеграции EHR?

Это услуги по внедрению, которые подключают, защищают, тестируют и поддерживают потоки данных между EHR и другой системой. Для этого развёртывания полезны настройка приложения Epic, настройка идентификации, проектирование областей и RBAC, клиническая валидация, сопоставление аудиторских данных, обучение и обработка исключений.

Каковы три ключевые проблемы и сложности EHR?

Для рабочего процесса ИИ, подключённого к EHR, три главные проблемы — неполный контекст, чрезмерно широкий доступ и непроверенный результат. Практические меры контроля — явное состояние недостающего контекста, роли и области по принципу минимальных привилегий и проверка врачом исходной карты и дат.

Что сделать в понедельник

Соберите на одной рабочей встрече руководителя медицинской информатизации (CMIO), ответственного за конфиденциальность, администратора Epic, владельца рабочего пространства и двух практикующих врачей. Выберите одну повторяющуюся задачу проверки, сопоставьте только необходимые ей данные и сначала испытайте процесс на одобренных тестовых или учебных картах: с полной картой, ограниченным ресурсом, истёкшим сеансом и отсутствующим результатом. Не расширяйте пилот, пока ответ не начнёт явно указывать недостающий контекст, ссылки на источники не выдержат проверку, доступ не будет корректно закрываться, а аудиторская выгрузка не ответит, кто, к чему и когда обращался.

Если вашей организации нужна одна из таких управляемых интеграций для здравоохранения, изучите системы ИИ для промышленной эксплуатации.