Một nhóm phụ trách thanh toán của bệnh viện xử lý một lượng lớn các yêu cầu thanh toán bị từ chối. Mỗi yêu cầu đều được xử lý theo cùng một cách: ai đó sửa một trường thông tin, nhập lại dữ liệu và gửi lại. Một tuần sau, các yêu cầu thanh toán với cùng một kiểu lại xuất hiện. Không ai hỏi lý do tại sao chúng bị từ chối ngay từ đầu, vì vậy việc khắc phục không bao giờ đến được bước gây ra lỗi.
Đây là một tình huống minh họa, không phải là một trường hợp đã được ghi nhận. Nó mô tả khoảng cách mà việc đào tạo về nguyên nhân gốc rễ của việc từ chối yêu cầu bồi thường nhằm mục đích thu hẹp: khoảng cách giữa việc khắc phục yêu cầu bồi thường bị từ chối và việc tìm ra phần nào trong quy trình làm việc đã gây ra điều đó.
Hướng dẫn này dành cho các giám đốc đào tạo và phát triển (L&D) của bệnh viện và các trưởng bộ phận tin học hoặc tuân thủ làm việc cùng họ. Nó bao gồm cách mô tả vấn đề về hiệu suất, chẩn đoán các lỗ hổng về học tập và bối cảnh, thiết kế chuẩn bị và thực hành, phân tích một trường hợp cụ thể và đánh giá xem kỹ năng có được chuyển giao vào công việc thực tế hay không. Đây là về thiết kế đào tạo. Chỉ sử dụng các trường hợp đã được ẩn danh và yêu cầu các trưởng bộ phận doanh thu, tin học và tuân thủ của riêng bạn xác nhận mọi trường hợp, mã và câu trả lời trước khi bất kỳ ai được đào tạo về chúng.
Đào tạo về nguyên nhân gốc rễ của việc từ chối yêu cầu bồi thường là gì?
Khóa đào tạo về nguyên nhân gốc rễ của việc từ chối thanh toán hướng dẫn nhân viên hành chính điều tra các mô hình từ chối lặp đi lặp lại và xác định các nguyên nhân quy trình đằng sau chúng. Nhiệm vụ này mang tính phân tích. Nhân viên xem xét bằng chứng trên yêu cầu thanh toán và trong hồ sơ, phân biệt những gì bên thanh toán nói với những gì đã xảy ra sai sót bên trong tổ chức, và mô tả một nguyên nhân đủ cụ thể để ai đó có thể hành động dựa trên đó.
sự kiện nhanh chóng
| câu hỏi | Câu trả lời ngắn |
|---|---|
| Nhiệm vụ là gì? | Điều tra các mô hình từ chối lặp đi lặp lại và xác định nguyên nhân gây ra sự cố trong quy trình làm việc. |
| Bạn đạt được bao nhiêu điểm? | Xác định nguyên nhân chính xác và tỷ lệ tái diễn của kiểu phủ nhận đó. |
| Liệu một khóa học ôn tập lập trình có đủ không? | Không. Nó giúp xây dựng kiến thức về các quy tắc, nhưng không tạo thói quen tìm ra nguyên nhân của sự phủ nhận. |
| Ai là người xác nhận nội dung? | Một người phụ trách chu kỳ doanh thu, tin học hoặc tuân thủ quy định, sử dụng các trường hợp đã được ẩn danh. |
| Huấn luyện không thể giải quyết được vấn đề gì? | Những thay đổi trong chính sách của bên chi trả, giới hạn của hệ thống, vấn đề nhân sự và sự không rõ ràng trong việc xác định trách nhiệm của từng bước. |
| Làm sao bạn biết nó có tác dụng? | Một sự phủ nhận mới, chưa từng thấy, được chấm điểm dựa trên các tiêu chí đã thống nhất, kèm theo theo dõi về sự tái phát. |
1. Mô tả vấn đề về hiệu năng
Hãy bắt đầu với nhiệm vụ: điều tra các mô hình từ chối thanh toán lặp đi lặp lại và xác định nguyên nhân quy trình làm việc. Hai từ này mang trọng trách quan trọng. "Lặp đi lặp lại" có nghĩa là đơn vị công việc là một mô hình, chứ không phải là một yêu cầu thanh toán riêng lẻ. "Nguyên nhân quy trình làm việc" có nghĩa là câu trả lời nằm trong quy trình của chính tổ chức, chứ không phải trong khoản thanh toán của bên chi trả.
Hướng dẫn về tài chính y tế cũng nêu rõ điều tương tự. Trong một bài báo cho Hiệp hội Quản lý Tài chính Y tế (HFMA), Denise Wilson và Tracey Tomak mô tả ba lớp của việc từ chối thanh toán. Lý do là mã do bên thanh toán đưa ra, chẳng hạn như mã lý do điều chỉnh yêu cầu bồi thường (CARC). Vấn đề là danh mục rộng, chẳng hạn như mã hóa hoặc tài liệu. Nguyên nhân gốc rễ là lỗi nội bộ dẫn đến sự chênh lệch thanh toán. Họ lưu ý rằng việc xác định nguyên nhân gốc rễ đòi hỏi phải xem xét nội bộ hồ sơ y tế, phí và yêu cầu bồi thường đã lập hóa đơn, và dữ liệu phải phản ánh nguyên nhân gốc rễ thực tế chứ không chỉ là mã lý do trên các khoản thanh toán.Wilson và Tomak, HFMAHọ cũng nói rằng cần phải nêu rõ nguyên nhân gốc rễ để người đọc có thể hành động dựa trên nguyên nhân cụ thể đó.
Sự khác biệt đó chính là mục tiêu đào tạo. Việc nhập lại dữ liệu hoạt động ở lớp lý do. Phân tích nguyên nhân gốc rễ hoạt động ở lớp thứ ba.
Hãy viết bản mô tả hiệu suất thành một câu duy nhất và nhờ người phụ trách chu kỳ doanh thu kiểm tra: "Với một nhóm các yêu cầu thanh toán bị từ chối có liên quan, nhân viên xem xét yêu cầu và hồ sơ, phân biệt lý do của bên thanh toán với nguyên nhân nội bộ, nêu rõ nguyên nhân cụ thể và đề xuất biện pháp khắc phục cũng như người chịu trách nhiệm."
2. Chẩn đoán những thiếu sót về kiến thức và bối cảnh.
Trước khi bắt tay vào xây dựng bất cứ điều gì, hãy so sánh nhiệm vụ đó với những gì chương trình đào tạo hiện tại của bạn đang thực hành và đánh giá. Thông thường, ba câu hỏi sau sẽ giúp phân biệt lỗ hổng đào tạo với những vấn đề khác:
- Liệu phương pháp hiện tại có sử dụng đúng nhiệm vụ thực tế? Nếu khóa đào tạo dạy nhân viên cách đọc mã lý do và áp dụng cách sửa lỗi tiêu chuẩn, họ đã thực hành việc nhập lại dữ liệu. Nếu bài kiểm tra là một bài trắc nghiệm về định nghĩa mã, nó đo lường khả năng ghi nhớ, chứ không phải khả năng điều tra.
- Yêu cầu về khả năng nhận thức là gì? Trong thang phân loại Bloom sửa đổi, việc so sánh các lời phủ nhận để tìm ra quy luật và đánh giá nguyên nhân nào phù hợp nhất với bằng chứng nằm ở cấp độ phân tích và đánh giá. Tra cứu mã số nằm ở cấp độ thấp hơn. Việc đối chiếu các hoạt động với các cấp độ này được đề cập trong hướng dẫn của chúng tôi về... Phù hợp các hoạt động học tập với Phân loại Bloom..
- Liệu có điều gì khác ngoài kỹ năng đang cản trở bạn? Kiểm tra quyền truy cập, công cụ và quyền sở hữu. Nhân viên không thể xem màn hình đăng ký, không có cách nào để báo cáo lỗi cho lễ tân hoặc được đánh giá dựa trên số lượng yêu cầu được xử lý mỗi giờ sẽ nhập lại thông tin theo hướng dẫn đào tạo. Báo cáo các nguyên nhân không liên quan đến đào tạo cho người có thể khắc phục chúng.
3. Chuẩn bị và thực hành thiết kế
Khi bạn đã xác định được những thiếu sót nào mà đào tạo có thể khắc phục, hãy giao nhiệm vụ riêng biệt cho từng giai đoạn.
Sự chuẩn bị. Kiểm tra các điều kiện tiên quyết bằng một bài kiểm tra chẩn đoán ngắn: thuật ngữ từ chối, vòng đời yêu cầu bồi thường từ khi đăng ký đến khi thanh toán, và ý nghĩa của các trường mã lý do. Tự học theo tốc độ riêng phù hợp với giai đoạn này. Bài kiểm tra ôn tập chỉ xác nhận các điều kiện tiên quyết.
Thực hành. Sử dụng phương pháp kiểm tra tính toàn vẹn dữ liệu trên các trường hợp đã được ẩn danh. Trong quá trình kiểm tra, nhân viên sẽ xem xét một yêu cầu bồi thường bị từ chối, truy ngược lại lịch sử thông qua hồ sơ, các khoản phí và đăng ký, và ghi lại vị trí xảy ra lỗi. Nhiều nhân viên sẽ tìm thấy cùng một trường hợp theo nhiều cách khác nhau, vì vậy việc thảo luận chính là nơi diễn ra quá trình học hỏi. Hãy yêu cầu lý do, chứ không chỉ là một nhãn mác.
Phản hồi. Hãy liên hệ nó với các quyết định thay vì chỉ là tổng điểm. Câu nói "Bạn đã xác định được sự thiếu sót trong giấy phép, đó là một nguyên nhân thực sự, nhưng bạn chưa kiểm tra xem nó bị thiếu hay được nhập sai vào lần thăm khám nào" sẽ dạy bạn nhiều hơn là chỉ đạt "7/10".
Nhập liệu trực tiếp hay xem xét không đồng bộ? Huấn luyện trực tiếp mang lại giá trị cao nhất khi trường hợp không rõ ràng và nhân viên cần nghe một đồng nghiệp giàu kinh nghiệm phân biệt chính sách của bên thanh toán với lỗi nhập liệu. Đánh giá không đồng bộ là đủ để so sánh bản tường trình nguyên nhân bằng văn bản của một người với câu trả lời mẫu có chú thích. Nhiều nhóm sử dụng cả hai: chuẩn bị theo tốc độ cá nhân trước, sau đó là một buổi huấn luyện có người hướng dẫn đối với những trường hợp khó nhất.
4. Hãy cùng nhau tìm hiểu một ví dụ thực tế.
Hình ảnh minh họa và đã được ẩn danh. Người phụ trách chu kỳ doanh thu hoặc tin học cần xác nhận trường hợp và tiêu chí trả lời trước khi sử dụng.
Trường hợp. Trong hơn một tháng, mười một yêu cầu thanh toán ngoại trú cho cùng một dịch vụ đã bị từ chối với cùng một lý do từ phía người trả tiền. Mỗi yêu cầu đều được sửa chữa và gửi lại bằng cách nhập lại cùng một trường thông tin. Ba trong số mười một yêu cầu đó lại bị từ chối lần nữa.
Nhiệm vụ. Nhân viên sẽ xem xét các yêu cầu bồi thường và hồ sơ, phân biệt lý do do bên chi trả đưa ra với nguyên nhân nội bộ, nêu rõ nguyên nhân cụ thể và cho biết họ cần thêm thông tin hoặc bằng chứng hỗ trợ nào.
Lần thử đầu tiên. "Bên thanh toán cho biết thông tin không chính xác. Tôi đã sửa lại trường thông tin và gửi lại." Câu này chỉ lặp lại lý do và áp dụng cách khắc phục thông thường. Nó không tìm kiếm quy luật hay nguyên nhân.
Phản hồi và thử lại. Huấn luyện viên chỉ ra hai sự thật trong trường hợp này: cả mười một yêu cầu đều dùng chung một dịch vụ và địa điểm đăng ký, và ba yêu cầu bị trả lại là do các nhân viên khác nhau xử lý. Yêu cầu thử lại đề nghị người đó xem lại vị trí nhập liệu lần đầu và liệu cùng một bước có tạo ra cả mười một yêu cầu hay không.
Một nỗ lực mạnh mẽ hơn. "Cả mười một yêu cầu thanh toán đều được đăng ký tại cùng một địa điểm, vì vậy tôi nghĩ lỗi xảy ra ở khâu đăng ký chứ không phải ở khâu lập hóa đơn. Tôi sẽ xem lại các mục đăng ký cho những yêu cầu đó và kiểm tra xem trường dữ liệu có được điền bằng giá trị mặc định hay không. Nếu vậy, việc nhập lại dữ liệu ở khâu lập hóa đơn sẽ tiếp tục thất bại. Tôi sẽ không coi đây là vấn đề chính sách của bên thanh toán cho đến khi tôi kiểm tra xem quy tắc của bên thanh toán có thay đổi hay không. Tôi sẽ chia sẻ phát hiện này với người phụ trách đăng ký và hỏi xem ai là người chịu trách nhiệm về trường dữ liệu đó." Câu trả lời này nêu ra một mẫu lỗi, một vị trí cụ thể gây ra lỗi, một bước kiểm tra để xác nhận hoặc loại trừ lỗi đó và người cần phải hành động.
Tại sao mỗi câu trả lời lại có thể chấp nhận được hoặc chưa đầy đủ. Đánh giá từng trường hợp dựa trên các tiêu chí đã được phê duyệt, chứ không phải dựa trên sở thích của người hướng dẫn. Lần thử đầu tiên là một thói quen phổ biến nhưng chỉ dừng lại ở mức độ lý giải. Lần thử tiếp theo sẽ tách biệt chính sách của bên chi trả khỏi việc nhập dữ liệu và bám sát vai trò của người thực hiện.
5. Đánh giá năng lực và lập kế hoạch chuyển giao
Bằng chứng về năng lực là phản hồi đối với một mô hình phủ nhận mà người học chưa từng gặp phải. Chấm điểm dựa trên việc xác định nguyên nhân chính xác, và theo thời gian, tỷ lệ tái diễn của mô hình mà họ đã điều tra. Một bảng tiêu chí đơn giản sử dụng thang điểm từ 0 đến 2 cho mỗi tiêu chí:
| Tiêu chí | Bằng chứng có thể quan sát được |
|---|---|
| Thực thi nhiệm vụ | Điều tra mô hình phủ nhận và ghi lại bằng chứng đằng sau nguyên nhân được nêu ra. |
| lý luận | Giải thích các hạn chế, phương án thay thế và những điều vẫn còn chưa chắc chắn. |
| Ranh giới | Sử dụng các quy trình đã được phê duyệt và tìm kiếm sự trợ giúp khi thông tin hoặc thẩm quyền không đầy đủ. |
Thang điểm: 0 là không có hoặc không được hỗ trợ, 1 là một phần với những thiếu sót liên quan, và 2 là đầy đủ và được chứng minh dựa trên các tiêu chí đã thống nhất. Xác định riêng các lỗi nghiêm trọng, chẳng hạn như xử lý thông tin bệnh nhân có thể nhận dạng được bên ngoài các hệ thống đã được phê duyệt, để điểm tổng thể không che giấu được lỗi nào. Bảng đánh giá này chỉ là một đề xuất, không phải là tiêu chuẩn sẵn sàng đã được xác nhận: hãy điều chỉnh nó với người phụ trách tin học hoặc tuân thủ và tiến hành thử nghiệm. Hướng dẫn của chúng tôi về... Thiết kế bài tập tương tác với phản hồi hữu ích Hướng dẫn cách viết phản hồi liên quan đến các quyết định.
Lên kế hoạch chuyển giao một cách có chủ đích. Thêm bước theo dõi sau khi nhân viên đã xử lý xong hàng đợi của họ một thời gian, chẳng hạn như đánh giá hàng tháng, trong đó mỗi người trình bày một trường hợp từ chối mà họ đã điều tra và kết quả sau khi khắc phục.
Trong trường hợp phương thức giao hàng tương tác giúp ích
Các định dạng tương tác rất hữu ích khi mọi người cần cam kết trước khi nghe câu trả lời. Trong một phiên trực tiếp, người điều phối có thể hiển thị bản tóm tắt từ chối đã được ẩn danh, yêu cầu mỗi người nhập nguyên nhân có khả năng xảy ra và hồ sơ đầu tiên họ sẽ kiểm tra, sau đó hiển thị bảng so sánh trước khi thảo luận. Trường hợp tương tự có thể được thực hiện theo hình thức tự học để chuẩn bị. AhaSlides hỗ trợ học tập tương tác và chuyển đổi giữa hình thức trực tiếp và tự học. Hãy loại bỏ bất kỳ dữ liệu bệnh nhân thực nào, kiểm tra bất kỳ chức năng soạn thảo, phản hồi hoặc báo cáo cụ thể nào bạn dự định sử dụng so với quy trình làm việc của riêng bạn, và coi AI, trình mô phỏng và tích hợp hệ thống là bên ngoài hoặc chưa được xác nhận cho đến khi bạn thấy chúng hoạt động. Để được hướng dẫn về việc lựa chọn định dạng, hãy xem bài viết của chúng tôi về Khi nào nên sử dụng phương pháp học tập thích ứng, tương tác và trực tiếp?.
Đo lường những gì đã thay đổi
Hãy quyết định trước những tiêu chí nào sẽ chứng minh nhân viên có thể hoàn thành nhiệm vụ. So sánh việc xác định nguyên nhân chính xác trên một mẫu từ chối chưa từng thấy với một mẫu cơ sở, và theo dõi tỷ lệ tái diễn của các mẫu đã được điều tra. Xác định đối tượng được bao gồm, mẫu số và thời điểm. Nếu kết quả được cải thiện, hãy kiểm tra những thay đổi khác trong cùng kỳ, chẳng hạn như cập nhật chính sách của bên thanh toán, màn hình đăng ký mới hoặc thay đổi về số lượng yêu cầu bồi thường, trước khi ghi nhận hiệu quả của khóa đào tạo.
Những ràng buộc có thể vẫn còn
- Chính sách của bên thanh toán. Một số trường hợp từ chối thanh toán là do thay đổi quy định của bên chi trả. Việc điều tra kỹ lưỡng sẽ xác định được điều này, nhưng đào tạo không thể thay đổi thực tế.
- Giới hạn hệ thống. Nếu hệ thống không thể hiển thị vị trí nhập liệu, nhân viên sẽ khó có cơ sở để theo dõi.
- Quyền sở hữu. Một nguyên nhân được phát hiện trong quá trình đăng ký cần có người trong bộ phận đăng ký chịu trách nhiệm khắc phục.
- Phạm vi bao phủ vụ việc. Một kiểu phủ nhận thể hiện một kiểu hành vi nhất định. Điểm số không phản ánh khả năng phán đoán tổng quát của một người.
- Chuyển khoản. Hiệu năng khi xử lý trường hợp huấn luyện không giống với hiệu năng khi xử lý hàng đợi đầy đủ.
Hãy nêu rõ những vấn đề này với nhà tài trợ từ sớm và lên kế hoạch khắc phục riêng biệt. Việc đào tạo giúp cải thiện khả năng điều tra của nhân viên. Nó không thay đổi điều kiện xung quanh hàng đợi.
Các câu hỏi thường gặp
Đào tạo về nguyên nhân gốc rễ của việc từ chối yêu cầu bồi thường là gì?
Nó hướng dẫn nhân viên hành chính điều tra các trường hợp từ chối yêu cầu bồi thường lặp đi lặp lại và truy tìm nguyên nhân dẫn đến bước quy trình gây ra lỗi, thay vì sửa chữa và gửi lại từng yêu cầu bồi thường.
Nguyên nhân gốc rễ khác với lý do phủ nhận như thế nào?
Lý do là mã số do bên thanh toán đưa ra. Nguyên nhân gốc rễ là lỗi nội bộ đằng sau đó. Một yêu cầu thanh toán bị từ chối có thể có cùng mã số nhưng lại có nhiều nguyên nhân gốc rễ khác nhau.
Làm thế nào để đánh giá xem nhân viên có thể tìm ra nguyên nhân gốc rễ hay không?
Đưa ra một dạng phủ nhận mà người học chưa từng thấy và chấm điểm nguyên nhân họ nêu ra cùng bằng chứng chứng minh dựa trên các tiêu chí đã thống nhất. Bài kiểm tra mã chỉ nhằm xác nhận các điều kiện tiên quyết.
Có thể sử dụng các vụ kiện thực tế trong quá trình đào tạo không?
Chỉ sử dụng các trường hợp đã được ẩn danh và không đưa thông tin bệnh nhân vào bất kỳ công cụ đào tạo nào trừ khi người phụ trách tuân thủ của bạn đã phê duyệt.
Bắt đầu từ đâu
Chọn một mẫu từ chối thanh toán lặp đi lặp lại. Viết báo cáo hiệu suất, nhờ người phụ trách chu kỳ doanh thu hoặc người phụ trách công nghệ thông tin xác nhận trường hợp đã được ẩn danh, các bước kiểm tra và người chịu trách nhiệm khắc phục, đồng thời soạn thảo một bảng đánh giá ba tiêu chí với thang điểm từ 0 đến 2 và danh sách các lỗi nghiêm trọng. Thử nghiệm với một nhóm nhỏ trước khi triển khai rộng rãi.
Để xem cách bạn có thể thực hiện một trường hợp phủ nhận trực tiếp với nhóm của mình và tái sử dụng sau đó theo tốc độ riêng, hãy khám phá AhaSlides.
