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

Процесс предварительного разрешения на использование электронных медицинских карт (ЭМК) состоит из пяти этапов:

1. Определите, требуется ли предварительное разрешение.
2. Соберите информацию, необходимую для поддержки предварительного запроса на авторизацию.
3. Отправьте запрос на предварительное разрешение.
4. Отслеживайте запрос на предварительную авторизацию для разрешения проблемы.
5. При необходимости дополните запрос на предварительное разрешение дополнительной необходимой информацией (и перейдите к шагу 4).

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

1. Обнаружение требований к покрытию (CRD) – Это обеспечивает поддержку принятия решений поставщиками услуг во время заказа диагностики, назначения лечения, выдачи направлений, планирования посещений и т. д.
2. Шаблоны и правила документации (DTR) – Это позволяет поставщикам услуг загружать интеллектуальные анкеты и правила, такие как язык клинического качества (CQL), и обеспечивает СМАРТ на FHIR приложение или приложение EHR, которое запускает анкеты и правила для сбора информации, относящейся к выполненной или запланированной услуге. Запуск анкет и правил также может осуществляться с помощью приложения, входящего в состав ЭМК провайдера.
3. Поддержка предварительной авторизации (PAS) – Это позволяет системам поставщиков отправлять (а системам плательщиков получать) запросы на предварительную авторизацию с использованием FHIR, при этом соблюдая нормативные требования по использованию X12 278, где это необходимо, для транспортировки предварительной авторизации, потенциально упрощая обработку для любого партнера по обмену (или для обоих). ).

В этой статье мы сосредоточимся на руководстве по внедрению CRD, чтобы определить требования к предварительной авторизации, и объясним, как CDS (Clinical Decision Support) Hooks использует AWS HealthLake, чтобы определить, требуется или нет предварительная авторизация.

Обзор решения

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

CDS Hooks — это спецификация Health Level Seven International (HL7). CDS Hooks предоставляет возможность внедрить дополнительные функции, работающие почти в реальном времени, в рабочий процесс врача по ЭМК. С помощью CDS Hooks можно должным образом оптимизировать практику отбора кандидатов, такую ​​как предварительное разрешение, а также другие требования к предварительной сертификации, такие как участие врача в сети. Эта функция помогает поставщикам услуг принимать обоснованные решения, предоставляя им информацию о состоянии пациента, вариантах лечения и формах, которые необходимо заполнить для облегчения оказания им помощи. Стратегическое использование CDS Hooks позволяет врачам быстро разрабатывать планы лечения, более ориентированные на пациента, и способствовать процессу предварительного разрешения, раскрывая важные административные и клинические требования. Дополнительную информацию о CDS Hooks и их спецификациях см. в разделе CDS Hooks. Веб-сайт.

На следующей диаграмме показано, как рабочий процесс CRD автоматизируется с помощью HealthLake.

Этапы рабочего процесса следующие:

1. Сотрудник поставщика услуг входит в систему ЭМК, чтобы открыть карту пациента.
2. Система EHR проверяет учетные данные пользователя и вызывает перехватчик просмотра пациента для получения информации о состоянии пациента.
3. Amazon API Gateway вызывает функцию Patient View Hooks AWS Lambda.
4. Функция Lambda проверяет и извлекает идентификатор пациента из запроса и получает информацию о состоянии пациента от HealthLake.
5. После просмотра состояния пациента пользователь вызывает перехватчик выбора заказа, чтобы получить информацию о требованиях к страховому покрытию для соответствующего препарата.
6. API Gateway вызывает лямбда-функцию перехватчиков требований к покрытию.
7. Функция Lambda извлекает информацию о претензиях для пациента, запускает правила CQL на основе отправленных лекарств и информации о претензиях, полученной из HealthLake, а также определяет, требуется ли предварительное разрешение.

Решение доступно в Определение требований к покрытию. Обнаружение с помощью перехватчиков CDS с AWS HealthLake. Репозиторий GitHub.

Предварительные условия

Данная должность предполагает знакомство со следующими сервисами:

Разверните приложение с помощью интерфейса командной строки AWS SAM.

