Claims – “Trái Tim” Của Hệ Thống Healthcare Insurance

Bài viết được chia sẻ từ chuyên gia Business Analyst trong lĩnh vực Healthcare

Vì sao Claims là module phức tạp nhất và quyết định toàn bộ hệ thống Healthcare Insurance?

Trong hệ thống Healthcare Insurance, Claims là module nơi quyết định có trả tiền hay không.
Mọi thành phần khác như Enrollment, Provider hay Benefits chỉ tạo điều kiện, còn Claims là nơi áp rule, kiểm tra điều kiện và xử lý dòng tiền thực tế.

Với nhiều Business Analyst, Claims cũng chính là phần gây choáng ngợp nhất khi mới bước vào Healthcare domain, tương tự cảm giác bỡ ngỡ ban đầu khi phải làm việc với quy trình y tế, thuật ngữ và logic nghiệp vụ hoàn toàn khác các domain khác. Chỉ một sai sót nhỏ trong Claims có thể dẫn đến mất tiền, khiếu nại hoặc rủi ro pháp lý, khiến module này trở thành trái tim vận hành của toàn bộ hệ thống bảo hiểm y tế.

Claims là gì và vì sao giữ vai trò trung tâm?

Claim là “yêu cầu hoàn trả chi phí y tế do Member hoặc Provider gửi lên”.

Claims là nơi:

• kiểm tra quyền lợi (Benefits)
• kiểm tra người được hưởng (Eligibility)
• kiểm tra nhà cung cấp dịch vụ (Provider)
• kiểm tra loại dịch vụ & chi phí
• đưa ra quyết định thanh toán theo đúng Policy

→ Đây là điểm giao cắt của mọi “pillar” trong Healthcare (Member – Provider – Benefits – Sales – External Agents).

Claims là trái tim của hệ thống bởi:

• 70–80% chi phí của một payer (công ty bảo hiểm) nằm ở claim payout
• Dữ liệu Claims được dùng cho actuarial, underwriting, sales, renewal
• Tốc độ xử lý Claims (Turnaround time – TAT) là chỉ số sống còn
• Sai sót trong Claims ⇒ kiện tụng, fraud, mất uy tín thị trường

Quy trình Claims end-to-end mà BA bắt buộc phải nắm

Claims bao gồm các bước:

Claim Intake – Nhận yêu cầu bồi hoàn 

Claims đến từ:

• Paper Claim (qua mail)
• Electronic Claim (qua clearinghouse)

Tại Intake, hệ thống kiểm tra:

• dữ liệu có đủ không?
• có lỗi syntax, logic, định dạng không?
• provider ID, member ID, service date có hợp lệ không?

Nếu lỗi → trả lại Provider/Member.

Claim Adjudication – Khâu “xét xử” quan trọng nhất

Tài liệu mô tả 3 bước chính:

Claim Preparation & Eligibility Check

Hệ thống xác thực:

• Member có active không?
• Có đúng PCP? Có referral không?
• Benefit có cover loại dịch vụ này không?
• Đã thỏa deductible, copay, coinsurance chưa?
• Provider có nằm trong network không?

→ Đây là phần BA phải mô tả rất chi tiết trong BRD/SRS.

Determine Payment – Tính toán số tiền bảo hiểm trả

Bao gồm:

• Allowed Amount
• Member Cost Share
• Insurance Payment Amount
• Logic thanh toán có thể đến từ:
• Fee schedule
• Capitation
• Contract của từng Provider
• DRG / RBRVS (tùy loại claim)

→ Đây là logic phức tạp nhất do liên quan đến “business rules engine”.

Update Claim – Finalization

Sau khi adjudicate xong, claim sẽ được:

• cập nhật trạng thái (Paid, Denied, Pending)
• ghi nhận accumulator (deductible, OOP max…)
• tạo output để gửi sang hệ thống Payment

Claim Payment

Có 2 hướng chính:

• Provider Payment – trả tiền thẳng cho Provider
• Member Reimbursement – nếu Member đã tự trả tiền

Tài liệu mô tả rõ việc gửi check và EOB (Explanation of Benefits) cho Member.

Claim Adjustments

Nếu claim bị sai hoặc cần chỉnh sửa, có các loại adjustment:

• Refund Adjustment
• Minus Debit
• Manual Check
• Void
• Stop Payment

→ BA phải hiểu rõ để xử lý các use case chỉnh claim.

BA cần phân tích gì trong một hệ thống Claims?

Khi làm BA bạn phải viết và phân tích các phần sau:

➤ A. Business Rules cho Claims

Bao gồm:

• Eligibility rules
• Referral rules
• Provider network rules
• Deductible, Copay, Coinsurance
• Benefit limits
• Accumulator cập nhật ra sao
• COB (Coordination of Benefits)

➤ B. Workflow & Use Cases

Use case thường có:

• Submit Claim
• Validate Claim
• Adjudicate Claim
• Calculate Payment
• Generate EOB
• Process Adjustments
• COB if necessary

➤ C. Data Mapping

BA phải mô tả:

• Claim Header
• Claim Line
• Provider Data
• Member Eligibility
• Accumulators
• Fee Schedule / Contract tables
• Claim adjudication requires information of almost all entities.

➤ D. Exception Handling

• Missing information
• Invalid member
• Provider not contracted
• Duplicate claims
• Suspicious claims (fraud check)

Vì sao Claims quyết định sống còn của hệ thống?

Có 4 lý do chính:

1. Claims kiểm soát dòng tiền lớn nhất

Chi phí healthcare chủ yếu phát sinh từ claim payout.

Không phân tích đúng → insurance mất tiền.

2. Claims ảnh hưởng trực tiếp đến Member Experience

TAT chậm → người dùng phàn nàn → rời bỏ.

EOB sai → khiếu nại, lawsuit.

3. Claims là nguồn dữ liệu cho actuarial & underwriting

Dữ liệu claims dùng để:

• định giá (rating)
• quản lý rủi ro
• thiết kế sản phẩm mới
• dự đoán chi phí

4. Claims là nơi chịu nhiều quy định pháp lý nhất

Bao gồm:

• HIPAA
• COB
• CMS guidelines
• Contract compliance

Sai ở Claims không chỉ là bug – mà là rủi ro pháp lý.

Claims không chỉ là module – đó là “bài test” của BA Healthcare Insurance

Trong thực tế, rất nhiều BA chỉ thực sự “vỡ ra” về Healthcare Insurance khi bắt đầu làm Claims.
Không còn là chuyện vẽ flow đẹp hay viết requirement đủ – mà là hiểu tiền đi đâu, dữ liệu đi thế nào và rủi ro nằm ở đâu.

Nếu bạn đang:

• Mới bước vào Healthcare BA
• Hoặc đang làm clinical system và muốn chuyển sang Insurance
• Hoặc từng nghe “Claims rất khó” nhưng chưa hình dung rõ

Thì việc hiểu module này sẽ là bước ngoặt nghề nghiệp.

Nếu bạn đang ở giai đoạn bắt đầu, có thể đọc thêm góc nhìn tổng quan dành cho BA mới vào ngành để hiểu bức tranh lớn trước khi đào sâu vào Claims.