HCL Workload Automation が保険金請求受付プロセスにどのような変革をもたらすか
2023/8/7 - 読み終える時間: 4 分
How HCL Workload Automation Revolutionizes the Insurance Claim Acceptance Process の翻訳版です。
HCL Workload Automation が保険金請求受付プロセスにどのような変革をもたらすか
2023年8月4日
著者: Sriram V / Technical Advisor-Workload Automation
これは、Workload Automation が保険ビジネス側のエンドツーエンドのプロセスをどのように模倣できるかを説明する 4 部構成シリーズの 2 番目の部分です。 (参考までに、シリーズの最初の部分へのリンクをここに示します。)
ここでは、以下のプロセスを調べ、HCL Workload Automation を使用してそれを模倣してみます。
保険請求は、受理プロセス中に完全性チェックを受け、すべての書類が保険請求の一部として提出されていることを確認します。 チェックの結果により、連絡先に電子メール通知が送信されるか、プロセスが次のステップに進むことが可能になります。
次のステップは、申し立てをエスカレーションする必要があるかどうかです。 エスカレーション要件により、さらなるレビューと承認のためにエスカレーションがポータルに送信される可能性があります。
請求ケースにエスカレーションが必要ない場合は、受入チェックが行われ、さらに明確な説明が必要な場合、または請求が受理されてシステムに登録される場合に備えて、請求は保留に設定されます。
請求フォームと文書に関するデータはすでに Mongo DB に保存されており、フォアグラウンドで公開されている Docusumo API を介して同じデータにアクセスできます。これを IBM Discovery API、Google Cloud Vision API などの同等の製品で置き換えることもできます。 。
保険フォームデータの完全性チェック
保険フォーム データの完全性チェックは、Docusumo API を利用して RESTFUL GET 操作を実行し、Mongo DB (すべてのデータが存在する) からデータを取得する RESTFUL GET ジョブとして実現される HWA ジョブを介して実行されます。
このジョブのジョブログは次のようになります。
このジョブには、データが完全であるかどうかを判断するための条件付き依存関係もあります。
したがって、これはジョブログ内でキーワード「N/A」を検索し、データが完全であるかどうか、または以前に Docusumo から実行されたスキャンに欠落しているフィールドがあるかどうかを判断します。
保険添付データの完全性チェック
保険添付データの完全性チェックは、バックグラウンドで実行されている内部 API を介してサービスされる同じ Mongo DB に対して、HWA ジョブを介して RESTFUL GET 呼び出しを行うことによって行われます。
ドキュメント データの完全性チェックは、ジョブ レベルで定義された条件付き依存関係を使用して再度検証されます。ジョブ ログ内の文字列「N/A」は、このデータがスキャンで利用できないか欠落していることを示し、その結果、条件「NOTCOMPLETE」が発生します。 満足する：
「NOTCOMPLETE」条件が満たされると、不足しているデータについて顧客に通知するために電子メールで顧客に通知を送信するメール ジョブが実行されます。
メール通知ジョブは、ドキュメントが完了していないことを示す通知を送信します。
CLAIM_ESCALATION ジョブ
これは、この場合にクレーム エスカレーションが必要かどうかをチェックする Unix ジョブとして実現されるため、呼び出されたスクリプトは、返された値が特定の値を超えているかどうかを評価します。
すべてのリターン コードが「REQ」、「NOT_REQ」にマップされる条件依存関係が定義されます。 したがって、戻りコード 5 または 0 に応じて、対応する条件 (必須または不要) が渡されます。
エスカレーションが必要な場合は、SEND_CLAIM_ESCALATION_PORTAL ジョブが呼び出され、ポータルに RESTFUL POST ジョブが実行されます。これにより、金額が特定の値を超えた場合に、より高い承認のためにクレームが上級管理者にエスカレーションされます。
MAKE_ACCEPTANCE_DECISION ジョブ
MAKE_ACCEPTANCE_DECISION ジョブは、AWS Lambda 関数または Google Cloud Functions を実行し、AWS または GCP 上でサーバーレス方式で実行されます。評価はバックグラウンドで Analytics を使用して実行されるか、Google Big Query ジョブまたは Azure Data Bricks ジョブの形式で実行されます。 以前の傾向から取得した履歴データや保険会社が作成したカスタム機能に基づいて請求が受け入れられるかどうか、または請求が「保留」になるか「受け入れられない」可能性があるかを確認します。
すべてのリターン コードが「ACCEPT」、「NOT_ACCEPTED」、「PENDING」のいずれかにマップされる条件依存関係が定義されます。 したがって、戻りコード 127、37、または 0 に応じて、対応する条件が渡されます。
要求保留設定のジョブ
このジョブは、Mongo DB で請求を保留に設定し、保険会社からのさらなるチェックのために請求を手動でさらに評価できるようにします。
「ACCEPT」条件を通過した場合、請求は「RESGITER CLAIM」ジョブによって受理され、請求の登録が正常に完了したことを通知するメール通知がメールジョブによって送信されます。
HWA 側の全体の流れ
