立即註冊娛樂城描述：：原標題：互聯網保險產品設計那點事（二）：保險理賠 繼上文講到的互聯網保險產品設計那點事（一）后，筆者繼續從財險理賠角度入手做進一步深入分析。 1. 前言 在互聯網保險行業中，非保險產品供應側的企業的業務流程大致是相似的。如下圖： 在上述的三個業務流程步驟中，從產品設計的角度考量，最具有保險專業特性的模塊為項目運營管理。 在互聯網保險經代類企業中： 1. 項目運營管理產品設計核心偏重于保險產品管理以及保單保全管理； 2. 產品設計難點： 保險產品管理（偏重核保規則配置）； 保險產品投保管理（偏重投保流程客制化配置）； 在互聯網保險服務類企業中： 1. 項目運營管理產品設計核心偏重于保險保全管理以及保險理賠管理； 2. 產品設計難點： 保險產品管理（偏重理賠規則配置）； 賠案理賠管理（偏自動理賠流程客制化配置）； 保單保全管理（偏重保單額度規則及流程配置）； 本文就互聯網保險服務類企業的核心模塊（理賠）的產品設計進行分享。 本文的理賠模塊的業務選擇范圍： 企業范圍：TPA企業 險種范圍：健康險 用戶維度：B2B2C 業務維度：團險 選擇原因：目前互聯網保險行業中，健康險的團險理賠與互聯網場景契合度最高，也最為復雜之一。 2. 理賠產品設計 2.1 理賠業務流程 上圖所示為健康險中理賠場景的業務處理流程，一個理賠案件的處理流程從立案收單到結案申請書輸出為一個完整的理賠預處理流程。 為什么稱為完整的理賠預處理流程，而不是完整的理賠處理流程呢？ 因為這里缺失了【保額扣減】的環節。這一環節是當賠案經過理算引擎理賠得出預計賠付金額后，會根據結算引擎（額度扣減規則）的運算得出實際賠付金額。當得到實際賠付金額后，整個理算流程才會完成。然而保單保額的管理角色的扮演者在不同的客戶場景中是不同。有的保險項目中，保額的管理者是被保險企業或保險產品供應側企業；有的保險項目中，保額的管理者是理賠處理方。 因為保額管理以及賠案結算引擎本身復雜度也較高，因而會在后續的文章中單獨分享，在此就不展開分享。 2.2 收單模塊 2.2.1 業務場景 被保險人在申請保險理賠服務后，通過線上(如：APP)或線下(如：快遞郵寄)的方式，將索賠申請書，身份證明等理賠所需相關申請材料遞交到理賠處理方的動作，稱為收單。 2.2.2 收單方式 根據實際業務場景大體分為以下幾種收單方式： 賠案資料線上方式上傳：如通過APP上傳或通過制定網頁上傳； 賠案資料快遞寄送：被保險人通過郵寄的方式將資料遞交給理賠方； 賠案資料送貨上門：被保險人親自將理賠材料送到理賠方所在企業； 收單人員批量收取：理賠方指派專業人員去被保險企業或被保險人所在地批量收取材料； 2.2.3 收費模式 在通過指派專業收單人員進行批量收單時，會產生人力成本，進而會發生服務變現的方式，主要收費方式有以下幾種： 按年收取收單服務費：如：2019年駐場收單費用為50萬元； 按人收取收單服務費：如：駐場收單人員每人每月5000元； 按次收取收單服務費：如：每次收單服務收取服務費200元； 按件收取收單服務費：如：每個案件的全流程服務費20元； 2.2.4 設計難點 顯而易見的難點：對于收單人員和收單計劃的合理管理和收取的理賠案件管理，如何保障每個案件及每個案件所包含的所有材料均未有遺失且可被逐一追溯？ 對于賠案時效的管理和跟蹤（收單時效：一個理賠案件從收單開始到錄入系統的時間限制）； 對于收單服務費的費率表的維護和結算管理； 在收單時，會對收取材料類目錯誤或收取材料內容錯誤進行打回重新收取的管理。 其他難點。。。 2.2.5 設計思路 針對第1和第2難點： 基本方案：人員管理，人員月度任務排期，整體理賠模塊的案件流轉監控體系等。 優化方案：收單任務池，任務自動分配，任務搶單機制等； 針對第3難點： 基本方案：是提供客制化的費率規則模板。 但從本質講，規則模板并未解決用戶需求，因為這個需求的用戶并不是對外用戶而且對內用戶，即銷售及業務管理者。銷售和業務管理者的本質需求是可以便捷的維護和管理費率表（所錄即所見）。而使用規則模板的解決方案只降低了開發成本，并未達到便捷管理的需求。 優化方案：通過交叉決策表替代規模模板來維護和管理費率表。 針對第4難點，這類問題是整個理賠流程皆有的異常流程處理機制，需要了解整個理賠流程的異常流程分支后，進行統一化處理。 其他難點也有很很多，這主要根據險種和客制化需求不同而不同。 2.3 掃描模塊 2.3.1 業務場景 在收單后，將收取的理賠案件的紙質化資料通過掃描設備轉化為電子影像件，方便后續的理賠自動動作執行。 2.3.2 設計難點 掃描階段的難點并不在互聯網產品設計中，而在硬件設備的掃描SDK中，此處要考究產品的點主要在于錄入方式是通過人工化錄入還是自動化錄入（ICR識別技術，注意是ICR而非OCR） 掃描階段有一個小難點： 如何保障在掃描執行中不會漏掃案件？ 因理賠案件材料數目及類目不足而需補掃或重新掃描時，如何不打亂整個賠案序列或不影響掃描效率？（賠案序列即為批量收單時根據被保險人遞交順序生成的批量序列，此序列因規定不可更改） 2.3.3 設計思路 難點1，并不在此處分享，會在后續錄入環節中分享。 難點2，此處涉及具體產品設計內容并不延伸討論。總的講，了解業務后，解決方法多種多樣。 2.4 錄入模塊 2.4.1 業務場景 將掃描環節生成的理賠案件的電子影像件的理算所需內容錄入到理算系統中。 2.4.2 錄入方式 根據實際研發能力分為以下2種收單方式： 人工錄入：成本較ICR略低，但準確率低，不足70%； ICR識別錄入：小業務量下，成本較高，大業務量下，成本較低，準確率在少量人工干預下可達到95%及以上； 2.4.3 設計難點 因為我們要通過互聯網的方式實現自動化理賠，那么理賠的核心理算環節的準確率則至關重要。保證理算準確率的有三個關鍵因素：理算基礎數據，理算規則，理算流程。而錄入環節則是保證理算基礎數據的準確性。 在健康險中，理算的基礎數據有哪些呢？ 索賠申請書的字段數據； 身份證明的字段數據； 病例的字段數據； 發票及支付憑證的字段數據； 消費項目清單的字段數據； 其他客制化需求的資質證明數據等； 以上的資料中錄取準確性差異最大的模塊為發票和消費項目清單，此處就發票進行簡單的介紹。 健康險下，發票類型大致分為：門診發票，住院發票，增值稅發票(購藥使用)； 而發票模板由于各省市的發票模板各有不同，大體上可針對門診發票和住院發票，又分為【通用發票模板】【北京發票模板】【上海發票模板】【解放軍(醫院)發票模板】。 針對發票模塊所需要錄入的信息，主要有以下幾點： 1. 發票號：方便進行發票驗真。 2. 發票類型：上文已述。 3. 發票所屬醫療機構； 4. 發票日期：門診發票為單個日期，住院發票為住院日期和出院日期。 5. 發票所屬疾病的ICD10編碼： 國際疾病分類（international Classification of diseases ,ICD），是依據疾病的某些特征，按照規則將疾病分門別類，并用編碼的方法來表示的系統 6. 發票金額字段： 發票合計金額：發票的總計金額； 醫保統籌支付金額：統籌支付就是用統籌帳戶資金支付參保人相關醫療費用。帳戶支付，也就是用參保人的醫保卡在藥店或門診的刷卡消費行為。醫保統籌管理，由個人帳戶和統籌帳戶組成； 分類自負（自付二）：指基本醫療保險支付部分費用項目中，先由參保人員個人按規定比例或差額進行現金自付的費用。合計結算前的自負部分，比如乙類自負10%； 自負（自付一）：指醫保結算范圍內的醫療費用。合計結算后自負部分，比如說退休自負10%； 自費：指醫療保險基金支付范圍外的藥品、醫療服務項目費用及《浙江省基本醫療保險、工傷保險和生育保險藥品目錄》、《浙江省基本醫療保險醫療服務項目目錄》內的限定支付費用和超標準以上部分費用； 三方支付：其他報銷。 2.4.4 設計思路 此處在大多數非大理賠服務方(即賠案年處理量低于500萬件)，采用的錄入方式是人工錄入。那么就要考量如何更有效更準確的進行賠案錄入。需要結合企業業務現狀，錄入人員技能強弱，人力成本，進行合理的錄入功能產品拆分，保障在同等人力成本下，錄入的效率和準確性得以顯著提高。 需結合下一環節（理算）的需求，將一些通用的理算環節的預處理流程事先在錄入環節得以實現，這部分會在理算中講解。 2.5 理算模塊 2.5.1 理算場景 將通過人工或自動化的方式計算賠案的實際賠付金額。 2.5.2 理算基礎公式 門診保險金計算公式： 預計賠付金額 = （發票核準金額 – 免賠金額）* 賠付比例 住院保險金計算公式： 預計賠付金額 = （發票核準金額 – 免賠金額）* 賠付比例 津貼保險金計算公式： 預計賠付金額 = 每日津貼 *（賠付天數 – 免賠天數）（賠付天數 <= 單次最長天數）； 以上計算公式僅為基礎理算公式，實際業務因為保險產品的客制化需求各不相同，即理算規則模型各不相同。 理算規則示例參考如下： 示例1： 關于跨年度案件理賠（住院）核實結果參照以下方案： 1. 津貼 =（前年度天數 * 前年度津貼）+（當年度天數 * 當年度津貼） 2. 住院醫療費用 =（發票合計金額 – 醫保統籌支付金額 – 非醫保金額）* 前年賠付比例 * 前年度天數 / 總天數+（發票合計金額 – 醫保統籌支付金額 – 非醫保金額）* 當年賠付比例 * 當年度天數/總天數 3. 賠付比例：員工100%，家屬50%； 4. 住院天數：若為0.5天，則按1天計算，若為9.5天，則按9天計算。 5. 第三方賠付金額，按照以下公式的結果取小值進行理算： 理算合理金額1 = 總金額– 統籌– 第三方賠付 理算合理金額2 =（發票合計金額 – 醫保統籌支付金額 – 非醫保金額）* 賠付比例； 示例2： 示例3： 示例4： 2.5.3 設計難點 從以上示例，可發現理算規則模型各式各樣，參照標準范圍極廣。因而如何更好更便捷的維護和使用理算規則，是自動理算引擎的核心難點。理算引擎由于內容復雜，會作為單獨的章節在后續講解。 2.6 復核模塊 2.6.1 業務場景 在錄入和理算環節都存在復核場景的存在，復核即對有異議的賠案進行重新審查。如 錄入環節中，錄入人員對賠案資料中非標準化數據的錄入存疑時，執行賠案掛起操作，賠案被標記為疑問件，此時就需要復核崗的介入。 理算環節中，對于單獨賠案申請理賠金額超過5000或多次被退單拒賠的案件需要復核崗進行結果審核； 2.6.2 設計難點 此模塊需要對全理賠流程的異常流程分支進行整合梳理和歸納分類。區分 是否需要暫停理賠時效； 是否需要理賠方向保險產品供應側發起賠案疑問查詢； 必須復核的規則時什么？ … 2.7 結案模塊 2.7.1 業務場景 在完成理算和復核環節后，如賠案的被保險人的保單的保額的管理權限不屬于理賠方時，賠案流程跳轉到結案環節。如保額管理權限屬于理賠方，則跳轉到賠案的實際賠付金額計算環節。 PS：如不屬于理賠方時，默認實際賠付金額與預計賠付金額相等。 2.7.2 設計難點 當理賠方不是保險產品供應側（保險公司）時，理賠方需向保險公司輸出賠案結案申請和賠案結案數據。因各保險公司的數據導入規則和導入通道各不相同，因而結案時需根據保險公司需求進行數據對接。 對結案數據的管理和結案紙質原件的文檔管理。 結案數據與被保險人的屬性關聯，用戶的健康管理。 … 本期就分享到這，下一期主要分享一下關于理賠核心—理算引擎的相關內容。 本文由 @楊三季 原創發布于人人都是產品經理，未經許可，禁止轉載 題圖來自 Unsplash，基于 CC0 協議