Вы можете развернуть шаблон с помощью консоли управления AWS или интерфейса командной строки AWS SAM. Чтобы использовать CLI, выполните следующие шаги:

1. Установите интерфейс командной строки AWS SAM.
2. Загрузите пример кода из репозитория образцов AWS в свою локальную систему:

git clone https://github.com/aws-samples/aws-crd-hooks-with-awshealthlake-api
cd aws-crd-hooks-with-awshealthlake-api/

3. Создайте приложение с помощью AWS SAM:

sam build

4. Разверните приложение, используя пошаговый процесс:

sam deploy --guided

# Replace MY_VALUE with proper resource names
Configuring SAM deploy

======================

Looking for config file (samconfig.toml) : Not found

Setting default arguments for 'sam deploy'

     =========================================

     Stack Name (sam-app): aws-cds-hooks-with-healthlake

     AWS Region (us-east-1): us-east-2

     #Shows you resources changes to be deployed and require a 'Y' to initiate deploy

     Confirm changes before deploy (y/N):

     #SAM needs permission to be able to create roles to connect to the resources in your template

     Allow SAM CLI IAM role creation (Y/n):

     #Preserves the state of previously provisioned resources when an operation fails

     Disable rollback (y/N):

     cdsDemoServicesFunction has no authentication. Is this okay? (y/N): y

     cqlQueryFunction has no authentication. Is this okay? (y/N): y

     cqlQueryOrderFunction has no authentication. Is this okay? (y/N): y

     Save arguments to configuration file (Y/n): y

     SAM configuration file (samconfig.toml):

     SAM configuration environment (default):

Развертывание может занять 30 минут или более, пока AWS создаст хранилище данных HealthLake и связанные ресурсы в вашей учетной записи AWS. AWS SAM может истечь по истечении времени и вернуть вас в командную строку. Этот тайм-аут не позволяет AWS SAM показывать вам прогресс в облаке, но не останавливает развертывание в облаке. Если вы видите тайм-аут, перейдите в консоль AWS CloudFormation и проверьте статус развертывания стека CloudFormation. Интегрируйте CDS Hooks в свой клинический рабочий процесс после завершения развертывания стека CloudFormation.

Определить требования к покрытию для предварительного разрешения

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

CDS Hooks можно интегрировать с EHR, поддерживающей CDS Hooks. Альтернативно, если у вас нет EHR, доступной для тестирования, вы можете использовать общедоступную песочницу, как описано в разделе Репозиторий GitHub. Обратите внимание, что песочница CDS Hooks используется исключительно в целях тестирования.

После интеграции перехватчиков с EHR, когда пользователь переходит к клиническому рабочему процессу, перехватчик просмотра пациента запускается для настроенного пациента. Обратите внимание, что идентификатор пациента из клинического рабочего процесса должен существовать в HealthLake. Карточки, возвращенные API, указывают на то, что у пациента имеется инфекция носовых пазух, и врачу, возможно, потребуется заказать рецепт.

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

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

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

Очистить

Если вам больше не нужны ресурсы AWS, созданные вами при выполнении этого примера, вы можете удалить их, удалив развернутый вами стек CloudFormation:

sam delete --stack-name <<your-stack-name>>

Заключение

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

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

Об авторах

Маниш Патель, глобальный архитектор решений для партнеров, поддерживающий здравоохранение и биологические науки в AWS. Он имеет более чем 20-летний опыт создания решений для Medicare, Medicaid, плательщиков, поставщиков услуг и клиентов медико-биологических наук. Вместе с партнерами он разрабатывает стратегии выхода на рынок для ускорения разработки решений в таких областях, как электронная медицинская документация, медицинская визуализация, решения для многомодельных данных и генеративный искусственный интеллект. Он увлечен использованием технологий для преобразования отрасли здравоохранения и улучшения результатов лечения пациентов.

Шраван Вурпутур — старший архитектор решений в AWS. Будучи доверенным защитником интересов клиентов, он помогает организациям понять лучшие практики в области передовых облачных архитектур и дает советы по стратегиям, которые помогут добиться успешных бизнес-результатов для широкого круга корпоративных клиентов благодаря своему увлечению обучением, обучением, проектированием и созданием облачных технологий. решения.