Agentic AI trong revenue cycle: claim bị từ chối, khiếu nại

Agentic AI trong quản lý chu trình doanh thu (RCM) hiệu quả nhất ở khâu claim bị từ chối: đọc remittance 835 và mã từ chối, gom bằng chứng, soạn claim đã sửa hoặc thư khiếu nại, rồi đưa vào hàng đợi cho người duyệt. Năm 2025, 41% nhà cung cấp báo tỉ lệ từ chối từ 10% trở lên, và 90% claim bị từ chối vẫn được người xem lại trước khi gửi lại. Hãy giữ nguyên như vậy.

Revenue cycle là nơi AI agent trong y tế Mỹ đang được mua nhanh nhất năm 2026, vì công việc khối lượng lớn, nặng quy tắc và đo bằng tiền. Đây cũng là nơi agent thất bại theo những cách đắt đỏ: lập luận khiếu nại sai, một lần gửi lại kích hoạt lỗi trùng claim, hay một script portal payer âm thầm ngừng chạy. Bài này đi qua số liệu, kiến trúc tham chiếu, các kiểu lỗi chúng tôi thiết kế để chặn, và áp lực quy định từ phía payer.

Vấn đề claim bị từ chối lớn đến đâu năm 2026?

Lớn và không giảm. Khảo sát năm 2025 của Experian Health cho thấy 41% nhà cung cấp có tỉ lệ từ chối từ 10% trở lên, tỉ lệ này tăng mỗi năm kể từ 2022. KFF ghi nhận các công ty bảo hiểm trên HealthCare.gov từ chối 19% claim trong mạng lưới năm 2024, và chưa tới 1% số claim bị từ chối được khiếu nại.

Theo thông cáo Experian Health State of Claims 2025 (250 người phụ trách quyết định tài chính, billing hoặc claim):

• Nguyên nhân từ chối hàng đầu: dữ liệu thiếu hoặc sai (50%), authorization (35%), và thông tin đăng ký bệnh nhân thiếu hoặc sai (32%).
• 90% claim bị từ chối được xử lý lại với ít nhất một phần do người xem trước khi gửi lại.
• 67% tin AI có thể cải thiện claim, nhưng chỉ 14% đang dùng. Rào cản được nêu gồm độ chính xác chưa được chứng minh, tuân thủ HIPAA chưa được chứng minh, và nghi ngờ AI xử lý được quy tắc riêng của từng payer.

Theo phân tích tháng 3/2026 của KFF trên dữ liệu Marketplace 2024: tỉ lệ từ chối trong mạng lưới dao động 3% đến 36% giữa các công ty bảo hiểm, từ chối ngoài mạng lưới là 37%, và bảo hiểm giữ nguyên quyết định ở 66% số khiếu nại được nộp. Lý do được ghi nghiêng về hành chính: 25% hành chính, 13% dịch vụ bị loại trừ, 9% thiếu prior authorization hoặc giấy giới thiệu, 5% tính cần thiết y khoa, và 36% "khác".

Gộp lại, dữ liệu cho thấy phần lớn claim bị từ chối là vấn đề dữ liệu và quy trình, không phải tranh chấp lâm sàng. Đó chính là loại việc agent chuẩn bị tốt, nếu có đúng dữ liệu và có người ký duyệt.

Một hệ thống agentic AI xử lý claim bị từ chối thực sự làm gì?

Nó biến mỗi claim bị từ chối thành một case đã xử lý: phân loại lý do, kéo claim, remittance, bệnh án và bằng chứng authorization, xác định cách sửa khả thi (sửa và gửi lại, khiếu nại, hay xóa nợ), soạn đầu ra, và chuyển cho đúng người kèm bằng chứng. Người duyệt trước khi bất cứ thứ gì đi đến payer.

Thứ tự quan trọng. Bắt đầu từ các loại hành chính, nơi bằng chứng có cấu trúc và cách sửa kiểm tra được. Để khiếu nại về tính cần thiết y khoa cho sau, khi bạn đã đo được độ chính xác ở các loại dễ hơn.

Kiến trúc tham chiếu cho một RCM agent là gì?

Năm lớp: thu nhận 835 và danh sách claim bị từ chối, một case store ghép dữ liệu claim, remittance, bệnh án và authorization, một orchestrator cho agent với công cụ hẹp, một hàng đợi duyệt của con người, và gửi đi qua clearinghouse hoặc API của payer. Model không bao giờ nói chuyện trực tiếp với payer.

1. Thu nhận

