収益サイクル管理データテンプレート
収益サイクル管理データテンプレート
- 収集を推奨する項目
- 追跡すべき主要アクティビティ
- Oracle Health レベニューサイクル向け抽出ガイダンス
収益サイクル管理属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクルプロセス内で発生した特定のステップまたはイベントの名称。 | ||
| 説明 この属性は、請求イベントのライフサイクル内で実行された各アクティビティの名称を記録します。例としては、「請求情報取り込み」、「支払者に請求提出済み」、「支払い計上済み」などがあります。これらのアクティビティは、発見されたプロセスマップのノードを形成します。 アクティビティの順序と頻度を分析することは、プロセスマイニングの核となります。この属性は、最も一般的なプロセスパスを特定し、標準手順からの逸脱を発見し、収益サイクルの運用フローを理解するのに役立ちます。 その重要性 プロセス内の 取得元 通常、Oracle Healthの収益サイクルの異なる段階に関連付けられたイベントログ、ステータス変更記録、または特定のトランザクションテーブルから導出されます。 例 請求生成済み送金受領済み否認再審査済みアカウント閉鎖済み | |||
| イベントのタイムスタンプ EventTimestamp | 活動がシステムに記録された正確な日付と時刻。 | ||
| 説明 この属性は、各アクティビティのタイムスタンプを提供し、それが正確に発生した瞬間をマークします。特定の請求イベントにおける収益サイクル内のイベントのタイミングと順序を理解するために不可欠です。 分析において、イベントタイムスタンプは、アクティビティを時系列に並べ、異なるステップ間の期間とサイクルタイムを計算し、ボトルネック分析を実行するために使用されます。これは、「請求提出済み」と「送金受領済み」の間の遅延の特定など、すべての時間ベースのプロセスマイニングメトリクスの基盤となります。 その重要性 このタイムスタンプは、イベントの順序付け、サイクルタイムや期間などのすべてのパフォーマンス指標の計算、およびプロセスボトルネックの特定に不可欠です。 取得元 Oracle Health レベニューサイクル内の各取引またはイベントログテーブルには、レコードが作成されたか、イベントが発生した時期を示す 例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| 請求イベント BillingEvent | 請求を生成する単一のサービスまたは製品提供のユニークな識別子であり、収益サイクルプロセスのケース識別子として機能します。 | ||
| 説明 請求イベントは、個別の請求可能項目に対する請求情報取り込みから口座閉鎖までのすべてのアクティビティをリンクする主要なケース識別子として機能します。各請求イベントは収益サイクルプロセスのユニークなインスタンスを表し、請求提出、支払い計上、潜在的な否認や調整などのさまざまな段階を通じたその過程を包括的に追跡できます。 プロセスマイニング分析において、この属性はエンドツーエンドのプロセスフローを再構築するための基本です。これにより、プロセスバリアントの可視化、アクティビティ間のサイクルタイムの計算、および特定の請求イベントに関連するボトルネックや逸脱の特定が可能になります。 その重要性 これは、請求可能なサービスの全ライフサイクルを追跡するための必須キーであり、すべてのプロセスフロー分析とパフォーマンス測定を可能にします。 取得元 この識別子は、Oracle Health Revenue Cycle内の主要な請求または料金トランザクションテーブルに存在するユニークキーである必要があります。料金イベントの主キーを特定するには、システムドキュメントを参照してください。 例 BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| ユーザー UserPerformingAction | そのアクティビティを実行した担当者のユーザーIDまたは氏名を示します。 | ||
| 説明 この属性は、プロセス内の特定のアクティビティの実行を担当する従業員または自動システムユーザーを識別します。これは、ワークロードの分散、リソースのパフォーマンス、およびトレーニングニーズを理解するために不可欠です。 分析において、この属性は、プロセスマップをユーザーまたはチームでフィルタリングしたり、異なるリソース間のパフォーマンスを比較したり、「請求部門ワークロード」ダッシュボードのワークロードを分析したりすることを可能にします。これにより、トップパフォーマーや追加のサポートまたはトレーニングが必要な個人を特定するのに役立ちます。 その重要性 プロセス活動を特定のユーザーまたはチームにリンクさせ、ワークロード分析、パフォーマンス比較、およびトレーニング機会の特定を可能にします。 取得元 ユーザーIDフィールド（例：「CREATED_BY」、「USER_ID」）は、Oracle Healthの各モジュールのトランザクションテーブルに通常存在します。 例 j.doeasmithBillingBot_AUTOk.williams | |||
| 否認理由コード DenialReasonCode | 支払い者によって請求が拒否された理由を示す標準化されたコードです。 | ||
| 説明 支払者が請求を否認する場合、「対象外サービス」や「重複請求」など、否認を説明する理由コードを提供します。この属性は、そのコードと関連する説明を捕捉します。 否認理由の分析は、収益サイクルを改善するための基本です。これにより、組織はコーディングや患者の資格の問題などの一般的なパターンを特定し、将来の否認を防ぐための是正措置を実施できます。これは、クリーンクレーム率に直接影響し、手戻りコストを削減します。 その重要性 請求否認の根本原因を提供し、クリーン請求率を高め、収益回収を加速するための的を絞った改善を可能にします。 取得元 この情報は支払者からの電子送金通知（ANSI 835ファイル）で受領され、Oracle Healthの請求または送金テーブルに保存されるべきです。 例 CO-16: 裁定に必要な情報が請求/サービスに不足しています。PR-96: 非対象料金。CO-18: 請求/サービスが重複しています。 | |||
| 患者区分 PatientClass | 入院患者または外来患者など、患者受診の分類。 | ||
| 説明 この属性は、請求を発生させた患者の受診または遭遇のタイプを分類します。一般的な分類には、入院患者、外来患者、緊急患者、および再受診患者が含まれます。患者クラスはしばしば、全体の請求および請求提出プロセスを決定します。 異なる患者クラスは、異なるプロセスパスをたどり、異なるコンプライアンス要件を持っています。この属性に基づいてプロセスを分析することは、これらのバリエーションを理解し、改善イニシアチブを調整し、各クラスで正しい手順が遵守されていることを保証するのに役立ちます。 その重要性 複雑さ、期間、および請求要件が異なる個別のプロセスフロー（例：入院患者と外来患者）を分離します。 取得元 これは、Oracle Healthにおける患者の受診または入院記録に関連付けられた標準フィールドです。 例 入院外来患者緊急定期仕訳 | |||
| 支払人名 PayerName | 支払い責任のある保険会社または第三者支払者の名称。 | ||
| 説明 この属性は、サービスに対して請求されるエンティティ（保険会社やメディケアのような政府プログラムなど）を識別します。支払者情報は、収益サイクル分析の基本です。 支払者ごとにプロセスを分析することで、支払い時間、否認率、および異議申し立て成功率に significantなばらつきがあることが明らかになります。これにより、遅延や収益損失を引き起こす問題のある支払者を特定するのに役立ち、支払者との契約や関係を効果的に管理するために不可欠です。 その重要性 支払い者ごとのプロセスセグメンテーションを可能にし、支払い者の異なる行動、否認率、支払い速度を明らかにします。これは財務パフォーマンスにとって不可欠です。 取得元 この情報は、Oracle Health Revenue Cycle内の患者の請求または保険記録に保存されます。 例 AetnaBlue Cross Blue ShieldユナイテッドヘルスケアメディケアCigna | |||
| 未払い残高 OutstandingBalance | ある時点での請求イベントに対する未払い残高。 | ||
| 説明 この属性は、すべての支払いと調整が適用された後の請求イベントに対する現在の未払い額を示します。これは、その特定の請求に対するアクティブな売掛金を表します。 これは「未払い残高経過期間」ダッシュボードにとって重要な属性です。この値を時系列で分析することは、キャッシュフローの速度を監視し、債権回収努力の有効性を評価し、売掛金回収日数（DSO）のような主要な財務KPIを計算するのに役立ちます。 その重要性 各ケースの現在の売掛金を追跡し、これはキャッシュフロー管理と回収の有効性を分析するために不可欠です。 取得元 この値は通常、特定の請求イベントに対するすべての財務トランザクション（請求、支払い、調整）の合計から計算されます。これは口座要約テーブルのフィールドとして存在する場合があります。 例 75.000.00550.80 | |||
| 経理部門 BillingDepartment | その活動を担当する部門または機能チーム。 | ||
| 説明 この属性は、「請求情報取り込み」、「コーディング」、または「債権回収」など、アクティビティを実行した部門を特定します。これはプロセスフローに組織的なコンテキストを提供します。 部門の視点からプロセスを分析することは、チーム間の引き継ぎを理解し、部門横断的な非効率性を特定するために不可欠です。これにより、アクティビティとパフォーマンス指標を部門レベルで集計することで、「請求部門ワークロード」ダッシュボードをサポートします。 その重要性 活動を組織単位に割り当てます。これは部門間の引き継ぎ、ワークロード、チームのパフォーマンスを分析するための鍵となります。 取得元 この情報は、Oracle Healthのユーザープロファイルデータに直接保存されるか、ユーザーまたは活動タイプに基づいて導出される場合があります。 例 患者アクセスコーディングBilling回収 | |||
| 調整金額 AdjustmentAmount | 口座残高に対して行われた調整の貨幣価値。 | ||
| 説明 この属性は、契約上の許容額、償却、修正など、請求イベントに適用されるあらゆる財務調整の金額を捉えます。調整は請求からの期待収益を直接減少させます。 「口座調整影響」ダッシュボードはこの属性に大きく依存しています。調整額とそれに関連する理由を分析することは、収益漏洩の原因、契約管理の問題、または初期の請求情報取り込みプロセスにおける問題を特定するのに役立ちます。これは財務健全性にとって重要な指標です。 その重要性 貸倒れや修正による収益漏洩を定量化し、財務浸食の根本原因を特定し対処するのに役立ちます。 取得元 患者アカウントに対する調整または貸倒れを記録する財務取引テーブルに見られます。 例 -50.25-120.0025.00 | |||
| イベントの終了時刻 EventEndTime | 利用可能な場合、活動の完了を示すタイムスタンプ。 | ||
| 説明 StartTimeが活動の開始を示すのに対し、EventEndTimeはその終了を示します。多くの活動は瞬間的なイベントであるため、すべてのアクティビティに明確な終了時間があるわけではありません。しかし、「否認申し立て済み」のように処理に時間がかかる可能性のある継続的なアクティビティの場合、このフィールドは非常に有用です。 この属性により、個々のアクティビティの処理時間をより正確に計算できます。活動間の待機時間と活動に費やされた処理時間とを区別するのに役立ちます。 その重要性 活動が完了するまでにかかる時間を直接計算できるようにし、処理時間と待機時間を分離します。 取得元 Oracle Health Revenue Cycleの一部のトランザクションテーブルには、特定の長時間タスクの開始および終了タイムスタンプが含まれている場合があります。 例 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ソースシステム SourceSystem | イベントデータを抽出したシステム。 | ||
| 説明 この属性は、データの発生源となったソースアプリケーションまたはモジュールを識別します。このプロセスの場合、通常は「Oracle Health Revenue Cycle」ですが、複数の場所からデータが統合されている場合は、システム内の異なるモジュールを指定することもできます。 この情報は、データガバナンスとトラブルシューティングにとって貴重です。データ系統を確定するのに役立ち、複数のシステムが単一のエンドツーエンドプロセスに貢献する環境において重要です。 その重要性 データ発生源に関する 取得元 これは、データセットの起源をラベル付けするために、データ抽出、変換、ロード（ETL）プロセス中にしばしば追加される静的な値です。 例 OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| 最終データ更新 LastDataUpdate | このイベントのデータが最後に更新または抽出された日時を示すタイムスタンプ。 | ||
| 説明 この属性は、データセットが最後に更新された日時を示します。これは分析されるデータの鮮度に関する情報を提供し、プロセスマイニング分析から導出される洞察の適時性を理解するために重要です。 ユーザーはこの属性をチェックして、最新のプロセス情報を表示していることを確認できます。これはデータの鮮度に関する期待値を管理するのに役立ち、データガバナンスと品質保証の重要な要素です。 その重要性 データの鮮度を示し、分析と決定が最新の情報に基づいていることを保証します。 取得元 これは、プロセスマイニングプラットフォームにデータをロードするETLプロセス中に通常生成および投入されるメタデータフィールドです。 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 処理時間 ProcessingTime | アクティビティに実作業として費やした時間。 | ||
| 説明 この属性は、イベントのアクティブ処理時間を測定し、その開始タイムスタンプと終了タイムスタンプの差として計算されます。これにより、タスクに積極的に費やされた時間と次のステップを待機する時間とを区別するのに役立ちます。 これはパフォーマンス分析にとって重要な指標であり、システム的な遅延からタスクを実行するリソースの効率を分離します。これにより、アイテムがワークキューにどれだけ長く滞留したかに関わらず、請求のコーディングや支払いの計上にどれくらいの時間がかかるかという疑問に答えることができます。 その重要性 活動の実際の作業期間を測定し、アイドル時間または待機時間から分離することで、リソース効率のより明確なビューを提供します。 取得元 これは計算されたメトリックであり、EventEndTimeからEventTimestampを差し引くことで導出されます。両方のフィールドが利用可能な場合にのみ計算可能です。 例 300120045 | |||
| 患者ID PatientId | 請求イベントに関連付けられた患者のユニークな識別子。 | ||
| 説明 この属性は、サービスを受けた患者のユニークな識別子であり、医療記録番号（MRN）として知られることもよくあります。これは、金融取引を特定の個人にリンクさせます。 プロセスにとってのケースIDではありませんが、患者IDは、単一の患者のすべての請求イベントを集計し、その患者の財務上の全過程を理解するのに役立ちます。また、患者マスターデータと結合した場合、患者の人口統計や履歴に基づいたセグメンテーションも可能です。 その重要性 財務イベントを特定の患者にリンクさせ、患者中心の分析とすべての請求活動の集計を可能にします。 取得元 この識別子は患者マスターレコードの中核要素であり、請求、クレーム、支払いなど、関連するすべてのトランザクションテーブルに存在します。 例 MRN-1002345MRN-1002346MRN-1002347 | |||
| 手戻り IsRework | 手戻りや繰り返しの作業を表す活動を識別するフラグです。 | ||
| 説明 この計算された属性は、理想的な「ハッピーパス」からの逸脱を示し、手戻りを構成する活動にフラグを付けます。例としては、「修正請求提出済み」や「否認申し立て済み」などがあり、これらはプロセスが最初に完璧に進行した場合には発生しないはずです。 手戻りを特定し定量化することは、プロセスマイニングの主要な目標です。このフラグにより、すべての手戻りループの簡単なフィルタリングと分析が可能になり、プロセスの非効率性の頻度、コスト、および原因を測定するのに役立ちます。これは収益サイクルにおける品質の真のコストを理解するために不可欠です。 その重要性 手戻りループの頻度と影響を定量化し、プロセスの非効率性と品質不良によるコストを浮き彫りにするのに役立ちます。 取得元 これは導出された属性です。データ変換中に、特定のアクティビティ名を「手戻り」としてフラグ付けするビジネスロジックを適用することで計算されます。 例 truefalse | |||
| 紛争理由 DisputeReason | 顧客または患者が請求書または請求を異議申し立てする際に提示した理由。 | ||
| 説明 この属性は、患者またはその他の責任者が請求に異議を唱えた理由を捕捉します。理由には、誤った請求、提供されなかったサービス、保険処理の問題などが含まれます。 この情報は「請求書異議解決メトリクス」ダッシュボードにとって不可欠です。異議の最も一般的な理由を理解することは、請求情報取り込み、コーディング、または請求プロセスにおけるシステム的な問題を特定するのに役立ちます。これらの根本原因に対処することで、異議発生率と解決に必要な管理コストを大幅に削減できます。 その重要性 請求書が異議申し立てされる理由を説明し、請求の正確性や明確性の問題に対する直接的な洞察を提供し、修正が必要な点を明らかにします。 取得元 これは、Oracle Health内のケース管理または顧客サービスモジュールに保存され、患者の口座にリンクされている可能性が高いです。 例 不正確なサービス請求重複料金保険請求誤りサービス未提供 | |||
| 自動化 IsAutomated | そのアクティビティが自動システムによって実行されたか、人間によって実行されたかを示すフラグ。 | ||
| 説明 このブール属性は、ボットやシステムバッチジョブなどのソフトウェア自動化によって実行されるアクティビティと、ユーザーによって手動で実行されるアクティビティとを区別します。たとえば、「請求生成済み」は自動化されたステップである可能性がありますが、「否認申し立て済み」は手動である可能性が高いです。 この属性を分析することは、プロセスにおける自動化のレベルと、それが効率およびエラー率に与える影響を理解するのに役立ちます。自動化された経路と手動の経路のパフォーマンスを比較し、さらなる自動化の機会を特定するために使用できます。 その重要性 人間が行う活動とシステムによる活動を区別し、自動化の有効性を分析し、新しい自動化の機会を特定するために重要です。 取得元 これは通常、UserPerformingAction属性に基づいて導出されます。例えば、「SYSTEM」や「RPA_BOT」のようなユーザーIDによって実行された活動は自動化されたものとしてフラグ付けされます。 例 truefalse | |||
| 請求ID ClaimId | 支払者に提出された保険請求のユニークな識別子。 | ||
| 説明 この属性は、支払者に払い戻しを求めて生成および送信される請求に割り当てられるユニークIDです。単一の請求イベントが、そのライフサイクル中に1つまたは複数の請求をもたらすことがあります（例：修正が必要な場合）。 請求IDを使用することで、特定の提出を支払者に追跡し、支払いまたは否認などの応答に直接リンクさせることができます。これは、より広範な収益サイクルプロセス内で、より詳細なレベルの追跡を提供します。 その重要性 支払い者との請求のジャーニーを追跡するための特定の識別子を提供します。これは全体的な請求イベントよりも粒度が細かいものです。 取得元 このIDは、請求が作成された際にOracle Healthによって生成され、主要な請求テーブルに保存されます。 例 CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| 請求額 ChargeAmount | 請求されるサービスまたは製品の総貨幣価値。 | ||
| 説明 この属性は、調整、契約上の許容額、または支払いが適用される前の、サービスに対して請求された初期の割引されていない金額を表します。これは、請求イベントの開始時の財務価値です。 請求額を追跡することは、提供されたサービスの総価値を計算し、その後の調整や償却の財務的影響を理解するなど、財務分析にとって非常に重要です。これは収益実現を測定するためのベースラインとして機能します。 その重要性 ケースの初期財務価値を確立します。これは、その後のすべての財務分析と影響評価の基礎となります。 取得元 Oracle Health の料金詳細または料金取引テーブルにあります。 例 150.001250.7585.50 | |||
収益サイクル管理アクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| アカウント閉鎖済み | 口座残高がゼロであり、それ以上の活動が予想されないことを示す最終活動です。これは口座残高がゼロになったときにしばしば推測されます。 | ||
| その重要性 レベニューサイクルの成功裏の完了をマークします。この状態に達するまでの時間は、全体的なプロセス効率の主要な尺度です。 取得元 これは通常、すべての支払いと調整が適用された後で、口座の未払い残高が最初にゼロになり、その後もゼロのままであることを特定することによって推測されます。 取得 すべての料金と支払いが イベントタイプ calculated | |||
| 患者入院作成済み | 特定の受診またはサービスに対する患者アカウントの作成をマークします。これは通常、登録システムまたは入院/退院/転送（ADT）フィードによってトリガーされる明示的なイベントです。 | ||
| その重要性 特定の請求イベントに対するレベニューサイクル全体の出発点として機能し、総プロセス期間と登録精度の分析を可能にします。 取得元 患者登録またはADTモジュールログから取得されます。受診作成イベント、または受診や会計番号に関連する最も早いタイムスタンプを確認してください。 取得 患者の登録または入院時に記録されるイベントです。 イベントタイプ explicit | |||
| 支払い者へ請求提出済み | 生成された請求の保険会社または支払い者への電子的または紙での提出を表します。システムはこの送信の日時を記録する必要があります。 | ||
| その重要性 この活動は支払いサイクルを開始します。提出から支払いまでの時間を分析することは、支払者のパフォーマンスと売掛金回収日数（DSO）を理解するための鍵となります。 取得元 請求管理モジュール（送信イベントを記録）から取得されます。請求履歴で送信タイムスタンプまたは「提出済み」へのステータス変更を確認してください。 取得 請求が イベントタイプ explicit | |||
| 支払い計上 | 支払い者から受領した支払いを、患者のアカウント上の対応する料金に適用することを表します。これはユーザーまたは自動化されたプロセスによって記録される財務取引です。 | ||
| その重要性 支払い計上の効率は売掛金の正確さに影響します。ここでの遅延は財務状況を歪め、二次請求を遅らせる可能性があります。 取得元 支払い取引テーブルに見られます。各支払い 取得 支払いがアカウントに適用された際に財務取引が記録されます。 イベントタイプ explicit | |||
| 請求生成済み | 個々の料金がUB-04やCMS-1500のような正式な請求書にまとめられる`ポイント`をマークします。これは初期請求書を作成するシステム生成イベントです。 | ||
| その重要性 これは支払者への請求準備が整ったことを示す主要なマイルストーンです。これは内部の請求から請求書発行までの遅延を測定するための終点となります。 取得元 請求生成ログまたはテーブルに記録された明示的なイベントです。入院に関連付けられた主要な請求レコードの作成 取得 請求レコードの作成時に記録されるイベントです。 イベントタイプ explicit | |||
| 修正請求提出済み | 支払い者への修正または訂正された請求の提出を表します。これは多くの場合、否認または追加情報要求の後に発生します。これは修正インジケーターを持つ新しい請求提出によって識別されます。 | ||
| その重要性 この活動は否認管理の手戻りループの重要な部分です。頻度が高い場合、初期請求の正確性に問題があることを示します。 取得元 請求提出ログから捕捉されます。既存の入院に対する新しい提出を検索します。これは多くの場合、再提出コードまたはより高いイテレーション番号でマークされています。 取得 請求再提出の記録されたイベントで、多くの場合、特定の請求頻度タイプコードによって識別されます。 イベントタイプ explicit | |||
| 勘定調整済み | アカウント残高に対して行われる財務調整を表します。例えば、契約上の許容範囲、貸倒れ、または割引などです。各調整は個別の財務取引です。 | ||
| その重要性 調整は収益に直接影響します。その頻度、種類、および金額を分析することで、収益漏洩と請求の不正確さを特定できます。 取得元 財務取引テーブルに見られます。各調整は、特定の取引コードと 取得 特定の調整コードとともに財務取引が記録されます。 イベントタイプ explicit | |||
| 否認再審査済み | 否認された請求が再審査中であることを示すユーザーまたはシステムアクションです。これは通常、ステータス更新またはワークキューで作成された特定のタスクとして捕捉されます。 | ||
| その重要性 この活動は手戻りループを開始します。異議申し立ての頻度と成功率を分析することは、収益回収努力を最適化するために重要です。 取得元 これは明示的なユーザー主導のイベントであるか、請求のステータス変更（例：「異議申し立て済み」または「審査中」）から推測される場合があります。 取得 ユーザーが否認された請求の再審査プロセスを開始した際のステータス変更または記録されたイベントです。 イベントタイプ explicit | |||
| 否認受信済み | 支払い者が請求または特定の明細項目を拒否したイベントをマークします。これは送金通知に示されており、送金データに存在する否認コードから推測されることがよくあります。 | ||
| その重要性 否認を追跡することは、コーディングエラーや資格問題などの根本原因を特定し、クリーンクレーム率を改善するために不可欠です。 取得元 送金（ERA/835）データから推測されます。請求または明細項目にゼロではない否認金額と対応する否認理由コードがある場合、このイベントがトリガーされます。 取得 否認理由コード（CARC/RARC）を含む送金データから推測されます。 イベントタイプ inferred | |||
| 回収活動開始済み | 患者のアカウントが未払いのために回収プロセスに移行されたことを示します。これは通常、アカウントの財務またはステータス`クラス`の変更によって捕捉されます。 | ||
| その重要性 これは不良債権管理にとって重要なステップです。この段階に至る要因とその成功率を分析することは、財務健全性にとって不可欠です。 取得元 アカウントステータスフィールドが「回収中」または「貸倒れ」に変更されたことから推測されます。このステータス変更には関連する 取得 アカウントステータスが「回収中」または同様の状態に変更されたことから推測されます。 イベントタイプ inferred | |||
| 患者向け明細書送付済み | 残りの患者責任に対する請求書が生成され、患者に送付されるイベントをマークします。これは患者請求モジュールによって記録される明示的なアクションです。 | ||
| その重要性 これは収益サイクルの患者支払い部分を開始します。これを追跡することは、患者債権回収の有効性を分析するのに役立ちます。 取得元 患者請求または連絡履歴ログから取得されます。システムは各明細書が作成または送信された日付を記録する必要があります。 取得 患者向け明細書が生成され、印刷または電子的に送信されたときに記録されるイベントです。 イベントタイプ explicit | |||
| 料金コーディング済み | 医療`コーダー`がCPTやICD-10のような標準化されたコードを捕捉された料金に割り当てるプロセスを表します。これは料金または入院のステータス変更によって追跡されることがよくあります。 | ||
| その重要性 コーディングの遅延は一般的なボトルネックです。この活動を追跡することで、コーディングワークフローの非効率性と、それが請求のタイムラインに与える影響を特定できます。 取得元 患者の入院または料金 取得 入院または料金ステータスが「コーディング済み」または「請求準備完了」に変更されたことから推測されます。 イベントタイプ inferred | |||
| 料金捕捉済み | 請求可能なサービスまたは品目を患者のアカウントに入力することを表します。これは臨床システムから自動的に行われるか、スタッフによる手動入力で行われることがあります。 | ||
| その重要性 この活動は、サービス提供から請求開始までの時間である「チャージラグ」を測定するために重要であり、キャッシュフローと収益の完全性に直接影響します。 取得元 料金取引テーブルから捕捉され、各料金明細項目の作成 取得 各新規請求に対して作成されるトランザクションログエントリ。 イベントタイプ explicit | |||
| 送金受領済み | 支払い者からの電子送金通知（ERA）または紙の給付説明書（EOB）の受領を示します。この文書は、どの料金が支払われ、拒否され、または調整されたかを詳述します。 | ||
| その重要性 これは支払者からの最初の応答であり、支払い速度を理解し、否認傾向を早期に特定するために非常に重要です。 取得元 送金処理モジュールに記録されます。請求に関連付けられたERAファイル、例えば835取引ファイルのインポートまたは作成 取得 支払い者の送金ファイル（例：ANSI 835）のインポートと処理時に記録されるイベントです。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- データベースアクセスをリクエスト: Oracle Health レベニューサイクルデータベースへの読み取り専用資格情報を取得します。患者、入院、請求、および財務取引データを含むスキーマへのアクセスが必要です。これには通常、ITセキュリティおよびデータベース管理チームからの承認が必要です。
- スキーマおよびテーブル名を特定: データベース管理者またはシステムアナリストと協力して、Oracle Health インスタンスの正確なスキーマおよびテーブル名を確認します。クエリで提供される名前は一般的なプレースホルダーであり、特定の環境にマッピングする必要があります。
- SQLクライアントをインストール: ワークステーションにOracle SQL DeveloperまたはDBeaverなどの互換性のあるSQLクライアントをインストールします。このツールは、データベースに接続し、抽出スクリプトを実行するために使用されます。
- データベース接続を確立: 提供されたホスト、ポート、サービス名、および資格情報を使用して、SQLクライアントで新しいデータベース接続を構成します。接続をテストして、正常に接続できることを確認します。
- SQLクエリをカスタマイズ: 提供されたSQLスクリプトを新しいクエリエディタウィンドウにコピーします。
[START_DATE]や[END_DATE]などのプレースホルダー値を見つけ、分析に必要な日付範囲（例：'2023-01-01'）に置き換えます。特定の患者クラスでフィルタリングするなど、特定の分析ニーズに基づいてフィルタ条件を調整します。 - 抽出スクリプトを実行: カスタマイズされたSQLスクリプトを実行します。このクエリは包括的に設計されており、日付範囲とデータベースのサイズに応じて、完了までに数分から数時間かかる場合があります。
- 初期結果を確認: クエリが完了したら、SQLクライアントの結果グリッドで最初の数百行を確認します。すべての列がNULLであるか、データ形式が正しくないかなどの明らかなエラーがないかを確認し、スクリプトが正しく実行されたことを確認します。
- データをCSVにエクスポート: 結果セット全体をCSVファイルにエクスポートします。文字化けを防ぐためにUTF-8エンコーディングを使用します。エクスポートされたファイルに、クエリアリアスで指定された列名（例：「BillingEvent」、「ActivityName」）を含むヘッダー行が含まれていることを確認します。
- アップロードの準備: プロセスマイニングツールにアップロードする前に、CSVファイルを開いて整合性を確認します。
タイムスタンプ形式が一貫しており、列ヘッダーが必須のアトリビュートと完全に一致していることを確認します。これでファイルはアップロードの準備が整いました。
設定
- 日付範囲: クエリでは
[START_DATE]と[END_DATE]のプレースホルダーを使用します。データ量を制御するため、具体的かつ適切な日付範囲を定義することが不可欠です。初回分析では3～6ヶ月の範囲を推奨します。 - フィルタリング: 初期データセットは、
RelevantEncountersセクションで入院登録日(reg_dt_tm)によってフィルタリングされます。範囲を絞り込むために、このセクションに他のWHERE句を追加できます。例えば、特定の入院タイプに焦点を当てるには、e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')とします。 - パフォーマンス: 本番システムでの直接的なデータベースクエリはパフォーマンスに影響を与える可能性があります。この抽出は、利用可能であればオフピーク時または本番データベースの読み取り専用レプリカに対して実行することを強く推奨します。
- 前提条件: この方法では、クエリで参照されるすべてのテーブルに対する
SELECT権限を持つデータベースユーザーアカウントが必要です。これらのテーブルには、入院、請求、料金、請求書、送金、および財務取引のテーブルが含まれます。 - テーブルと列のマッピング: 提供されるスクリプトは、テーブルと列に一般的な代表名を使用しています。これらを貴組織のOracle Healthデータベーススキーマ内の実際の名前と照合し、マッピングする必要があります。例えば、貴社のシステムでは
FINANCIAL_TRANSACTIONがAR_TRANSACTIONSと命名されている場合があります。
a クエリ例 sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL;