Обучение по выявлению первопричин отказов в выплатах: как перевести административный персонал с повторного ввода данных на выяснение причин отказов в выплатах.

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

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

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

Что такое обучение по выявлению первопричин отказов в выплате страхового возмещения?

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

Интересные факты

1. Опишите проблему с производительностью.

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

В рекомендациях по финансированию здравоохранения прослеживается та же логика. В статье для Ассоциации управления финансовыми ресурсами здравоохранения (HFMA) Дениз Уилсон и Трейси Томак описывают три уровня отказа. Причина — это указанный плательщиком код, например, код причины корректировки претензии (CARC). Проблема — это широкая категория, например, кодирование или документация. Первопричина — это внутренний сбой, который привел к расхождению в платежах. Они отмечают, что выявление первопричин требует внутреннего анализа медицинской документации, начислений и выставленных счетов, и что данные должны отражать фактические первопричины, а не только коды причин в платежных документах.Уилсон и Томак, HFMAОни также утверждают, что основную причину следует описывать таким образом, чтобы читатель мог предпринять конкретные действия для ее устранения.

Это различие является целью обучения. Повторный ввод данных работает на уровне причин. Анализ первопричин работает на третьем уровне.

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

2. Диагностика пробелов в знаниях и контексте.

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

1. Используется ли в современной практике реальная задача? Если обучение учит сотрудников считывать коды причин и применять стандартные корректировки, значит, они отработали навыки повторного ввода. Если же оценка представляет собой тест на знание определений кодов, то она измеряет запоминание, а не способность к расследованию.
2. Какова когнитивная нагрузка? В пересмотренной таксономии Блума сравнение отказов для выявления закономерностей и определение причины, наиболее соответствующей имеющимся доказательствам, находятся на уровнях анализа и оценки. Поиск кода находится ниже. Сопоставление действий с этими уровнями рассматривается в нашем руководстве. соответствие учебных мероприятий таксономии Блума.
3. Что-то ещё, помимо навыков, мешает? Проверьте доступ, инструменты и ответственных лиц. Сотрудники, которые не видят экран регистрации, не имеют возможности сообщить на ресепшен об ошибке или чья работа оценивается по количеству обработанных заявок в час, будут повторно вводить данные в соответствии с инструкцией. Сообщайте о причинах, не связанных с инструкцией, тем, кто может их устранить.

3. Подготовка и практика проектирования

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

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

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

Обратная связь. Свяжите это с принятыми решениями, а не с общей оценкой. Утверждение «Вы выявили отсутствующее разрешение, что является реальной причиной, но вы не проверили, отсутствовало ли оно или было внесено в неправильную запись о посещении» учит больше, чем «7 из 10».

Ввод данных в режиме реального времени или асинхронная проверка? Очное обучение наиболее эффективно в случаях, когда ситуация неоднозначна и сотрудникам необходимо услышать от опытного коллеги, как он разграничивает политику плательщика и ошибку ввода данных. Асинхронного анализа достаточно для сравнения письменного обоснования проблемы с аннотированным типовым ответом. Многие команды используют оба подхода: сначала самостоятельная подготовка, а затем интерактивное обсуждение самых сложных случаев.

4. Проработайте реалистичный пример.

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

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

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

Первая попытка. «Плательщик сообщил, что информация неверна. Я исправил поле и отправил данные повторно». Это повторяет причину и применяет стандартный способ исправления. При этом не ищется закономерность или причина.

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

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

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

5. Оценить возможности и спланировать передачу.

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

Критерии оценки: 0 означает отсутствие или неподтвержденность, 1 — частичное выполнение с существенными упущениями, 2 — полное выполнение и обоснование в соответствии с согласованными критериями. Критические ошибки следует определять отдельно, например, обработку идентифицируемой информации о пациенте вне утвержденных систем, чтобы общая оценка не скрывала ошибку. Данная рубрика является предложением, а не утвержденным стандартом готовности: адаптируйте ее совместно с руководителем отдела информатики или соответствия требованиям и проведите пилотное тестирование. Наше руководство по разработка интерактивных методов обучения с полезной обратной связью показывает, как писать отзывы, которые связаны с принятыми решениями.

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

Где интерактивная доставка помогает

Интерактивные форматы помогают участникам заранее определиться с ответом. На онлайн-сессии модератор может показать обезличенное резюме отказа, попросить каждого участника указать вероятную причину и первую проверенную запись, а затем показать распределение ответов перед обсуждением. Тот же кейс можно пройти в удобном для себя темпе для подготовки. AhaSlides поддерживает интерактивное обучение и переключение между онлайн- и самостоятельным обучением. Не используйте реальные данные пациентов, проверяйте любые функции создания контента, обратной связи или отчетности, которые вы планируете использовать, на соответствие собственному рабочему процессу, и рассматривайте ИИ, симуляторы и системную интеграцию как внешние или неподтвержденные, пока не увидите их работу. Рекомендации по выбору форматов см. в нашей статье. Когда использовать адаптивное, интерактивное и обучение в режиме реального времени?.

Измерьте, что изменилось.

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

Ограничения, которые могут остаться

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

Сообщите об этих проблемах спонсорам на раннем этапе и спланируйте отдельные меры по их устранению. Обучение улучшает способность персонала проводить расследования. Оно не меняет условий в очереди.

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

Что такое обучение по выявлению первопричин отказов в выплате страхового возмещения?

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

Чем отличается первопричина от причины, по которой вы её отрицаете?

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

Как вы оцениваете способность персонала выявлять первопричины?

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

Можно ли использовать реальные утверждения в процессе обучения?

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

Когда начать

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

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