データテンプレート:請求処理
保険金請求プロセス用データテンプレート
- 収集を推奨する属性
- 追跡すべき主要アクティビティ
- Duck Creek Claims 用データ抽出ガイド
保険金支払業務の属性
| 名前 | 説明 | ||
|---|---|---|---|
アクティビティ名 ActivityName | 請求で特定時点に発生したビジネスアクティビティまたはイベントの名称。 | ||
説明 この属性は、請求プロセス内で実行される個々のステップやタスク(例:'Claim Submitted'、'Adjuster Assigned'、'Payment Issued')を表します。各アクティビティは請求ライフサイクル上の明確なポイントです。 これらのアクティビティの順序や頻度を分析することがProcess Miningの核心です。プロセスモデルの発見、ボトルネックの特定、手戻りループの検出、標準モデルとの逸脱分析が可能になります。 その重要性 Activity Nameはプロセスフローの各ステップを定義する項目で、請求プロセスの発見・分析・モニタリングの土台になります。 取得元 Duck Creek Claims 内のイベントログ、トランザクション名、ステータス変更記録などから導出するのが一般的です。複数のソースフィールドやテーブルからのマッピングが必要になる場合があります。 例 請求の提出査定担当者の割り当て調査開始支払命令発行請求のクローズ | |||
イベント時刻 EventTime | 特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。 | ||
説明 Event Time は、請求のライフサイクルに記録された各アクティビティの正確な日時を提供します。この時間情報はパフォーマンス分析に不可欠です。 分析では、このタイムスタンプを用いてアクティビティ間のサイクルタイムや待機時間を算出し、案件全体の所要時間を測定し、期間別のプロセスパフォーマンスを評価します。時間に基づくあらゆる指標の土台となるデータです。 その重要性 この timestamp は、サイクルタイムや所要時間など時間ベースの各種指標を算出するうえで不可欠で、パフォーマンス分析やボトルネックの特定を可能にします。 取得元 Duck Creek Claims のイベント/トランザクションログに関連する標準的な timestamp フィールドです。「CreateDate」「Timestamp」「EventDate」などのフィールドを確認してください。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
請求ID ClaimId | 1件の保険金請求を一意に識別するIDで、主要なケース識別子として機能します。 | ||
説明 Claim IDは、1件の保険金請求に紐づくすべてのイベントやアクティビティを、申請からクローズまで一貫して結び付ける基礎キーです。これにより、請求のライフサイクル全体を通じて追跡できます。 プロセスマイニングの分析では、ケースビューを構成するための必須属性で、各請求の旅路をたどり、エンドツーエンドのサイクルタイムを測定し、プロセスのバリアントを分析できます。 その重要性 プロセス内の関連イベントをすべて結びつけ、クレームのライフサイクルをエンドツーエンドで把握するために不可欠な Case ID です。 取得元 Duck Creek Claims の主要なクレームエンティティ/テーブルにおけるプライマリキーです。具体的なテーブル名・フィールド名はシステムドキュメントを参照してください。 例 CL-2023-001234CL-2023-005678CL-2024-009101 | |||
担当アジャスター AssignedAdjuster | そのアクティビティで請求を担当したアジャスターの氏名またはID。 | ||
説明 この属性はアクティビティを実行したユーザー/リソースを識別します。案件が異なる担当者やチームへ引き継がれるにつれて変更されます。 リソースのパフォーマンス、ワークロードの分散、ハンドオフ分析に不可欠です。査定担当者の処理量、負荷のばらつき、ボトルネックの特定に焦点を当てたdashboardでは、業務の割り当てと処理状況を把握するうえで本属性が重要な役割を果たします。 その重要性 リソースのパフォーマンス、負荷分散、連携パターンを分析でき、ボトルネックやトレーニング課題の特定に役立ちます。 取得元 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 のドキュメントを参照してください。これはメインの請求レコードにおける基本項目です。 例 オープン保留 - 情報待ちクローズ - 示談成立クローズ - 不承認 | |||
請求の重大度 ClaimSeverity | 請求の金銭面・業務面の複雑度を表す区分(低・中・高など)。 | ||
説明 請求の重大度は、想定される影響度や複雑さの目安です。初期損害見積もり、事故の性質、事前に定義した業務ルールなどに基づいて判定します。 この属性はパフォーマンス分析に不可欠です。重大度が高い請求は、工程数が多く処理時間も長く、専門リソースを要する傾向があります。重大度別にKPIをセグメントすることで、現実的な目標設定ができ、複雑性が効率や結果に与える影響を正しく把握できます。 その重要性 請求を複雑さでセグメント化でき、きめ細かなパフォーマンス分析や、サイクルタイムやコストの現実的なベンチマーク設定が可能になります。 取得元 Duck Creek Claims のドキュメントを参照してください。専用のフィールドとして存在する場合と、初期損害引当額から導出される場合があります。 例 低中高大規模災害 | |||
請求種別 ClaimType | 保険金請求のカテゴリー(自動車、財物、賠責など)。 | ||
説明 請求種別は、保険種目や損害の内容に基づいて請求を分類します。データのセグメント化と分析における基本的な軸です。 この属性により、請求種別ごとのプロセス性能を比較できます。例えば、『自動車 - 全損』は『財物 - 漏水』とはプロセスもKPIも大きく異なります。種別別に分析することで文脈が明確になり、意味のある比較や、実態に合わせた改善施策の立案が可能になります。 その重要性 請求タイプはプロセスやSLA、複雑さがしばしば異なるため、分析をセグメント化するうえで不可欠な軸です。 取得元 Duck Creek Claims のドキュメントを参照してください。これはメインの請求レコードの主要項目です。 例 自動車保険(車両・衝突)企業向け財物 - 火災労災補償一般賠償責任保険 | |||
部署 Department | その時点でアクティビティまたは請求を担当する部門・チーム。 | ||
説明 この属性は、請求を扱う機能グループ/部門(例:'Initial Intake'、'Investigation Unit'、'Settlement Team')を示し、プロセスフローに組織的な背景を与えます。 部門別の分析は集計レベルでのパフォーマンス把握に不可欠です。部門間のボトルネックの特定、チーム効率の測定、組織横断の業務フローの理解に役立ちます。 その重要性 機能領域別のパフォーマンス分析が可能になり、部門横断のハンドオフやチームごとのボトルネックを可視化します。 取得元 Duck Creek Claims のドキュメントを参照してください。多くの場合、割り当てられたユーザーのプロファイルや、キュー/ワークグループの割当情報に紐づきます。 例 自動車保険金請求財物保険(大口損害)特別調査部門(SIU)支払い処理 | |||
ソースシステム SourceSystem | イベントデータを抽出したシステム。 | ||
説明 この属性は請求データの発生元アプリケーションを示します。本コンテキストでは常に 'Duck Creek Claims' となります。 単一システム由来で冗長に見えても、データガバナンスやトレーサビリティ、将来的な複数システム統合時に不可欠です。データの出所や構造の背景を明確にします。 その重要性 データの来歴と文脈を提供します。複数システムが連携する環境では、データガバナンスやトラブルシューティングの観点で特に重要です。 取得元 データの出所を示すために、抽出・変換の過程で付与される固定値であることが一般的です。 例 Duck Creek Claims | |||
最終データ更新 LastDataUpdate | ソースシステムからの最新データ更新時刻を示すタイムスタンプ。 | ||
説明 この属性はデータセットの最終更新日時を示し、分析対象データの鮮度を把握する基準になります。 dashboardや分析では、洞察の新しさをユーザーに伝えるために用いられ、最新の取引がプロセスビューに含まれているかの期待値の調整に役立ちます。 その重要性 分析結果の解釈や迅速な意思決定に不可欠な、データの鮮度をユーザーに知らせます。 取得元 この timestamp はデータ抽出・変換・ロード(ETL)過程で生成され、通常はデータセットのメタデータに保存されます。 例 2024-05-21T02:00:00Z | |||
処理時間 ProcessingTime | 特定アクティビティの実作業時間(End Time − Start Time)。 | ||
説明 Processing Time(アクティブ時間/ハンドリング時間)は、特定のタスクに対してリソースが実際に作業していた時間を示します。各アクティビティのEndTimeからStartTimeを差し引いて算出します。 この指標はパフォーマンス分析の中核です。長時間実行されるタスクによる非効率(高いProcessing Time)と、リソースや情報待ちによる遅延(高いWaiting Time)を見分けるのに役立ちます。真のボトルネックを特定するうえで不可欠です。 その重要性 各アクティビティの実作業時間を計測し、ボトルネック分析で“非効率なタスク”による遅延と“待ち時間”による遅延を切り分けるのに役立ちます。 取得元 これはソースシステムのフィールドではありません。各アクティビティについて「EndTime」から「StartTime」を差し引いて算出します。 例 360086400300 | |||
却下理由 RejectionReason | 請求が否認・却下された具体的な理由。 | ||
説明 クレームを否認する決定が下された場合、その根拠となる理由を示す属性です。通常は、あらかじめ定義されたコードまたは説明のリストから選択します。 否認理由の分析は「Claim Decision & Rejection Insights」dashboard にとって不可欠です。申請内容の共通不備、潜在的な不正の兆候、約款表現の不明瞭さなどを特定でき、初期受付プロセスや引受ルールの改善につながります。 その重要性 請求が却下される理由を可視化し、受付プロセスの改善、不備のある申請の削減、トレーニングが必要な領域の特定につながる実行可能なインサイトを提供します。 取得元 Duck Creek Claims のドキュメントを参照してください。通常、請求のステータスが 'Denied' などに変更された際にこのフィールドが設定されます。 例 補償対象外保険契約の失効重複請求不正の疑い | |||
手戻り IsRework | そのアクティビティが手戻り(リワーク)ループに含まれるかを示す計算フラグ。 | ||
説明 このブール属性は、他の異なるアクティビティを挟んで同一アクティビティが再度発生した場合に true となります。例:'Loss Assessed' から 'Investigation Started' に戻る場合。 手戻りの定量化・分析に不可欠で、'Claim Rework Rate' KPIや 'Claim Rework & Reprocessing Patterns' dashboardを支援します。手戻りを含むアクティビティやケースを直接絞り込み・強調表示でき、プロセスの非効率や品質課題の特定に役立ちます。 その重要性 アクティビティ単位で手戻りを定量化し、プロセスの非効率の原因と影響を測定・可視化・分析しやすくします。 取得元 これはソースシステムのフィールドではありません。ケース内で繰り返されるアクティビティのシーケンスを検出するアルゴリズムにより、データ準備時に算出します。 例 truefalse | |||
支払額 SettlementAmount | 請求の支払いとして最終的に合意された金額。 | ||
説明 この属性は、支払い承認された支払額(示談額)を記録します。支払いに至った各請求の成果指標となる重要な金額です。 財務分析や 'Payment Authorization & Issuance Time' などのdashboardで重要な役割を果たします。初期の 'Loss Amount' と比較して引当の妥当性を検証するなど、請求プロセスの財務的帰結を理解するうえでの基盤となります。 その重要性 請求の主要な財務結果を示し、財務報告や初期損害見積もりの精度分析に不可欠です。 取得元 Duck Creek Claims のドキュメントを参照してください。通常、この情報は請求に紐づく財務トランザクションまたは支払い関連のテーブルに格納されます。 例 1450.7522000.00115800.20 | |||
期限内解決 IsOnTimeResolution | 請求が目標解決日以内(当日を含む)にクローズされたかを示す計算フラグ。 | ||
説明 このブール属性は、当該請求の 'Claim Closed' のタイムスタンプと 'ResolutionTargetDate' を比較して導出します。期日内なら true、遅延なら false と判定します。 本属性は 'On-Time Claim Resolution Rate' KPIを直接支えます。dashboardでのSLA遵守状況の集計・可視化を容易にし、遅延請求の共通点(例:特定の請求タイプ、部門、プロセスパス)を特定するドリルダウン分析を可能にします。 その重要性 請求単位でのSLA遵守状況を直接測定でき、期限超過案件の強力なフィルタリングや原因分析が可能になります。 取得元 これはソースシステムのフィールドではありません。データ準備時に、最終アクティビティの timestamp と「ResolutionTargetDate」フィールドを比較して算出します。 例 truefalse | |||
終了時刻 EndTime | アクティビティの完了時刻を示すタイムスタンプ。 | ||
説明 この属性はアクティビティの完了時刻を表します。StartTimeが開始時刻を示すのに対し、EndTimeは当該タスクの所要時間計算のもう一方の端点になります。 Process Miningでは、アクティビティの開始・終了の双方を持つことで、パフォーマンス分析が格段に深まります。タスクの実作業時間('Processing Time')とタスク間の待ち時間('Waiting Time')を正確に算出でき、ボトルネックの特定に欠かせません。 その重要性 アクティビティの正確な処理時間を算出し、実作業時間と待機時間を切り分けられます。正確なボトルネック分析に不可欠です。 取得元 イベントログ内に独立したタイムスタンプ項目として保持されている場合もあれば、同一ケースの次アクティビティのStartTimeから導出することもできます。 例 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
自動処理 IsAutomated | 人手を介さずシステムが自動実行したかどうかを示すブール型フラグ。 | ||
説明 このフラグは、人手で完了したタスクと、通知の自動送信、初期データ検証、straight-through processing のようにシステム自動化で実行されたタスクを区別します。 この属性の分析は、請求プロセスの自動化レベルを把握する鍵です。自動化施策の効果測定、さらなる自動化機会の発見、そして自動ステップが期待どおりに機能し下流に問題を生んでいないかの確認に役立ちます。 その重要性 自動化の効率・コストへの影響を測定し、ストレートスルー処理(STP)の機会を特定するのに役立ちます。 取得元 この情報は、イベントに紐づく 'user'(例:'SYSTEM'、'BATCH')や、イベントレコード上の専用フラグから推定されることがあります。 例 truefalse | |||
解決目標日 ResolutionTargetDate | SLAや社内目標に基づく、請求の解決予定日。 | ||
説明 この属性は請求クローズの期限を保持します。規制要件、SLA、社内KPIなどに基づき、請求種類や重大度により異なる場合があります。 'On-Time Claim Resolution Rate' KPIの算出基礎であり、'Claim Resolution Target Adherence' dashboardを支える情報です。SLA違反のリスクがある請求を事前に監視し、優先度付けに役立ちます。 その重要性 SLAや社内目標に対するパフォーマンスを定量測定でき、顧客満足やコンプライアンスに直結します。 取得元 Duck Creek Claims のドキュメントを参照してください。特定のSLA日付フィールドとして保持されるか、請求の受付日と業務ルールに基づいて算出される場合があります。 例 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
証券番号 PolicyNumber | 請求が提出された保険契約の一意のID。 | ||
説明 この属性は請求を元の保険契約に紐づけます。補償範囲、契約条件、顧客情報といった背景を提供します。 プロセスフロー分析で常に使うとは限りませんが、Policy Numberは請求データの拡張に極めて有用です。ポリシーや顧客データと結合し、顧客セグメント、契約種別、契約の経過年数によってプロセス性能がどう異なるかを分析でき、より俯瞰的なビジネス視点を得られます。 その重要性 請求を顧客や契約にひも付けることで、プロセスのパフォーマンスが顧客セグメントや保険種別ごとに与える影響を幅広く分析できます。 取得元 Duck Creek Claims のドキュメントを参照してください。これはメインの請求エンティティにおける標準的な参照フィールドです。 例 PA-987654321CP-123456789WC-555444333 | |||
保険金支払業務のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
支払命令発行 | このアクティビティは、保険金支払いのための決済が実行されたことを示します。小切手やEFTなどで支払いを送金・発送した時点で生成される、明確なイベントです。 | ||
その重要性 承認済みクレームに対する金銭的義務の履行完了を示します。「Payment Authorized」から「Payment Issued」までの時間は、財務部門の業務効率を表します。 取得元 Duck Creek Claims の財務トランザクションテーブルから取得します。特定のトランザクションコードとタイムスタンプで、すべての支払いが記録されています。 取得 支払いを処理すると、その都度、個別の財務トランザクションのログエントリが作成されます。 イベントタイプ explicit | |||
支払実行許可 | 算出された支払額の正式承認を示します。多くの場合、管理者などの承認権限者が関与する独立したステップで、明示的な承認トランザクションとして記録されます。 | ||
その重要性 支払い前の重要な管理ポイントで、ボトルネックになり得ます。「Claim Decision Made」からここまでの所要時間は、KPI「Average Claim Approval Time」で計測します。 取得元 特定の権限を持つユーザーが支払いを承認する、workflow または財務モジュール上の明示的なイベントであることが一般的です。承認ログに記録されます。 取得 workflow やトランザクションログに記録された明確な承認イベントです。 イベントタイプ explicit | |||
請求のクローズ | 最終アクティビティであり、支払い実行または和解後にクレームファイルを事務的にクローズすることを示します。ステータスが最終的に「Closed」へ更新された時点で記録されます。 | ||
その重要性 本プロセスの完了を示すアクティビティです。「Average End-to-End Claim Cycle Time」などの所要時間KPIを算出する際の終点です。 取得元 請求のメインデータテーブルで最終ステータスが「クローズ」または「示談成立」に変更されたタイムスタンプから推定します。 取得 請求の最終ステータスが「クローズ」に設定されたことから推定します。 イベントタイプ inferred | |||
請求の不承認 | このアクティビティは、請求が正式に否認(不承認)となった場合の別の終了形を表します。請求の最終ステータスが 'Denied' または 'Rejected' に設定された時点で記録されます。 | ||
その重要性 これは個別に分析すべき重要なアウトカムです。いつ・なぜ請求が否認されるのかを把握することで、受付プロセスの改善やコンプライアンス管理に役立ちます。 取得元 請求エンティティテーブルにおいて、最終ステータスが「否認」「却下」「不払いクローズ」に変更されたタイムスタンプから推定します。 取得 請求の最終ステータスが否認理由を示していることから推定します。 イベントタイプ inferred | |||
請求の提出 | 最初のイベントであり、保険会社が損害の第一報(FNOL: First Notice of Loss)を受領したことを表します。代理店や契約者が初期クレーム情報をシステムに入力した際に、明示的なトランザクションとして記録されるのが一般的です。 | ||
その重要性 このアクティビティは、保険金請求ライフサイクル全体の起点です。このイベントから他のイベントまでの経過時間を分析することで、総処理時間や受付効率を把握できます。 取得元 新しいクレームレコードが Duck Creek Claims に初めて作成された際、クレームまたは FNOL のログテーブルに記録される明示的なイベントであることが一般的です。 取得 新規の請求レコード作成時に記録されるイベントです。 イベントタイプ explicit | |||
請求の決定 | このアクティビティは 'Approved'、'Partially Approved'、'Denied' などの正式な判断を表します。最終決定ステータスへの変更から見て取れる重要なマイルストーンです。 | ||
その重要性 重要な意思決定のマイルストーンです。この時点に至るまでの所要時間と決定の結果は、プロセス分析や効率化の核心となる要素です。 取得元 専用の「請求判断」または「請求ステータス」フィールドが「承認」「否認」などの終端状態に変更されたことから推定します。この変更時点のタイムスタンプを取得します。 取得 請求の主要ステータスまたは判断フィールドの更新から推定します。 イベントタイプ inferred | |||
初期審査完了 | 担当アジャスターによる最初の包括的レビューが完了したことを示します。通常は、担当割当後にステータスが「Assigned」から「Under Review」や「Investigation」に変わったタイミングで推定します。 | ||
その重要性 アジャスターの初動までの時間を測る指標となり、業務の滞留の兆候を示すことがあります。人手による最初の重要なチェックポイントです。 取得元 請求ステータスの変更(例:「初期審査完了」「情報待ち」への遷移)から推定します。このステータス変更のタイムスタンプを使用します。 取得 アジャスター割り当て後の請求ステータス変更から推定します。 イベントタイプ inferred | |||
損害査定完了 | 調査結果に基づいて引当金が設定または更新されるタイミングを示すマイルストーンです。クレームの財務影響の見積りを意味し、引当額が入力・調整された時点で記録されます。 | ||
その重要性 これはプロセス上の重要な財務チェックポイントです。発生タイミングを分析することで、財務評価のスピードと精度を把握できます。 取得元 多くの場合、Duck Creek Claims のクレーム財務トランザクションログや引当履歴テーブルに記録される明示的な財務トランザクションです。 取得 損害準備金(リザーブ)の設定・更新時に記録される会計トランザクション。 イベントタイプ explicit | |||
支払額を算出 | 承認決定後に実施される、最終的な示談金/支払額の計算を表すアクティビティです。明示的なステップとして記録される場合と、システムの財務モジュールでの支払額確定から推定される場合があります。 | ||
その重要性 このアクティビティは「Settlement Rework Rate」KPIの測定に不可欠です。1件の請求でこのイベントが複数回発生している場合、精算フェーズでの非効率、誤り、あるいは交渉が起きているサインです。 取得元 トランザクションログの明示的な記録、または請求の財務データにある『Settlement Amount(示談金額)』フィールドの更新から推定します。主なソースは当該フィールドの監査ログです。 取得 最終支払額を算出して保存した時点で記録されるイベント。 イベントタイプ explicit | |||
査定担当者の割り当て | このイベントは、登録済みの請求に査定担当者(ハンドラー)がアサインされたことを記録します。システム上で割り当てが記録され、明確な引き継ぎポイントとライフサイクルにおける責任の所在が確立されます。 | ||
その重要性 リソース配分やアジャスターの業務負荷、割り当てに伴う遅延の分析に不可欠。待ち時間が生まれやすい重要なハンドオフポイントです。 取得元 メインのクレームデータテーブルにある「Assigned Adjuster」フィールドの更新として追跡します。このフィールドの履歴または監査ログから timestamp を取得します。 取得 査定担当者フィールドが入力または変更されたときに、監査ログに記録されます。 イベントタイプ explicit | |||
調査完了 | 調査活動が完了したことを示します。必要な事実がすべて揃った状態です。通常は、ステータスが「Under Investigation」から「Pending Decision」などの判断フェーズへ移行した時点で推定します。 | ||
その重要性 調査完了は、次の意思決定や示談(支払い)工程に進めるための重要なマイルストーンです。ここが滞ると後続工程に大きな影響が出ます。 取得元 請求ステータスが「調査」系の状態から「審査」または「判断」系の状態へ更新されたタイムスタンプから推定します。 取得 調査活動の終了を示す請求ステータスへの変更から導出します。 イベントタイプ inferred | |||
調査開始 | このアクティビティは、正式な調査フェーズの開始を示します。請求ステータスが 'Under Investigation' などへ変更されたことから推測されることが多いです。 | ||
その重要性 多くのリソースを要するフェーズの開始を示します。調査期間の計測はKPI「Average Investigation Duration」の基礎となり、プロセスの重要領域を適切に管理する助けになります。 取得元 主要ステータスが「調査中」または「査定待ち」へ更新されたタイムスタンプから推定します。 取得 調査活動の開始を示す請求ステータスへの変更から導出します。 イベントタイプ inferred | |||
請求の登録 | 提出された請求を正式に受理・登録するタイミングを示し、この時点で一意のClaim IDが付与されます。初期データの検証が通った後に自動で発生するシステムイベントであることが一般的です。 | ||
その重要性 請求の開始を確定し、以降の工程(例:アジャスターの割り当て)を開始します。提出から登録までの時間は、初期データの品質やシステム負荷の問題を示す指標になります。 取得元 メインの請求エンティティテーブルで、主要な Claim ID が発番され、ステータスが「保留」または「提出済み」から「オープン」または「登録済み」に遷移したタイムスタンプから推定します。 取得 主請求レコードの作成日時、またはステータスが 'Open' に変更された時点から導出します。 イベントタイプ inferred | |||
追加情報の依頼 | このアクティビティは、査定担当者が追加情報が必要だと判断し、契約者または第三者に照会を送付したときに発生します。多くの場合、システムのコミュニケーション/コレスポンデンス機能に紐づく明示的イベントとして記録されます。 | ||
その重要性 このアクティビティの発生頻度が高い場合、初期の情報収集プロセスに課題がある可能性があります。また、大きな待ち時間を生み、全体のサイクルタイムに影響します。 取得元 送信コミュニケーション(郵送文書、メールなど)に関するログ、または Duck Creek Claims の特定トランザクション『Request for Information(情報依頼)』から取得します。 取得 情報提供依頼の文書やタスクが作成された際に記録されるイベント。 イベントタイプ explicit | |||
追加情報の受領 | 追加情報の受領を示すイベント。これにより処理が再開されます。査定担当者が手動で記録する場合も、デジタルポータル経由で提出された情報をもとに自動記録される場合もあります。 | ||
その重要性 「Information Requested」から「Information Received」までの時間は重要な待ち時間です。この期間を分析することで、外部依存やコミュニケーション上のボトルネックを特定できます。 取得元 これは文書管理システム連携からの明示的イベント、または書類受領時に査定担当者が行う手動のログ記録・ステータス変更として記録されることがあります。 取得 査定担当者が書類をアップロードまたは手入力した際に記録されるイベント。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- Duck Creek Data Hub 構成ユーティリティにアクセス: Duck Creek 環境にログインし、Data Hub アプリケーションに移動します。データエクスポート設定を作成・変更できる権限が必要です。
- 新規データエクスポートジョブの作成: Data Hub ユーティリティ内で新しいエクスポートジョブを作成します。ProcessMind_Claims_Event_Log_Export など、わかりやすい名前を付けてください。
- データソースの定義: ジョブを Data Hub のメイン SQL データベースに接続するよう設定します。サーバー名、データベース名、関連スキーマに読み取り権限を持つユーザーの資格情報を指定します。
- 抽出クエリの入力: エクスポートジョブのクエリ定義セクションを開き、下の query セクションにあるスクリプト全文をコピーしてクエリエディタに貼り付けます。
- クエリパラメータの設定: パラメータ設定画面で、抽出期間を指定する @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)、データが期待どおりかを確認してください。
設定
- Prerequisites: Duck Creek Data Hub モジュールへのアクセスが必要です。エクスポートジョブを実行するユーザーまたはサービスアカウントには、Data Hub の基盤となるデータベーステーブル(例:[DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory])に対する読み取り権限が必要です。
- Date Range Configuration: クエリは @StartDate と @EndDate パラメータを使用します。抽出期間を定義するため、これらの設定が重要です。初回分析では、完了案件と進行中案件を十分に含めるため 6~12か月を推奨します。
- Filtering: 共通テーブル式(CTE)内に /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ のプレースホルダーがあります。特定のラインで絞り込む場合は、この行のコメントを外して編集してください(例:'Personal Auto'(個人自動車)、'Commercial Property'(商業用物件))。これによりデータ量を抑え、分析の焦点を絞れます。
- Data Hub Refresh Cycle: Data Hub のデータはリアルタイムではなく、通常はスケジュール(例:夜間)でリフレッシュされます。抽出データは、直近の Data Hub リフレッシュ時点までの内容です。
- Output Format: エクスポートジョブはフラットファイル(推奨:CSV)を出力するよう設定してください。データ内のカンマに対応するため、囲み文字は二重引用符(")に設定してください.
a クエリ例 config
`config
-- 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;
`