Parse remittance X12 835 và chuẩn hóa mã CARC, RARC thành các nhóm của riêng bạn. Kéo danh sách claim bị từ chối từ hệ thống quản lý phòng khám hoặc EHR. Lớp này là phần mềm thông thường và phải deterministic.

2. Case store

Mỗi claim bị từ chối là một bản ghi, nối claim 837 gốc, dòng 835, bản ghi authorization và các tài liệu lâm sàng liên quan. Phần lớn lỗi agent chúng tôi gặp đều truy về một case thiếu một trong những thứ này.

3. Orchestrator và công cụ

Agent nhận các công cụ hẹp, chủ yếu là đọc: "lấy các dòng claim", "lấy remittance của claim", "tìm ghi chú theo ngày khám", "kiểm tra eligibility", "tìm authorization". Công cụ ghi chỉ tạo bản nháp. Quy tắc riêng của payer (hạn nộp, cấp khiếu nại, biểu mẫu bắt buộc) nằm trong cấu hình có version, không nằm trong prompt.

4. Hàng đợi duyệt

Mỗi bản nháp hiển thị lý do từ chối, hành động đề xuất, bằng chứng kèm link về tài liệu gốc, và nhãn độ tin cậy. Người duyệt chấp nhận, sửa hoặc từ chối, và mọi quyết định được ghi log. Các lần bị từ chối trở thành dữ liệu đánh giá.

5. Gửi đi

Claim đã sửa được duyệt đi ra dưới dạng 837 qua clearinghouse. Khiếu nại đi qua portal hoặc API của payer. Khi các payer đưa Prior Authorization API vào hoạt động theo CMS-0057-F, bước authorization sẽ gọn hơn; xem hướng dẫn về hạn chót Prior Authorization API của CMS năm 2027.

RCM agent hay hỏng ở đâu?

Hỏng ở thiếu ngữ cảnh, quy tắc payer thay đổi, tự động hóa portal, và độ chính xác không được đo. Không cái nào là vấn đề model mà prompt sửa được; đó là vấn đề dữ liệu, tích hợp và đánh giá.

• Thiếu ngữ cảnh. Agent soạn khiếu nại mà thiếu ghi chú phẫu thuật vì tài liệu được scan và chưa bao giờ được đánh chỉ mục. Bản nháp đọc rất ổn và sai. Cách sửa: case chưa "sẵn sàng" cho đến khi có đủ tài liệu bắt buộc.
• Quy tắc payer thay đổi. Hạn khiếu nại, biểu mẫu và chính sách thay đổi. Nếu quy tắc nằm trong prompt, không ai để ý. Giữ chúng trong cấu hình có version và có người phụ trách.
• Gửi trùng. Claim gửi lại mà thiếu frequency code đúng hoặc tham chiếu claim gốc sẽ bị từ chối vì trùng. Làm việc gửi đi idempotent và kiểm tra lịch sử claim trước.
• Tự động hóa portal. Script portal payer bằng mật khẩu lưu sẵn sẽ hỏng mỗi lần giao diện đổi và thường xung đột với điều khoản portal. Ưu tiên đường clearinghouse và API; để portal cho người khi không có API.
• Trích dẫn bịa. Một thư khiếu nại trích một mục chính sách không tồn tại làm mất uy tín với payer đó. Yêu cầu mọi trích dẫn phải trỏ về một tài liệu nguồn đã lưu.
• Không có baseline. Không có tỉ lệ lật quyết định và tỉ lệ chấp nhận lần đầu từ trước khi có agent, bạn không biết agent có giúp hay không.

Mô hình chung được bàn trong vì sao dự án AI agent thất bại, và cách đo trong kiểm thử LLM cho ngành tuân thủ.

Nên đo một RCM agent như thế nào?

Đo kết quả theo từng loại từ chối so với baseline trước khi có agent: tỉ lệ lật quyết định khi khiếu nại, tỉ lệ claim đã sửa được chấp nhận lần đầu, số ngày từ lúc bị từ chối đến lúc gửi lại, tỉ lệ người duyệt phải sửa, và số tiền thu hồi sau khi trừ xóa nợ. Độ chính xác của bản nháp chỉ có ý nghĩa khi nó làm các con số đó dịch chuyển.

