Mở đầu — vì sao bài này quan trọng
Đây là Capstone cuối cùng của khóa học, và mình cố tình để bài toán Insurtech ở vị trí khó nhất. Vì sao? Bảo hiểm sức khỏe là một trong những lĩnh vực có quy trình nghiệp vụ phức tạp bậc nhất mà một BA Việt Nam sẽ gặp: nó vừa có giấy tờ y tế chằng chịt, vừa có rủi ro gian lận (fraud) cao, vừa bị siết bởi quy định pháp lý của Bộ Tài chính và Luật Kinh doanh bảo hiểm, lại vừa đòi hỏi trải nghiệm người dùng phải nhanh và mượt để cạnh tranh.
Hãy hình dung trải nghiệm của một khách hàng hôm nay: con bị sốt xuất huyết, nằm viện 4 ngày, hóa đơn 18 triệu. Họ photo công chứng toàn bộ hồ sơ bệnh án, hóa đơn đỏ, đơn thuốc, rồi gửi bưu điện hoặc mang lên văn phòng công ty bảo hiểm. Sau đó chờ 15-30 ngày để được "xét bồi thường". Nếu thiếu một tờ giấy, họ phải bổ sung và đếm lại từ đầu. Đây chính là "nỗi đau" (pain point) mà các công ty như Bảo Việt, Manulife Việt Nam, FWD, Prudential, hay startup như Papaya, Global Care đang muốn xóa bỏ bằng digital health claim — bồi thường bảo hiểm sức khỏe số hóa: chụp ảnh hồ sơ bằng điện thoại, hệ thống tự đọc dữ liệu, tự kiểm tra điều khoản, và chi trả tự động trong vài giờ.
Bài này không dạy bạn một khái niệm mới — nó bắt bạn tổng hợp toàn bộ kỹ năng đã học (BABOK, BPMN, NFR, SQL, API, NFR bảo mật, stakeholder) vào một dự án thật. Mục tiêu: bạn rời khóa học với một bộ artefact đủ để đưa vào portfolio và nói chuyện được với hội đồng phỏng vấn CBAP.
Khái niệm cốt lõi
Vòng đời một claim bảo hiểm sức khỏe
Trước khi số hóa, BA phải hiểu nghiệp vụ gốc. Một claim đi qua các trạm: FNOL (First Notice of Loss — khách báo có sự kiện y tế) → thu thập chứng từ → adjudication (thẩm định: đối chiếu quyền lợi với hợp đồng) → quyết định (approve/reject/partial) → payout (chi trả). Số hóa nghĩa là rút ngắn và tự động hóa từng trạm, chứ không bỏ trạm nào.
Hai khái niệm kỹ thuật mới mà BA Insurtech bắt buộc nắm
OCR + IDP (Intelligent Document Processing): Khách chụp ảnh hóa đơn, đơn thuốc, giấy ra viện. Hệ thống dùng OCR để bóc chữ, rồi IDP/ML để hiểu đây là trường nào — tên bệnh nhân, mã ICD-10 (mã chuẩn quốc tế phân loại bệnh), tổng tiền, ngày nhập–xuất viện. BA không code OCR, nhưng phải định nghĩa: trường nào bắt buộc bóc tách, ngưỡng độ tin cậy (confidence) bao nhiêu thì máy tự duyệt, dưới ngưỡng thì đẩy sang người.
STP (Straight-Through Processing): Tỷ lệ claim được xử lý tự động từ đầu đến cuối, không cần con người chạm vào. Đây là KPI sống còn của dự án. Một claim đơn giản (khám ngoại trú 500k) nên STP 100%; một claim phức tạp (phẫu thuật 200 triệu) thì cần thẩm định viên. BA phải thiết kế business rule quyết định cái nào đi STP, cái nào route sang người.
Auto-adjudication rules — trái tim của hệ thống
Đây là phần đậm chất BA nhất. Bạn phải dịch điều khoản hợp đồng (policy) thành các rule máy chạy được. Ví dụ:
- Quyền lợi nội trú: tối đa 20 triệu/ngày phòng, 100 triệu/năm.
- Waiting period: bệnh có sẵn (pre-existing) không chi trả trong 12 tháng đầu.
- Loại trừ (exclusion): tai nạn do say rượu, thẩm mỹ, nha khoa thông thường.
- Co-payment: khách tự trả 20% nếu khám ngoài bệnh viện liên kết.
Fraud detection — vì sao Insurtech khác mọi domain khác
Gian lận bảo hiểm y tế ở Việt Nam là vấn đề thật: hóa đơn khống, "nhân bản" một hồ sơ cho nhiều hợp đồng, kê khai bệnh có sẵn thành bệnh mới. BA phải định nghĩa các red flag: cùng một hóa đơn dùng cho 2 claim, số tiền lẻ bất thường, claim ngay sau khi vừa mua hợp đồng, tần suất claim cao bất thường. Những claim trúng red flag bị route sang đội điều tra (SIU — Special Investigation Unit) thay vì auto-pay.
Tình huống thực tế
Ví dụ 1 — FWD Việt Nam và bài toán "claim trong 30 phút"
FWD định vị thương hiệu trẻ với cam kết bồi thường nhanh. Giả sử bạn là BA cho dự án "Express Claim": mục tiêu xử lý 70% claim ngoại trú dưới 500.000đ trong vòng 30 phút.
Khi phân tích, nhóm BA phát hiện nút thắt không nằm ở công nghệ mà ở chính sách: phòng pháp chế yêu cầu mọi claim đều phải có người duyệt. BA đã làm một việc rất "BABOK": chạy Solution Evaluation trên dữ liệu lịch sử 50.000 claim, chứng minh rằng claim dưới 500k có tỷ lệ gian lận chỉ 0,3% và giá trị tổn thất kỳ vọng nếu auto-pay sai còn thấp hơn chi phí nhân công duyệt tay. Con số này thuyết phục pháp chế nới rule: dưới 500k + đúng bệnh viện liên kết + OCR confidence > 95% → auto-pay.
Bài học: BA không bán công nghệ, BA bán bằng chứng định lượng. Khi stakeholder bảo "không được, rủi ro", bạn phản biện bằng dữ liệu chứ không bằng cảm tính. Đây là sự khác biệt giữa BA junior và BA senior.
Ví dụ 2 — Startup Papaya / Global Care và tích hợp bệnh viện
Một startup Insurtech VN xây sản phẩm bảo hiểm sức khỏe nhóm cho nhân viên doanh nghiệp. Họ muốn "cashless" — nhân viên khám xong không phải ứng tiền, hệ thống thanh toán trực tiếp với bệnh viện.
BA ở đây phải xử lý bài toán tích hợp: kết nối API với hệ thống HIS (Hospital Information System) của các bệnh viện như Vinmec, FV. Nhưng thực tế phũ phàng — nhiều bệnh viện công ở VN chưa có API, dữ liệu còn trên giấy. BA buộc phải thiết kế hai luồng song song: luồng cashless (real-time API) cho bệnh viện có hệ thống số, và luồng reimbursement (chụp hóa đơn, bồi hoàn sau) cho phần còn lại. Đồng thời phải định nghĩa reconciliation — đối soát công nợ định kỳ giữa công ty bảo hiểm và bệnh viện, vì tiền chảy hàng ngày.
Bài học: BA giỏi luôn thiết kế cho thực tế "vận hành hỗn hợp", không mơ một thế giới nơi mọi thứ đã số hóa. Phải có fallback path cho trường hợp tích hợp chưa sẵn sàng.
Ví dụ 3 — Bảo Việt và sự cố OCR đọc sai mã ICD-10
Giả định một dự án tại Bảo Việt: sau khi ra mắt, đội vận hành báo tỷ lệ khiếu nại tăng. Điều tra ra: OCR đọc nhầm chữ viết tay của bác sĩ — mã bệnh "J18" (viêm phổi, được chi trả) bị đọc thành "I18", và hệ thống tự từ chối vì I18 nằm trong nhóm loại trừ. Khách bị reject oan.
BA đã bổ sung một rule an toàn: nếu OCR đọc ra mã bệnh thuộc nhóm exclusion nhưng confidence < 90%, không được auto-reject — phải route sang người. Nguyên tắc thiết kế: máy được phép tự đồng ý, nhưng quyết định từ chối phải thận trọng hơn vì hậu quả trải nghiệm và pháp lý nặng hơn.
Bài học: Trong domain nhạy cảm, rule auto-approve và auto-reject phải bất đối xứng. Sai sót khi từ chối gây tổn hại danh tiếng lớn hơn nhiều so với chi nhầm một khoản nhỏ.
Hướng dẫn từng bước
Đây là cách triển khai Capstone này như một dự án thật. Hãy làm theo và tạo ra artefact ở mỗi bước.
Bước 1 — Strategy Analysis & xác định scope. Viết một Business Case ngắn: vấn đề (claim chậm 15-30 ngày), mục tiêu đo được (giảm thời gian xử lý xuống < 4 giờ cho claim đơn giản, đạt STP 60%), và đối tượng (gói bảo hiểm sức khỏe cá nhân). Vẽ context diagram để cố định ranh giới hệ thống.
Bước 2 — Stakeholder Analysis. Lập danh sách và xếp lên Power/Interest Grid: Claims Manager (quyết định nghiệp vụ), pháp chế/compliance, đội SIU chống gian lận, IT bệnh viện đối tác, đội CSKH, và quan trọng nhất — khách hàng cuối. Mỗi nhóm có "nỗi sợ" riêng; pháp chế sợ chi sai, vận hành sợ tồn đọng, khách sợ chờ lâu.
Bước 3 — Mô hình hóa quy trình bằng BPMN 2.0. Vẽ luồng end-to-end với swimlane: Khách → Mobile App → OCR/IDP Engine → Rule Engine → (gateway: STP hay Manual?) → Thẩm định viên → Payout. Dùng đúng gateway, message event khi gọi API bệnh viện, và một nhánh ngoại lệ cho red flag fraud.
Bước 4 — Viết Auto-adjudication Decision Table. Lập bảng quyết định: cột điều kiện (số tiền, loại điều trị, bệnh viện liên kết, waiting period, confidence OCR) → cột hành động (auto-approve / partial / route manual / route SIU). Đây là artefact giá trị nhất của bạn.
Bước 5 — Đặc tả requirement. Viết User Stories cho hành trình khách (chụp hồ sơ, theo dõi trạng thái claim, nhận thông báo) kèm acceptance criteria. Viết Functional Requirement cho rule engine và OCR.
Bước 6 — Non-Functional Requirements. Bắt buộc có: bảo mật dữ liệu y tế (mã hóa at-rest và in-transit, tuân Nghị định 13/2023 về bảo vệ dữ liệu cá nhân), audit trail mọi quyết định chi/từ chối, hiệu năng (xử lý OCR < 10 giây), và độ sẵn sàng 99,5%.
Bước 7 — Thiết kế tích hợp & data. Phác API contract (REST/JSON) cho việc gọi HIS bệnh viện và cổng thanh toán; vẽ ERD cho các thực thể Policy, Member, Claim, ClaimLine, Document, Decision.
Bước 8 — Validation & Traceability. Lập RTM (Requirements Traceability Matrix) nối từ business objective → requirement → test case, để chứng minh không bỏ sót.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi đây là dự án IT thuần, quên mất nghiệp vụ bảo hiểm. Nhiều bạn lao vào vẽ màn hình và API mà chưa hiểu "waiting period" hay "co-payment" là gì. Hệ quả: rule engine sai về bản chất. Mẹo: dành ít nhất 30% thời gian elicitation với chuyên gia claim, đọc kỹ một bộ điều khoản hợp đồng thật.
Lỗi 2 — Thiết kế chỉ cho happy path. Bạn vẽ luồng "chụp ảnh → duyệt → trả tiền" rất đẹp nhưng quên: ảnh mờ, thiếu chứng từ, bệnh viện không phản hồi API, khách khai man. Mẹo: với mỗi bước trong BPMN, hỏi "nếu bước này thất bại thì sao?" và vẽ nhánh exception.
Lỗi 3 — Bỏ qua audit trail và compliance. Trong bảo hiểm, mọi quyết định chi trả phải truy vết được "ai/cái gì đã quyết, dựa trên rule nào". Nếu thanh tra Bộ Tài chính hỏi, bạn phải xuất được log. Mẹo: viết NFR audit trail ngay từ đầu, không để cuối dự án.
Lỗi 4 — Đặt ngưỡng OCR confidence một cách cảm tính. Đừng viết "OCR phải chính xác". Hãy định lượng: confidence ≥ 95% cho auto, 80-95% route người xác nhận, < 80% yêu cầu khách chụp lại. Con số phải đến từ thử nghiệm dữ liệu thật.
Mẹo vàng: Luôn thiết kế rule auto-approve "rộng" và auto-reject "hẹp". Máy được tự duyệt chi, nhưng việc từ chối nên ưu tiên đẩy sang người khi có nghi ngờ. Đây là nguyên tắc quản trị rủi ro trải nghiệm khách hàng trong Insurtech.
Bài tập thực hành
Hãy hoàn thành mini-project sau và lưu vào portfolio của bạn:
- Business Case + Context Diagram cho một sản phẩm digital health claim của một công ty bảo hiểm VN (tự chọn Bảo Việt, FWD, Manulife hoặc một startup giả định). Nêu rõ 3 KPI đo được.
- BPMN 2.0 diagram đầy đủ swimlane cho luồng claim ngoại trú cashless, có ít nhất 2 gateway và 1 nhánh exception (ảnh mờ / red flag fraud).
- Decision Table cho auto-adjudication với tối thiểu 6 điều kiện và 4 hành động đầu ra (auto-approve, partial, route manual, route SIU).
- 5 User Stories cho hành trình khách hàng kèm acceptance criteria theo định dạng Given-When-Then.
- Danh sách 8 NFR, trong đó bắt buộc có ít nhất: 1 về bảo mật dữ liệu cá nhân (dẫn chiếu Nghị định 13/2023), 1 về audit trail, 1 về hiệu năng OCR.
- Thử thách nâng cao: Viết 5 red-flag rule chống gian lận và giải thích logic nghiệp vụ đằng sau mỗi rule.
Tóm tắt
Capstone Insurtech này là phép thử cuối cùng cho khả năng tổng hợp của một BA. Bạn đã thấy: digital health claim không chỉ là "chụp ảnh thay vì gửi giấy", mà là bài toán cân bằng giữa tốc độ (STP, auto-adjudication), rủi ro (fraud detection, compliance), và trải nghiệm (cashless, theo dõi real-time). Trái tim công việc của BA nằm ở việc dịch điều khoản hợp đồng thành decision table mà máy chạy được, và ở việc thiết kế các nhánh exception cho thực tế vận hành hỗn hợp đặc thù Việt Nam — nơi nhiều bệnh viện chưa có API và gian lận là rủi ro thật.
Ba bài học cốt lõi: (1) BA thuyết phục bằng dữ liệu định lượng, không bằng cảm tính; (2) thiết kế rule auto-approve rộng nhưng auto-reject hẹp; (3) luôn có fallback path cho thực tế chưa số hóa hoàn toàn. Hoàn thành mini-project, đưa các artefact vào portfolio, và bạn sẽ có một câu chuyện dự án đủ sức nặng để bước vào phỏng vấn CBAP cũng như vị trí BA Insurtech thực thụ. Chúc bạn vững vàng trên hành trình nghề nghiệp phía trước.