Команда з виставлення рахунків лікарні працює з чергою відхилених заявок. Кожна з них отримує однакове виправлення: хтось виправляє поле, повторно вводить дані та повторно надсилає заявку. Через тиждень заявки з тією ж схемою повертаються. Ніхто не запитує, чому їх було відхилено, тому виправлення так і не доходить до кроку, який спричинив помилку.
Це ілюстративний сценарій, а не задокументований випадок. Він описує прогалину, яку має заповнити навчання з визначення першопричини відхилення претензій: відстань між виправленням відхиленої претензії та визначенням того, яка частина робочого процесу її спричинила.
Цей посібник призначений для директорів відділів навчання та розвитку лікарень та керівників відділів інформатики або комплаєнсу, які з ними працюють. У ньому розповідається, як описати проблему з продуктивністю, діагностувати прогалини в навчанні та контексті, розробити підготовку та практику, опрацювати випадок та оцінити, чи перенесе навичка на робочий процес. Йдеться про розробку навчання. Використовуйте лише деідентифіковані випадки та майте власний цикл отримання доходу, керівники відділів інформатики та комплаєнсу перевіряють кожен випадок, код та відповідь, перш ніж хтось пройде навчання.
Що таке навчання щодо першопричин відмови у виплаті претензій?
Навчання з питань першопричин відмови у виплаті претензій навчає адміністративний персонал досліджувати повторювані моделі відмов та виявляти причини, що лежать в їх основі, в робочому процесі. Завдання має аналітичний характер. Персонал розглядає докази у претензії та в записі, відокремлює те, що сказав платник, від того, що пішло не так всередині організації, та описує причину, достатньо конкретну, щоб хтось міг на неї вжити заходів.
Швидкі факти
| Питання | Коротка відповідь |
|---|---|
| Яке завдання? | Дослідіть повторювані моделі відмов та визначте причини робочого процесу. |
| Який бал ви отримуєте? | Правильна ідентифікація причини та частота повторення цієї моделі заперечення. |
| Чи достатньо освіжити знання з кодування? | Ні. Це розвиває знання правил, але не звичку знаходити причину заперечення. |
| Хто перевіряє зміст? | Керівник відділу з питань циклу доходів, інформатики або комплаєнсу з використанням анонімізованих справ. |
| Чого не можуть виправити тренування? | Зміни політики платників, системні обмеження, штатний розклад та нечітка приналежність до певного кроку. |
| Звідки ви знаєте, що це спрацювало? | Нове, невидиме заперечення, оцінене за узгодженими критеріями, з подальшим спостереженням за рецидивом. |
1. Опишіть проблему продуктивності
Почніть із завдання: дослідіть повторювані моделі відмов та визначте причини робочого процесу. Два слова мають значення. Повторюваність означає, що одиниця роботи є закономірністю, а не окремим твердженням. Причини робочого процесу означають, що відповідь знаходиться всередині власного процесу організації, а не в переказі платника.
Керівництво з фінансування охорони здоров'я проводить ту саму лінію. У статті для Асоціації фінансового менеджменту охорони здоров'я (HFMA) Деніз Вілсон та Трейсі Томак описують три рівні відмови. Причиною є зазначений платником код, такий як код причини коригування заяви (CARC). Проблема полягає в широкій категорії, такій як кодування або документація. Першопричиною є внутрішній збій, який призвів до відхилення платежу. Вони зазначають, що виявлення першопричин вимагає внутрішнього перегляду медичної карти, нарахувань та виставлених рахунків, і що дані повинні відображати фактичні першопричини, а не лише коди причин на грошових переказах (Вілсон і Томак, HFMA). Вони також кажуть, що першопричину слід написати так, щоб читач міг діяти відповідно до конкретної причини.
Ця відмінність є метою навчання. Перекодування працює на рівні причини. Аналіз першопричини працює на третьому рівні.
Напишіть звіт про ефективність одним реченням і попросіть керівника циклу доходів перевірити його: «Враховуючи групу пов’язаних відмов, співробітник переглядає заяву та запис, відокремлює причину платника від внутрішньої причини, називає конкретну причину та пропонує виправлення, а також вказує, хто за нього відповідає».
2. Діагностуйте прогалини у навчанні та контексті
Перш ніж щось створювати, порівняйте завдання з тим, що практикується та оцінюється у вашій поточній програмі. Три питання зазвичай відрізняють прогалину в навчанні від чогось іншого:
- Чи використовує сучасна практика реальне завдання? Якщо навчання навчить персонал зчитувати коди причин та застосовувати стандартну корекцію, вони практикуватимуть перекодування. Якщо оцінювання – це тест на визначення кодів, воно вимірює запам'ятовування, а не дослідження.
- Що таке когнітивний попит? У переглянутій таксономії Блума порівняння заперечень для пошуку закономірності та визначення того, яка причина найкраще відповідає доказам, знаходиться на рівнях аналізу та оцінки. Пошук коду знаходиться нижче. Зіставлення дій з цими рівнями розглядається в нашому посібнику зіставлення навчальних завдань з таксономією Блума.
- Чи щось, окрім навичок, заважає? Перевірте доступ, інструменти та право власності. Співробітники, які не бачать екран реєстрації, не мають можливості повідомити на рецепцію про помилку або оцінюються за кількістю заявок, що розглядаються за годину, перевведуть дані відповідно до інструкцій, наданих у навчанні. Повідомте про причини, не пов'язані з навчанням, людям, які можуть їх виправити.
3. Підготовка та практика проектування
Як тільки ви зрозумієте, які прогалини може заповнити навчання, дайте кожному етапу окреме завдання.
Підготовка. Перевірте передумови за допомогою короткої діагностики: термінологію відмови, життєвий цикл заяви від реєстрації до переказу коштів та значення полів коду причини. Для цього етапу підходить самостійне навчання. Перевірка відкликання підтверджує лише передумови.
Практика. Використовуйте розтин для перевірки цілісності даних у деідентифікованих випадках. Під час розтину персонал бере відхилену заяву, відстежує її у зворотному порядку через запис, звинувачення та реєстрацію, і записує, де допущено помилку. Багато співробітників знаходять один і той самий випадок більш ніж одним способом, тому обговорення – це те, з чого відбувається навчання. Запитуйте обґрунтування, а не просто ярлик.
Зворотний зв'язок. Пов’яжіть це з рішеннями, а не із загальною оцінкою. «Ви визначили відсутність авторизації, що є реальною причиною, але не перевірили, чи вона відсутня, чи введена під час неправильного візиту» навчає більше, ніж «7 з 10».
Живий ввід чи асинхронний огляд? Живий коучинг додає найбільшої цінності, коли справа неоднозначна, і персоналу потрібно почути, як досвідчений колега відокремлює політику платників від помилки введення даних. Асинхронного огляду достатньо для порівняння письмової заяви про причину позову особи з анотованою зразковою відповіддю. Багато команд використовують обидва варіанти: спочатку підготовку у власному темпі, а потім фасилітовану сесію з найскладніших справ.
4. Розгляньте реалістичний приклад
Ілюстративний та анонімний. Лід з циклу доходів або інформатики повинен перевірити справу та критерії відповіді перед використанням.
Справа. Протягом одного місяця одинадцять заявок на амбулаторне лікування за ту саму послугу було відхилено з тієї ж причини, що й платник. Кожну з них було виправлено та подано повторно шляхом повторного заповнення того самого поля. Три з одинадцяти знову були відхилені.
Завдання. Співробітник переглядає заяви та запис, відокремлює заявлену платником причину від внутрішньої причини, називає конкретну причину та повідомляє, яка додаткова інформація чи підтримка йому потрібна.
Перша спроба. «Платник сказав, що інформація неправильна. Я виправив поле та повторно надіслав». Тут повторюється причина та застосовується звичайне виправлення. Закономірність чи причина не шукаються.
Зворотній зв'язок та повторна спроба. Тренер вказує на два факти у справі: усі одинадцять заяв мають спільну послугу та місце реєстрації, а три, що надійшли, були виправлені різними співробітниками. Під час повторної спроби особу просять подивитися, де поле було вперше введено, і чи той самий крок призвів до всіх одинадцяти заяв.
Сильніша спроба. «Усі одинадцять заявок було зареєстровано в одному місці, тому я думаю, що помилка виникає під час реєстрації, а не під час виставлення рахунків. Я б витягнув записи реєстрації для цих заявок і перевірив, чи заповнюється поле зі значення за замовчуванням. Якщо так, повторне введення даних під час виставлення рахунків продовжуватиме не вдаватися. Я б не називав це проблемою політики платника, доки не перевірю, що правило платника не змінилося. Я поділюся висновками з керівником реєстрації та запитаю, кому належить це поле». У цій відповіді називається закономірність, конкретне місцезнаходження причини, перевірка, яка підтвердить або виключить її, і хто має діяти.
Чому кожна відповідь є обґрунтованою або неповною. Оцінюйте кожен за затвердженими критеріями, а не за вподобаннями коуча. Перша спроба — це поширена звичка, але вона залишається на рівні причини. Більш переконлива спроба відділяє політику платників від введення даних і залишається в межах ролі особи.
5. Оцінка можливостей та планування передачі
Доказом здібностей є реакція на патерн заперечення, якого учень не бачив. Оцініть правильне визначення причини та з часом частоту повторення досліджуваного патерну. Проста рубрика використовує шкалу від 0 до 2 для кожного критерію:
| критерій | Спостережувані докази |
|---|---|
| Виконання завдання | Досліджує схему заперечення та фіксує докази, що стоять за названою причиною. |
| Обґрунтування | Пояснює обмеження, альтернативи та те, що залишається невизначеним. |
| Межі | Використовує затверджені процедури та звертається за допомогою, коли інформації чи повноважень недостатньо. |
Опорні точки: 0 – відсутній або непідтверджений, 1 – частковий з відповідними пропусками, а 2 – повний та обґрунтований відповідно до узгоджених критеріїв. Окремо визначте критичні помилки, такі як обробка ідентифікованої інформації про пацієнта поза затвердженими системами, щоб загальна оцінка не могла їх приховати. Ця рубрика є пропозицією, а не затвердженим стандартом готовності: адаптуйте її разом з керівником з інформатики або комплаєнсу та випробуйте її в пілотному режимі. Наш посібник з розробка інтерактивної практики з корисним зворотним зв'язком показує, як писати відгуки, що посилаються на рішення.
Плануйте переведення речей свідомо. Додайте подальший контроль після того, як персонал деякий час відпрацював свою чергу, наприклад, щомісячний огляд, де кожна людина приносить одну досліджену схему заперечення та що сталося після виправлення.
Де допомагає інтерактивна доставка
Інтерактивні формати допомагають, коли кожен має взяти на себе зобов'язання, перш ніж почує відповідь. Під час живого сеансу фасилітатор може показати анестезований виклад відмови, попросити кожну особу ввести ймовірну причину та перший запис, який вони перевірили б, а потім показати розкид перед обговоренням. Той самий випадок може проходити у власному темпі для підготовки. AhaSlides підтримує інтерактивне навчання та перехід між живим сеансом та власним темпом. Не включайте будь-які реальні дані пацієнтів, перевірте будь-яку конкретну функцію створення, зворотного зв'язку чи звітності, на яку ви плануєте покладатися, порівняно з власним робочим процесом, та розглядайте штучний інтелект, симулятори та системні інтеграції як зовнішні або непідтверджені, доки ви не побачите їх у роботі. Щоб отримати рекомендації щодо вибору форматів, дивіться нашу статтю про коли використовувати адаптивне, інтерактивне та живе навчання.
Виміряйте, що змінилося
Заздалегідь вирішіть, що покаже, що персонал може виконати завдання. Порівняйте правильну ідентифікацію причини на невидимому шаблоні відмови з базовим рівнем та відстежуйте рівень повторення для досліджених шаблонів. Визначте, хто включений, знаменник та час. Якщо результати покращаться, перевірте, що ще змінилося за той самий період, наприклад, оновлення політики платників, новий екран реєстрації або зміна обсягу претензій, перш ніж зараховувати навчання.
Обмеження, які можуть залишитися
- Політика платника. Деякі відмови відбуваються після зміни правил щодо платників. Ретельне розслідування це виявляє, але навчання цього не змінює.
- Системні обмеження. Якщо система не може показати, де було введено поле, персонал мало що може відстежити.
- Право власності. Причина, виявлена під час реєстрації, потребує, щоб хтось із учасників реєстрації відповідав за її виправлення.
- Покриття справ. Одна модель заперечення показує одну модель. Оцінка не описує судження людини загалом.
- Трансфер Продуктивність у навчальному випадку не така ж, як продуктивність із повною чергою.
Заздалегідь повідомте про це спонсорів та сплануйте окремі виправлення. Навчання покращує те, що персонал може дослідити. Воно не змінює умови навколо черги.
Часті питання
Що таке навчання щодо першопричин відмови у виплаті претензій?
Це навчає адміністративний персонал розслідувати повторювані відмови у виплаті претензій та відстежувати їх до кроку робочого процесу, який їх спричинив, замість того, щоб виправляти та повторно подавати кожну претензію.
Чим відрізняється корінна причина від причини заперечення?
Причиною є вказаний код платника. Першопричиною є внутрішній збій, що стоїть за ним. Відмова може мати один і той самий код причини та кілька різних першопричин.
Як ви оцінюєте, чи можуть співробітники знайти першопричини?
Наведіть шаблон заперечення, якого учень не бачив, та оцініть названу ним причину та докази, що стоять за нею, за узгодженими критеріями. Тест на код підтверджує лише передумови.
Чи можна використовувати реальні твердження у навчанні?
Використовуйте лише анонімні випадки та не розміщуйте інформацію про пацієнтів у жодному навчальному інструменті, окрім випадків, коли це схвалено вашим керівником з дотримання вимог.
З чого почати
Виберіть одну повторювану схему заперечення. Напишіть звіт про ефективність, попросіть керівника відділу доходів або інформатики перевірити деідентифікований випадок, перевірки та відповідального за виправлення, а також складіть трикритерійну рубрику зі шкалою від 0 до 2 та перелік критичних помилок. Випробуйте її з невеликою групою, перш ніж розгортати.
Щоб побачити, як справа про відмову може бути розгорнута в прямому ефірі з вашою власною командою та повторно використана у власному темпі згодом, ознайомтеся з AhaSlides.