• Tỉ lệ người duyệt phải sửa theo từng loại cho biết agent đã sẵn sàng giảm giám sát ở đâu và chưa ở đâu.
• Lý do bị từ chối từ người duyệt cần được phân loại và đưa lại vào bộ đánh giá.
• Phân tích theo payer bắt sớm thay đổi quy tắc: tỉ lệ lật quyết định ở một payer đột ngột giảm thường có nghĩa là chính sách vừa đổi.
• Chi phí cho mỗi claim được xử lý, gồm chi phí model và hạ tầng, so với số tiền liên quan. Claim số tiền nhỏ có thể không đáng để khiếu nại. Xem chi phí vận hành một sản phẩm AI.

Tranh cãi về AI phía payer là gì?

Payer dùng thuật toán để xét duyệt và từ chối chăm sóc, và cơ quan quản lý đang phản ứng. Một cuộc điều tra của Thượng viện năm 2024 cho thấy tỉ lệ từ chối prior authorization cho chăm sóc sau cấp tính của UnitedHealthcare tăng từ 10.9% năm 2020 lên 22.7% năm 2022, và ghi nhận công việc nội bộ về machine learning gắn với các case đó. California hiện yêu cầu chuyên gia lâm sàng có giấy phép ra quyết định về tính cần thiết y khoa.

Báo cáo của Tiểu ban Điều tra Thường trực Thượng viện (10/2024) tập trung vào UnitedHealthcare, Humana và CVS; UnitedHealthcare phản đối cách mô tả này. Luật SB 1120 của California, có hiệu lực từ tháng 1/2025, yêu cầu quyết định về tính cần thiết y khoa của các gói bảo hiểm phải do bác sĩ có giấy phép hoặc chuyên gia y tế đủ chuyên môn đưa ra, không chỉ do thuật toán. Ở cấp liên bang, mô hình WISeR của CMS, dùng AI hỗ trợ xét duyệt prior authorization trong Original Medicare ở sáu bang từ 2026, nêu rõ chuyên gia lâm sàng có giấy phép quyết định các khuyến nghị không chi trả.

Với đội RCM phía nhà cung cấp, điều này có hai mặt. AI phía payer có thể làm tăng số claim bị từ chối, khiến việc xử lý nhanh càng có giá trị. Và cơ quan quản lý đang phát tín hiệu cùng một chuẩn cho tất cả: một người đủ chuyên môn chịu trách nhiệm cho quyết định có hệ quả. Hãy xây agent theo chuẩn đó ngay từ bây giờ.

Nên tự xây RCM agent hay mua?

Mua nếu vendor đã bao phủ các payer, chuyên khoa và hệ thống quản lý của bạn với kết quả đo được, và chịu ký BAA. Tự xây, hoặc mở rộng một nền tảng đã mua, khi cơ cấu payer của bạn đặc thù, dữ liệu nằm rải rác ở những hệ thống vendor không kết nối được, hoặc bạn cần agent nằm trong công cụ làm việc và audit trail của chính mình.

Câu hỏi nên đặt cho bất kỳ vendor nào: Loại từ chối nào được tự động hóa trọn vẹn, loại nào chỉ soạn nháp? Tỉ lệ người duyệt phải sửa theo từng loại ở khách hàng giống chúng tôi là bao nhiêu? PHI đi đâu, những subprocessor nào nằm trong BAA? Chúng tôi có xuất được mọi quyết định và bằng chứng không? Bài chi phí xây dựng AI agent đi qua phía tự xây của phép so sánh.

BeevR làm việc này thế nào

Chúng tôi xây RCM agent theo mô hình case: thu nhận 835 và danh sách claim một cách deterministic, case store ghép claim, remittance, authorization và bằng chứng bệnh án, agent với công cụ hẹp chỉ tạo bản nháp, và hàng đợi duyệt nơi đội billing, coder và bác sĩ của bạn duyệt mọi hành động gửi ra ngoài. Quy tắc payer nằm trong cấu hình có version và người phụ trách. Mọi bản nháp, chỉnh sửa và lần duyệt đều được ghi log. BeevR ký BAA với vai trò business associate, và model có thể chạy trong tài khoản AWS của bạn dưới AWS BAA, chỉ nhận PHI ở mức tối thiểu cần thiết.

Chúng tôi là đội senior do founder dẫn dắt tại Hà Nội, 5.0 trên Clutch, làm theo từng giai đoạn giá cố định từ $10K mỗi giai đoạn, demo chạy được mỗi thứ Sáu và bạn sở hữu toàn bộ IP từ ngày đầu. Đọc thêm về phát triển AI agent cho y tế, hoặc đặt lịch gọi 30 phút để cùng xem dữ liệu claim bị từ chối của bạn.