保険金請求処理のデータテンプレート
保険金請求処理のデータテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- Duck Creek Claimsからの抽出ガイド
保険金請求処理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 請求について、特定の時点で発生した業務アクティビティまたはイベントの名称です。 | ||
| 説明 この属性は、請求プロセス内で実行された特定のステップまたはタスクを表します。たとえば、「Claim Submitted」、「Adjuster Assigned」、「Payment Issued」などです。各アクティビティは、請求のライフサイクルにおける個別の時点を示します。 これらのアクティビティの順序と頻度を分析することが、プロセスマイニングの中心です。プロセスモデルの発見、ボトルネックの特定、手戻りループの検出、標準モデルとの差異の分析が可能になります。 重要な理由 アクティビティ名はプロセスフローの各ステップを定義するものであり、請求プロセスの発見、分析、監視に欠かせません。 入手先 通常は、Duck Creek Claims内のイベントログ、取引名、またはステータス変更記録から取得します。複数のソースフィールドやテーブルからのマッピングが必要になる場合があります。 例 保険金請求を提出損害査定担当者を割り当て調査を開始支払いを実行請求終了 | |||
| イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した時点を示すタイムスタンプです。 | ||
| 説明 イベント時刻は、請求のライフサイクルに記録された各アクティビティの正確な日時を示します。この時間情報は、パフォーマンス分析に欠かせません。 分析では、このタイムスタンプを使ってアクティビティ間のサイクルタイムを計算し、待ち時間を特定し、ケース全体の所要時間を測定し、期間ごとのプロセスパフォーマンスを分析します。時間ベースのプロセス指標を支える基盤となる情報です。 重要な理由 サイクルタイムや所要時間など、時間に基づくすべての指標の計算に欠かせません。パフォーマンス分析とボトルネックの特定が可能になります。 入手先 Duck Creek Claimsのイベントログまたは取引ログに関連付けられた標準的なタイムスタンプフィールドです。「CreateDate」、「Timestamp」、「EventDate」などのフィールドを確認してください。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 請求ID ClaimId | 単一の保険金請求を識別する一意の識別子であり、ケースの主識別子として機能します。 | ||
| 説明 請求IDは、1件の保険金請求に関連するすべてのイベントとアクティビティを、申請から終了まで結び付ける基本キーです。請求のライフサイクル全体を一貫して追跡できます。 プロセスマイニング分析では、ケースビューを構築するために欠かせない属性です。分析担当者は、各請求の全体の流れを追跡し、エンドツーエンドのサイクルタイムを測定し、プロセスのバリエーションを分析できます。 重要な理由 プロセス内の関連するすべてのイベントを結び付け、請求のライフサイクルを最初から最後まで確認できる基本的なCase IDです。 入手先 Duck Creek Claims内の請求メインエンティティまたはテーブルにおける主キーです。具体的なテーブル名とフィールド名については、システムのドキュメントを参照してください。 例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| 割り当て済み査定担当者 AssignedAdjuster | 特定のアクティビティで請求の処理を担当する査定担当者の名前またはIDです。 | ||
| 説明 アクティビティを実行するユーザーまたはリソースを識別する属性です。ケースが異なる査定担当者やチームに引き継がれると、請求のライフサイクル中に変わることがあります。 リソースのパフォーマンス、業務量の分配、引き継ぎを分析するために欠かせません。査定担当者の処理量、業務量の偏り、ボトルネックを確認するダッシュボードでは、個人やチームへの業務の割り当てと処理状況を把握するために、この属性を頻繁に利用します。 重要な理由 リソースのパフォーマンス、業務量の平準化、協業パターンを分析できます。ボトルネックやトレーニングの必要性の特定にも役立ちます。 入手先 Duck Creek Claimsのドキュメントを参照してください。請求タスク、イベント、または請求メインエンティティに関連するテーブルで、ユーザー、所有者、割り当て先のフィールドを確認してください。 例 John SmithJane DoeRobert Brownadjuster_1138 | |||
| 損害額 LossAmount | 請求で報告された損害の見積額または実際の金額です。 | ||
| 説明 請求に関連する損害の初期見積額を表す属性です。請求の振り分け、複雑度、必要な調査レベルに影響する主要な財務指標です。 分析では、請求を区分し、金銭的な影響とプロセスの動きの関係を把握するために使います。たとえば、高額な請求では異なる経路をたどったり、サイクルタイムが長くなったりする場合があります。業務プロセスデータに財務面の重要な文脈を加えます。 重要な理由 請求の財務面を把握できます。請求額が処理経路、所要時間、結果に与える影響を分析できます。 入手先 Duck Creek Claimsのドキュメントを参照してください。請求に関する基本的な財務フィールドで、「Reported Loss」または「Initial Reserve」と呼ばれることがよくあります。 例 1500.0025000.50125000.00 | |||
| 請求ステータス ClaimStatus | 特定の時点における請求全体のステータスです。たとえば、「Open」、「Pending」、「Closed」などです。 | ||
| 説明 請求ステータスは、ライフサイクル上の請求の現在の状態を表します。プロセス全体のどの段階にあるかを大まかに把握できます。 請求案件の全体像を作成したり、ケースを絞り込んだりする際に役立ちます。特に、「Closed - Paid」や「Closed - Denied」など、請求の最終結果を特定するうえで重要です。結果の分析や却下率の把握に欠かせません。 重要な理由 請求の現在の状態と最終結果を把握できます。結果の分析やケースの絞り込みに欠かせません。 入手先 Duck Creek Claimsのドキュメントを参照してください。請求メインレコードにある基本フィールドです。 例 オープン保留-情報待ちクローズ-示談成立クローズ-却下 | |||
| 請求種別 ClaimType | 自動車、財物、賠償責任など、保険金請求の分類です。 | ||
| 説明 請求種別は、事業分野または損害の性質に基づいて請求を分類します。請求データを区分して分析するための基本的な軸です。 請求種別ごとのプロセスパフォーマンスを比較するために使います。たとえば、「Auto - Total Loss」と「Property - Water Damage」では、プロセスもKPIも大きく異なります。請求種別で分析することで、より適切な比較や、対象に合わせたプロセス改善施策が可能になります。 重要な理由 分析を区分するための重要な軸です。請求種別によって、プロセス、SLA、複雑さの水準が異なることが多いためです。 入手先 Duck Creek Claimsのドキュメントを参照してください。請求メインレコードにある基本属性です。 例 個人自動車保険-衝突企業財物保険-火災労災補償一般賠償責任 | |||
| 請求複雑度 ClaimSeverity | 低・中・高など、請求の財務面または業務面の複雑さを分類したものです。 | ||
| 説明 請求複雑度は、請求に見込まれる影響や複雑さを示します。初期損害見積もり、事故の性質、その他の定義済み業務ルールに基づいて設定される場合があります。 高複雑度の請求は通常、より多くのステップ、長い処理時間、専門的なリソースを必要とするため、パフォーマンス分析に欠かせない属性です。複雑度別にKPIを区分することで、現実的な目標を設定し、複雑さがプロセスの効率や結果に与える影響を把握できます。 重要な理由 請求を複雑さで区分できます。より細かなパフォーマンス分析や、サイクルタイムとコストの現実的なベンチマークに役立ちます。 入手先 Duck Creek Claimsのドキュメントを参照してください。専用フィールドの場合もあれば、初期損害準備金額から算出される場合もあります。 例 低中高壊滅的 | |||
| 部門 Department | 特定の時点でアクティビティまたは請求を担当する部門またはチームです。 | ||
| 説明 請求を担当する機能グループまたは部門を示す属性です。たとえば、「Initial Intake」、「Investigation Unit」、「Settlement Team」などです。プロセスフローに組織上の文脈を加えます。 部門別の分析は、プロセスパフォーマンスを全体的に把握するうえで重要です。部門間のボトルネックの特定、チーム単位の効率測定、組織内での業務の流れの把握に役立ちます。 重要な理由 機能領域別にパフォーマンスを分析できます。部門間の引き継ぎや、チーム固有のボトルネックを明らかにします。 入手先 Duck Creek Claimsのドキュメントを参照してください。この情報は、割り当てられたユーザーのプロファイル、またはキューやワークグループの割り当てに関連付けられていることがよくあります。 例 自動車保険金請求大規模損害の財物保険金請求特別調査部門支払い処理 | |||
| ソースシステム SourceSystem | イベントデータを抽出したシステムです。 | ||
| 説明 請求データの発生元であるアプリケーションを識別する属性です。この場合は一貫して「Duck Creek Claims」になります。 すべてのデータが1つのシステムから取得される場合は重複して見えるかもしれませんが、データガバナンス、追跡可能性、将来的に複数のシステムからデータを統合する場合に欠かせません。データの発生元と構造を把握するための文脈を提供します。 重要な理由 データの系譜と文脈を示す重要な情報です。特に複数の統合システムがある環境で、データガバナンスやトラブルシューティングに役立ちます。 入手先 通常は、データの発生元を示すために、データの抽出・変換処理中に追加される固定値です。 例 Duck Creek Claims | |||
| 保険契約番号 PolicyNumber | 請求が提出された保険契約を一意に識別する番号です。 | ||
| 説明 請求を元の保険契約に結び付ける属性です。請求に関連する補償内容、契約条件、顧客の情報を把握できます。 プロセスフロー分析で直接使わない場合もありますが、請求データを充実させるうえで重要です。保険契約や顧客のデータと結合し、顧客セグメント、保険契約種別、契約期間によってプロセスパフォーマンスがどう変わるかを分析できます。より広い業務上の視点を得られます。 重要な理由 請求を顧客と保険契約に結び付け、異なる顧客セグメントや保険契約種別にプロセスパフォーマンスが与える影響を幅広く分析できます。 入手先 Duck Creek Claimsのドキュメントを参照してください。請求メインエンティティにある標準的な参照フィールドです。 例 PA-987654321CP-123456789WC-555444333 | |||
| 最終データ更新 LastDataUpdate | ソースシステムから直近にデータを更新した時点のタイムスタンプです。 | ||
| 説明 データセットが最後に更新された日時を示す属性です。分析対象データの鮮度を確認する基準になります。 ダッシュボードや分析では、インサイトがどの程度新しい情報に基づくものかを利用者に伝えるために使います。最新の取引がプロセスビューに含まれているかどうかを判断する際にも役立ちます。 重要な理由 データの鮮度を利用者に伝えます。分析結果の解釈や、適切なタイミングでの意思決定に欠かせません。 入手先 通常、データの抽出・変換・ロード(ETL)処理中に生成され、データセットのメタデータに保存されます。 例 2024-05-21T02:00:00Z | |||
| 却下理由 RejectionReason | 請求が否認または却下された具体的な理由です。 | ||
| 説明 請求を否認する判断が下された場合、その判断の根本的な理由を示す属性です。通常は、あらかじめ定義されたコードまたは説明の一覧から選択します。 却下理由の分析は、「Claim Decision & Rejection Insights」ダッシュボードに欠かせません。申請時のよくある問題、潜在的な不正パターン、保険契約の文言が分かりにくい箇所を特定できます。受付プロセスや引受ルールの改善にもつながります。 重要な理由 請求が否認された理由を明らかにし、受付プロセスの改善、無効な申請の削減、トレーニング機会の特定に役立つ具体的な情報を提供します。 入手先 Duck Creek Claimsのドキュメントを参照してください。通常、請求のステータスが「Denied」または同様の状態に変更されたときに入力されます。 例 補償対象外の危険保険契約の期限切れ重複請求不正の疑い | |||
| 手戻りかどうか IsRework | アクティビティが手戻りループの一部かどうかを示す計算済みフラグです。 | ||
| 説明 他の異なるアクティビティが発生した後に、同じアクティビティが請求内で繰り返された場合、trueに設定される真偽値属性です。たとえば、プロセスが「Loss Assessed」から「Investigation Started」に戻る場合です。 手戻りを定量化・分析するために欠かせません。「Claim Rework Rate」KPIや「Claim Rework & Reprocessing Patterns」ダッシュボードで、手戻りが発生したアクティビティやケースを直接絞り込み、可視化できます。プロセスの非効率や品質上の問題を特定するのに役立ちます。 重要な理由 アクティビティ単位で手戻りを定量化でき、プロセスの非効率の原因と影響を測定、可視化、分析しやすくなります。 入手先 ソースシステムのフィールドではありません。ケース内でアクティビティの並びが繰り返されていることを検出するアルゴリズムを使い、データ準備中に算出します。 例 truefalse | |||
| 期限内に解決したかどうか IsOnTimeResolution | 請求が解決目標日までに、またはその日までに終了したかどうかを示す計算済みフラグです。 | ||
| 説明 請求の「Claim Closed」アクティビティのタイムスタンプと「ResolutionTargetDate」を比較して算出する真偽値属性です。期限内(true)または遅延(false)として各請求を示します。 「On-Time Claim Resolution Rate」KPIを直接支えます。ダッシュボードでSLA遵守状況を簡単に集計・可視化でき、遅延した請求に共通する特徴(請求種別、部門、プロセス経路など)を掘り下げて分析できます。 重要な理由 請求単位でSLA遵守状況を直接測定できます。期限超過した請求の絞り込みや根本原因分析に役立ちます。 入手先 ソースシステムのフィールドではありません。最終アクティビティのタイムスタンプと「ResolutionTargetDate」フィールドを比較して、データ準備中に算出します。 例 truefalse | |||
| 示談金額 SettlementAmount | 請求を解決するために最終的に合意した金額です。 | ||
| 説明 計算され、支払いが承認された示談金額を記録する属性です。支払いに至った各請求の結果を示す主要な指標です。 財務分析や「Payment Authorization & Issuance Time」などのダッシュボードに欠かせません。初期の「Loss Amount」と比較することで準備金の精度を分析でき、請求プロセスの財務的な結果を把握する基礎になります。 重要な理由 請求における主要な財務結果を表します。財務報告や初期損害見積もりの精度分析に欠かせません。 入手先 Duck Creek Claimsのドキュメントを参照してください。通常、請求に関連する財務取引テーブルまたは支払い関連テーブルに保存されています。 例 1450.7522000.00115800.20 | |||
| 終了時刻 EndTime | アクティビティが完了した時点を示すタイムスタンプです。 | ||
| 説明 アクティビティの完了時刻を示す属性です。StartTimeがアクティビティの開始時刻を示すのに対し、EndTimeはそのタスクの所要時間を計算するための終了時刻を示します。 プロセスマイニングでは、アクティビティの開始時刻と終了時刻の両方があることで、パフォーマンスをより詳細に分析できます。タスクに実際に取り組んだ「Processing Time」と、タスク間で費やした「Waiting Time」を正確に計算できます。この区別は、ボトルネックを正確に特定するうえで欠かせません。 重要な理由 アクティビティの処理時間を正確に計算し、実作業時間とアイドル時間・待ち時間を区別できます。正確なボトルネック分析に欠かせません。 入手先 イベントログに独立したタイムスタンプフィールドとして存在する場合があります。同じケース内の次のアクティビティのStartTimeから算出することもできます。 例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| 自動処理かどうか IsAutomated | 人の介入なしに、システムがアクティビティを自動実行したかどうかを示す真偽値フラグです。 | ||
| 説明 人が完了したタスクと、自動通知、初期データ検証、ストレートスルー処理など、システムが実行したタスクを区別するフラグです。 この属性を分析することで、請求プロセスの自動化レベルを把握できます。自動化施策の効果を測定し、さらなる自動化の機会を特定するとともに、自動処理が後続工程に問題を生じさせず、想定どおり機能しているかを確認できます。 重要な理由 自動化が効率とコストに与える影響を測定し、ストレートスルー処理の機会を特定できます。 入手先 イベントに関連付けられた「user」(例:「SYSTEM」または「BATCH」)から推定するか、イベントレコードの専用フラグから取得できる場合があります。 例 truefalse | |||
| 解決目標日 ResolutionTargetDate | SLAまたは社内目標に基づき、請求を解決する予定の期限日です。 | ||
| 説明 請求を終了する期限を保存する属性です。この日付は、規制要件、サービスレベル合意(SLA)、社内の主要業績評価指標(KPI)によって決まり、請求種別や複雑度によって異なる場合があります。 「On-Time Claim Resolution Rate」KPIの計算や、「Claim Resolution Target Adherence」ダッシュボードを支える基準になります。SLA違反のリスクがある請求を事前に監視し、優先順位を付けて対応できます。 重要な理由 サービスレベル合意(SLA)や社内目標に対するパフォーマンスを測定できます。顧客満足度とコンプライアンスに直接影響します。 入手先 Duck Creek Claimsのドキュメントを参照してください。専用のSLA日付フィールドの場合もあれば、請求申請日と業務ルールに基づいて算出される場合もあります。 例 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
保険金請求処理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 保険金請求の判断を決定 | 「Approved」、「Partially Approved」、「Denied」など、保険金請求に対する正式な判断を示すアクティビティです。最終判断のステータスに変更された時点から推定する、重要なマイルストーンです。 | ||
| 重要な理由 意思決定における主要なマイルストーンです。この時点までにかかる時間と判断結果は、プロセス分析と効率性を評価するうえで中心的な要素です。 入手先 専用の「Claim Decision」または「Claim Status」フィールドが「Approved」や「Denied」などの終了状態に変わった時点から推定し、その変更時刻を取得します。 取得 保険金請求の主要ステータスまたは判断フィールドの更新から推定します。 イベントタイプ inferred | |||
| 保険金請求を却下 | このアクティビティは、保険金請求が正式に否認されるプロセス上の別の終了点を表します。請求の最終ステータスが「Denied」または「Rejected」に設定された時点で記録されます。 | ||
| 重要な理由 これは個別に分析する必要がある重要な結果です。請求が否認される理由とタイミングを把握することで、受付プロセスの改善とコンプライアンスの管理に役立ちます。 入手先 請求エンティティテーブルで、請求の最終ステータスが「Denied」、「Rejected」、または「Closed without Payment」に変更された時点のタイムスタンプから推定されます。 取得 請求の最終ステータスが否認理由になっていることから推定されます。 イベントタイプ inferred | |||
| 保険金請求を提出 | これは最初のイベントであり、保険会社がFirst Notice of Loss(FNOL)を受け取ったことを示します。通常、代理店または保険契約者がシステムに初期の保険金請求情報を入力した際に、明示的な取引として記録されます。 | ||
| 重要な理由 このアクティビティは、保険金請求のライフサイクル全体の開始を示します。このイベントから他のイベントまでの時間を分析することは、総処理時間と受付業務の効率を把握するうえで重要です。 入手先 通常、Duck Creek Claimsで新しい保険金請求レコードが初めて作成された際に、ClaimsまたはFNOLのログテーブルへ明示的なイベントとして記録されます。 取得 新しい保険金請求レコードの初回作成時に記録されるイベントです。 イベントタイプ explicit | |||
| 支払いを実行 | 保険金を支払う財務取引が実行されたことを示すアクティビティです。小切手、EFT、その他の方法で支払いが送付された際に生成される、明確で明示的なイベントです。 | ||
| 重要な理由 承認済みの保険金請求に対する財務上の支払い義務が完了したことを示します。「Payment Authorized」から「Payment Issued」までの時間から、財務部門の処理効率を把握できます。 入手先 Duck Creek Claimsの財務取引テーブルから取得します。このテーブルには、特定の取引コードとタイムスタンプとともに、すべての支払いが記録されます。 取得 支払いが処理された際に、個別の財務取引ログが作成されます。 イベントタイプ explicit | |||
| 支払いを承認 | 計算された精算額の支払いが正式に承認されたことを示します。通常、管理者または別の権限者が関与する独立したステップで、明示的な承認取引として記録されます。 | ||
| 重要な理由 支払い前の重要な管理ポイントであり、ボトルネックになる可能性があります。「Claim Decision Made」からこの時点までの所要時間は、「Average Claim Approval Time」KPIで測定します。 入手先 通常、特定の権限を持つユーザーが支払いを承認するワークフローまたは財務モジュールの明示的なイベントです。承認ログから取得できます。 取得 ワークフローまたは取引ログに記録される明示的な承認イベントです。 イベントタイプ explicit | |||
| 請求終了 | 支払いが実行された、または請求が解決した後に、請求ファイルを管理上終了する最終アクティビティです。「Closed」への最終ステータス更新によって記録されます。 | ||
| 重要な理由 このアクティビティは、プロセスが正常に終了したことを示します。「Average End-to-End Claim Cycle Time」やその他の主要な期間指標を計算する際の終点になります。 入手先 請求のメインデータテーブルで、最終ステータスが「Closed」または「Settled」に変更された時点のタイムスタンプから推定されます。 取得 請求の最終ステータスが「Closed」に設定されていることから推定されます。 イベントタイプ inferred | |||
| 保険金請求を登録 | 提出された保険金請求が正式に受理・登録されたことを示します。この時点で、一意のClaim IDが正式に割り当てられます。通常、初期データ検証後に自動生成されるシステムイベントです。 | ||
| 重要な理由 保険金請求の開始を正式に確定し、査定担当者の割り当てなど後続プロセスを開始します。提出から登録までの時間は、初期データの品質やシステム負荷の問題を示す場合があります。 入手先 主Claim IDが生成された時刻、およびメインの保険金請求エンティティテーブルで請求ステータスが「pending」または「submitted」から「open」または「registered」に変わった時刻から推定します。 取得 主たる保険金請求レコードの作成時刻、またはステータスが「Open」に変わった時刻から導出します。 イベントタイプ inferred | |||
| 初回レビューを完了 | 割り当てられた査定担当者による、保険金請求の初回の詳細な審査が完了したことを示します。通常、割り当て後に請求ステータスが変わり、「Assigned」から「Under Review」または「Investigation」へ移行した時点などから推定します。 | ||
| 重要な理由 このマイルストーンにより、査定担当者が最初の対応を行うまでの時間を測定でき、業務量の滞留を示す場合があります。人が主導する最初の主要なチェックポイントです。 入手先 請求ステータスフィールドの変更から推定します。たとえば、「Initial Review Complete」または「Pending Information」への移行時刻を使用します。 取得 査定担当者の割り当て後に請求ステータスフィールドが変更された時点から推定します。 イベントタイプ inferred | |||
| 損害査定担当者を割り当て | 登録済みの保険金請求に査定担当者または担当者が割り当てられたことを記録するイベントです。システムがこの割り当てを記録することで、明確な引き継ぎ地点が生まれ、請求のライフサイクルにおける担当責任が定まります。 | ||
| 重要な理由 リソース配分や査定担当者の業務量を分析し、請求の割り当てにおける遅延を特定するうえで重要です。待ち時間が発生しやすい主要な引き継ぎ地点でもあります。 入手先 メインの保険金請求データテーブルにある「Assigned Adjuster」フィールドの更新によって追跡します。このフィールドの履歴または監査ログから時刻を取得できます。 取得 査定担当者フィールドに値が入力または変更された際に、監査証跡へ記録されます。 イベントタイプ explicit | |||
| 損害額を査定 | 調査結果に基づいて、支払準備金が設定または更新された時点を示すマイルストーンです。請求による財務上の影響を見積もるもので、準備金額が入力または調整された際に記録されます。 | ||
| 重要な理由 プロセスにおける重要な財務チェックポイントです。このイベントの発生時点を分析することで、財務評価の速度と精度を把握できます。 入手先 通常、Duck Creek Claimsの保険金請求に関する財務取引ログまたは準備金履歴テーブルに、明示的な財務取引として記録されます。 取得 保険金請求の準備金を設定または更新した財務取引として記録されます。 イベントタイプ explicit | |||
| 支払額を算出 | 承認判断の後に、最終的な支払額または精算額を計算するアクティビティです。明示的なステップとして記録される場合や、システムの財務モジュールで支払額が確定した時点から推定する場合があります。 | ||
| 重要な理由 「Settlement Rework Rate」KPIを測定するうえで重要なアクティビティです。1件の保険金請求でこのイベントが複数回発生する場合、精算段階で非効率、エラー、交渉が発生している可能性があります。 入手先 明示的な取引ログの記録、または保険金請求の財務データにある「Settlement Amount」フィールドの更新から推定します。このフィールドの監査ログが主な情報源です。 取得 最終的な支払額が計算され、保存された際にイベントとして記録されます。 イベントタイプ explicit | |||
| 調査を完了 | 必要な事実の収集を終え、調査アクティビティが完了したことを示します。通常、請求ステータスが「Under Investigation」から「Pending Decision」などの意思決定ステータスに変わった時点から推定します。 | ||
| 重要な理由 調査の完了は、意思決定と支払額確定の段階を開始するための主要なマイルストーンです。ここでの遅延は、後続プロセスに大きな影響を及ぼします。 入手先 請求ステータスが「investigation」状態から「review」または「decision」状態に変わった時刻から推定します。 取得 調査アクティビティの終了を示す請求ステータスの変更から導出します。 イベントタイプ inferred | |||
| 調査を開始 | 保険金請求の正式な調査段階が始まったことを示すアクティビティです。通常、請求ステータスが「Under Investigation」または同様の状態に変わった時点から推定します。 | ||
| 重要な理由 リソースを多く必要とする段階の開始を示します。調査の所要時間を測定することは、「Average Investigation Duration」KPIの算出に重要であり、プロセスの重要な部分を管理するのに役立ちます。 入手先 メインの請求ステータスフィールドが「Investigation in Progress」または「Pending Inspection」に更新された時刻から推定します。 取得 調査アクティビティの開始を示す請求ステータスの変更から導出します。 イベントタイプ inferred | |||
| 追加情報を依頼 | 査定担当者が追加情報が必要だと判断し、保険契約者または第三者に依頼を送信した際に発生するアクティビティです。通常、システムのコミュニケーションまたは文書連絡モジュールに関連付けられた明示的なイベントです。 | ||
| 重要な理由 このアクティビティの頻度が高い場合、初期データ収集プロセスに問題がある可能性があります。また、大きな待ち時間が発生し、全体のサイクルタイムにも影響します。 入手先 送信した文書連絡(例:書簡、メール)に関するログ、またはDuck Creek Claimsの「Request for Information」取引から取得します。 取得 情報を依頼する文書連絡またはタスクが生成された際に記録されます。 イベントタイプ explicit | |||
| 追加情報を受領 | 依頼した情報を受け取り、保険金請求の処理を再開できる状態になったことを示します。査定担当者が手動で記録する場合や、デジタルポータルから情報が提出された際に自動記録される場合があります。 | ||
| 重要な理由 「Information Requested」から「Information Received」までの時間は、重要な待機期間です。この所要時間を分析することで、外部依存関係とコミュニケーション上のボトルネックを特定できます。 入手先 文書管理システムとの連携から明示的なイベントとして取得するか、書類を受け取った際に査定担当者が手動で記録したログまたはステータス変更から取得します。 取得 書類のアップロード時、または査定担当者による手動入力時にイベントとして記録されます。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- Duck Creek Data Hub Configuration Utilityにアクセス:Duck Creek環境にログインし、Data Hubアプリケーションを開きます。データのエクスポート設定を作成または変更するには、適切な権限が必要です。
- 新しいデータエクスポートジョブを作成:Data Hubユーティリティで、新しいエクスポートジョブの作成を開始します。ProcessMind_Claims_Event_Log_Exportなど、内容が分かる名前を付けます。
- データソースを定義:プライマリのData Hub SQLデータベースに接続するようジョブを設定します。サーバー名、データベース名、対象スキーマへの読み取り権限を持つユーザーの認証情報を入力します。
- 抽出クエリを入力:エクスポートジョブのクエリ定義セクションを開きます。下記のクエリセクションにあるスクリプト全体をコピーし、クエリエディターに貼り付けます。
- クエリパラメーターを設定:設定画面のパラメーターセクションで、クエリ内の@StartDateと@EndDateに値を設定し、抽出対象期間を指定します。例:'2023-01-01'と'2023-12-31'。
- 出力列をマッピング:出力ファイルの設定を行います。SELECT文で定義した列(ClaimId、ActivityName、EventTimeなど)が、出力ファイルの列に正しく対応していることを確認します。出力ファイルのヘッダー名は、これらの名前と完全に一致させます。
- 出力ファイルを設定:出力形式にCSVを指定します。区切り文字はカンマ(,)、文字コードはUTF-8に設定し、ProcessMindとの互換性を確保します。
- 保存先を定義:生成したCSVファイルを保存するファイルパスまたはネットワーク上の場所を指定します。システムにその場所への書き込み権限があることを確認します。
- エクスポートジョブをスケジュール:ジョブの実行スケジュールを設定します。初回の分析では手動実行で構いません。継続的に監視する場合は、毎日または毎週などの定期実行を設定します。
- 実行してファイルを取得:ジョブを実行してイベントログファイルを生成します。完了後、手順8で指定した保存先からCSVファイルを取得します。
- アップロード前の準備:ProcessMindにアップロードする前にCSVファイルを開き、最終確認を行います。ヘッダーが正しいこと、日付形式が統一されていること(YYYY-MM-DD HH:MI:SS)、データが想定どおりであることを確認します。
設定
- 前提条件:Duck Creek Data Hubモジュールへのアクセスが必要です。エクスポートジョブを実行するユーザーまたはサービスアカウントには、Data Hubの基盤データベーステーブル(例:[DataHubSchema].[FactClaimTransaction]、[DataHubSchema].[DimClaim]、[DataHubSchema].[DimStatusHistory])への読み取り権限が必要です。
- 日付範囲の設定:クエリでは@StartDateと@EndDateパラメーターを使用します。抽出期間を定義するため、必ず値を設定してください。初回分析では、完了済み案件と進行中の案件を十分に含められるよう、6~12か月の期間を推奨します。
- フィルタリング:クエリのCommon Table Expression(CTE)内には、/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */というプレースホルダーがあります。特定の事業分野(例:'Personal Auto'、'Commercial Property')で絞り込む場合は、この行のコメントを外して修正します。データ量を減らし、分析対象を明確にできます。
- Data Hubの更新サイクル:Data Hubのデータには遅延があります。リアルタイムデータではなく、通常は夜間などのスケジュールに従って更新されます。抽出データは、最後に正常完了したData Hubの更新時点の内容になります。
- 出力形式:エクスポートジョブは、できればCSVなどのフラットファイルを生成するよう設定します。データ項目内のカンマを処理できるよう、テキスト修飾子は二重引用符(")に設定してください。
a サンプルクエリ sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; 始める準備はできていますか?
このテンプレートがあれば、保険金請求処理の最適化を始めるために必要な準備が整います。今すぐデータ分析を始め、業務改善につながる発見を見つけ出してください。
請求案件の滞留を解消:今すぐ保険金請求処理を最適化
ストレートスルー処理率70%を達成し、コストと遅延を削減します。
14日間無料でお試しいただけます。クレジットカードは必要ありません。