収益サイクル管理のデータテンプレート
収益サイクル管理のデータテンプレート
- 収集を推奨する属性
- 追跡する主なアクティビティ
- Oracle Health Revenue Cycleのデータ抽出ガイド
収益サイクル管理の属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 収益サイクルプロセスで発生した個々のステップまたはイベントの名前です。 | ||
| 説明 この属性には、請求イベントのライフサイクルで実行された各アクティビティの名前が記録されます。例として、「請求項目を確定」「支払者に請求を提出」「入金を計上」などがあります。これらのアクティビティが、検出されたプロセスマップのノードになります。 アクティビティの順序と頻度の分析は、プロセスマイニングの中心です。この属性を使うと、よく見られるプロセス経路の特定、標準手順からの逸脱の発見、収益サイクルの業務フローの把握ができます。 重要な理由 プロセスの各ステップを定義し、プロセスマップの可視化やワークフローのパターン分析を可能にします。 入手先 通常、Oracle Healthの収益サイクルにおける各段階に関連するイベントログ、ステータス変更記録、または特定の取引テーブルから取得します。 例 請求を作成支払明細を受領否認に異議を申し立て口座をクローズ | |||
| イベントのタイムスタンプ EventTimestamp | アクティビティがシステムに記録された正確な日時です。 | ||
| 説明 この属性には各アクティビティのタイムスタンプが記録され、発生した正確な時点を示します。特定の請求イベントについて、収益サイクル内のイベントのタイミングと順序を把握するために欠かせません。 分析では、イベントのタイムスタンプを使ってアクティビティを時系列に並べ、各ステップ間の所要時間やサイクルタイムを算出し、ボトルネックを分析します。「請求を提出」から「支払明細を受領」までの遅延など、時間に基づくプロセスマイニング指標の基礎となります。 重要な理由 イベントの順序付け、サイクルタイムや所要時間などのパフォーマンス指標の算出、プロセスのボトルネックの特定に欠かせないタイムスタンプです。 入手先 Oracle Health収益サイクルの各取引テーブルまたはイベントログテーブルには、レコードの作成時刻またはイベントの発生時刻を示すタイムスタンプ列が必要です。 例 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| 請求イベント BillingEvent | 請求が発生する個々のサービスまたは製品の納品を識別する固有のIDです。収益サイクルプロセスにおけるケースIDとして機能します。 | ||
| 説明 請求イベントは主要なケースIDとして機能し、個別の請求対象項目について、請求項目の確定から口座のクローズまでのすべてのアクティビティを関連付けます。請求イベントごとに収益サイクルプロセスの固有の事例を表すため、請求提出、入金処理、否認や調整の可能性など、各段階の進行状況を追跡できます。 プロセスマイニング分析では、この属性を使ってプロセス全体のフローを再構成します。プロセスバリアントの可視化、アクティビティ間のサイクルタイムの算出、個々の請求イベントに関連するボトルネックや逸脱の特定が可能になります。 重要な理由 請求対象サービスのライフサイクル全体を追跡するための基本となるキーです。プロセスフローの分析とパフォーマンス測定に使用します。 入手先 Oracle Health収益サイクルの主要な請求または請求取引テーブルに含まれる、一意のキーを指定してください。請求イベントの主キーについては、システムの文書を確認してください。 例 BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| ユーザー UserPerformingAction | アクティビティを実行した担当者のユーザーIDまたは名前です。 | ||
| 説明 この属性は、プロセス内の特定のアクティビティを実行した従業員または自動処理用ユーザーを特定します。業務量の配分やリソースパフォーマンスの把握、研修の必要性の特定に役立ちます。 分析では、ユーザーやチームでプロセスマップを絞り込み、リソース間のパフォーマンスを比較し、「請求部門の業務量」ダッシュボードで業務量を分析できます。高い成果を上げている担当者や、追加の支援・研修が必要な担当者の特定にも役立ちます。 重要な理由 プロセスのアクティビティを特定のユーザーやチームに関連付け、業務量の分析、パフォーマンスの比較、研修機会の特定を可能にします。 入手先 通常、Oracle Healthの各モジュールの取引テーブルに、ユーザーID項目（例：「CREATED_BY」「USER_ID」）が含まれています。 例 j.doeasmithBillingBot_AUTOk.williams | |||
| 患者区分 PatientClass | 入院患者や外来患者など、患者の受診記録の分類です。 | ||
| 説明 この属性は、請求の発生元となった患者の受診または診療記録の種類を分類します。一般的な区分には、入院、外来、救急、継続診療があります。患者区分によって、請求や請求書類の提出プロセス全体が決まることも少なくありません。 患者区分ごとにプロセス経路やコンプライアンス要件が異なります。この属性に基づいて分析すると、こうした違いを把握し、改善施策を調整するとともに、区分ごとに適切な手順が守られているかを確認できます。 重要な理由 入院と外来など、複雑さ、所要時間、請求要件が異なるプロセスフローを分けて分析できます。 入手先 Oracle Healthの患者受診記録または入院記録に標準で含まれる項目です。 例 入院外来緊急定期 | |||
| 支払者名 PayerName | 支払いを担う保険会社または第三者支払者の名前です。 | ||
| 説明 この属性は、サービスの請求先となる保険会社やメディケアなどの政府プログラムを特定します。支払者の情報は、収益サイクルの分析に欠かせません。 支払者別にプロセスを分析すると、入金までの時間、否認率、異議申し立ての成功率に大きな違いがあるかを確認できます。遅延や収益の損失につながる支払者を特定し、支払者との契約や関係を適切に管理するうえでも役立ちます。 重要な理由 支払者別にプロセスを分類し、支払者ごとの対応、否認率、入金速度の違いを明らかにします。財務パフォーマンスの把握に役立ちます。 入手先 Oracle Health収益サイクル内の患者請求記録または保険記録に保存されています。 例 AetnaBlue Cross Blue ShieldUnitedHealthcareメディケアCigna | |||
| 未回収残高 OutstandingBalance | 特定の時点における請求イベントの未払い残高です。 | ||
| 説明 この属性は、すべての支払いと調整を反映した後の、請求イベントに対する現在の未払い額を示します。該当する請求に対する現在の売掛金を表します。 「未回収残高の経過期間」ダッシュボードで重要な属性です。この値を時系列で分析すると、資金回収の速さを監視し、回収活動の効果を評価できます。また、売上債権回転日数（DSO）などの重要業績評価指標（KPI）の算出にも役立ちます。 重要な理由 ケースごとの現在の売掛金を追跡します。資金繰りの管理や回収活動の効果分析に欠かせません。 入手先 通常は、特定の請求イベントに関するすべての財務トランザクション（請求、支払い、調整）の合計から算出します。口座サマリーテーブルの項目として存在する場合もあります。 例 75.000.00550.80 | |||
| 調整額 AdjustmentAmount | 口座残高に対して行われた調整の金額です。 | ||
| 説明 この属性には、契約上の減額、貸倒処理、訂正など、請求イベントに適用された財務調整額が記録されます。調整額は、請求に対して見込まれる収益を直接減少させます。 「口座調整の影響」ダッシュボードでは、この属性が重要な役割を果たします。調整額とその理由を分析すると、収益の漏れ、契約管理上の問題、初期の請求情報取得プロセスの問題を特定できます。財務健全性を測る重要な指標です。 重要な理由 貸倒処理や訂正による収益の漏れを数値化し、財務価値の目減りにつながる根本原因の特定と対処に役立ちます。 入手先 患者の口座に対する調整や貸倒処理を記録する財務トランザクションテーブルにあります。 例 -50.25-120.0025.00 | |||
| 請求否認理由コード DenialReasonCode | 保険支払者が請求を否認した理由を示す標準コードです。 | ||
| 説明 保険支払者が請求を否認すると、「補償対象外のサービス」や「請求の重複」など、否認理由を示すコードが通知されます。この属性には、そのコードと説明が記録されます。 否認理由の分析は、収益サイクルの改善に欠かせません。組織は、コーディングや患者の資格確認に関する問題など、よくあるパターンを特定し、今後の否認を防ぐための是正措置を講じられます。これにより、クリーンクレーム率が向上し、手戻りのコストを削減できます。 重要な理由 請求否認の根本原因を把握し、対象を絞った改善によってクリーンクレーム率を高め、収益回収を早めることができます。 入手先 この情報は、保険支払者から電子送金通知（ANSI 835ファイル）として受信し、Oracle Healthの請求テーブルまたは送金テーブルに保存します。 例 CO-16：審査に必要な情報が請求またはサービスに不足しています。PR-96：補償対象外の請求項目です。CO-18：請求またはサービスが重複しています。 | |||
| 請求部門 BillingDepartment | アクティビティを担当する部門または機能チームです。 | ||
| 説明 この属性には、アクティビティを実行した「請求項目の確定」「コーディング」「回収」などの部門が設定されます。プロセスフローを組織の観点から把握できます。 部門別にプロセスを分析すると、チーム間の引き継ぎを把握し、部門をまたぐ非効率を特定できます。また、アクティビティやパフォーマンス指標を部門単位で集計できるため、「請求部門の業務量」ダッシュボードにも役立ちます。 重要な理由 アクティビティを組織単位に割り当てます。部門間の引き継ぎ、業務量、チームのパフォーマンスを分析するうえで重要です。 入手先 Oracle Healthのユーザープロフィールデータに直接保存されている場合と、ユーザーまたはアクティビティの種類に基づいて導出される場合があります。 例 患者受付コーディング請求回収 | |||
| イベント終了時刻 EventEndTime | 利用可能な場合に、アクティビティの完了時刻を示すタイムスタンプです。 | ||
| 説明 StartTimeがアクティビティの開始を示すのに対し、EventEndTimeは終了を示します。多くのイベントは瞬時に発生するため、すべてのアクティビティに明確な終了時刻があるわけではありません。一方、「否認に異議を申し立て」のように処理に時間がかかるアクティビティでは、この項目が役立ちます。 この属性を使うと、個々のアクティビティの処理時間をより正確に算出できます。アクティビティ間の待ち時間と、アクティビティ自体にかかった処理時間を区別できます。 重要な理由 アクティビティの完了までにかかった時間を直接算出し、処理時間と待ち時間を区別できます。 入手先 Oracle Health収益サイクルの一部の取引テーブルには、時間のかかる特定のタスクについて、開始と終了の両方のタイムスタンプが含まれている場合があります。 例 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| ソースシステム SourceSystem | イベントデータの抽出元となるシステムです。 | ||
| 説明 この属性は、データの発生元となったアプリケーションまたはモジュールを特定します。このプロセスでは通常「Oracle Health Revenue Cycle」ですが、複数の場所からデータを統合する場合は、システム内の異なるモジュールを指定することもあります。 この情報は、データガバナンスや問題の調査に役立ちます。データの来歴を確認できるほか、複数のシステムが1つのプロセス全体に関わる環境でも重要です。 重要な理由 データの発生元を把握できるため、データの検証やガバナンス、システムに起因するプロセスの違いを理解するうえで役立ちます。 入手先 通常、データの抽出、変換、読み込み（ETL）の際に、データセットの発生元を示す固定値として追加されます。 例 OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| 最終データ更新日時 LastDataUpdate | このイベントのデータが最後に更新または抽出された日時を示すタイムスタンプです。 | ||
| 説明 この属性には、データセットの最終更新日時が表示されます。分析対象データの新しさを把握できるため、プロセスマイニング分析で得られたインサイトがどの時点のデータに基づくかを確認できます。 最新のプロセス情報を表示しているかどうかを確認する際にも使えます。データの更新時期に関する認識をそろえるうえで役立ち、データガバナンスと品質保証の重要な要素となります。 重要な理由 データの新しさを示し、最新の情報に基づく分析と意思決定を支えます。 入手先 通常、プロセスマイニングプラットフォームへのデータ読み込みを行うETL処理で生成、設定されるメタデータ項目です。 例 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 患者ID PatientId | 請求イベントに関連付けられた患者の一意の識別子です。 | ||
| 説明 この属性は、サービスを受けた患者の一意の識別子で、医療記録番号（MRN）とも呼ばれます。財務トランザクションを特定の個人に紐付けます。 プロセスのケースIDではありませんが、患者IDを使うと、患者ごとの請求イベントを集計し、財務上の経過全体を把握できます。また、患者の基本データと結合すれば、患者の属性や履歴に基づくセグメント分析も可能です。 重要な理由 財務イベントを特定の患者に紐付け、患者単位の分析や請求活動全体の集計を可能にします。 入手先 この識別子は患者の基本記録の主要項目であり、請求、保険請求、支払いなど、関連するすべてのトランザクションテーブルに含まれます。 例 MRN-1002345MRN-1002346MRN-1002347 | |||
| 手戻りかどうか IsRework | 手戻りや作業の繰り返しに該当するアクティビティを示すフラグです。 | ||
| 説明 この計算属性は、理想経路からの逸脱にあたり、手戻りとなるアクティビティにフラグを設定します。たとえば、「請求の訂正版を提出」や「否認への異議申し立て」は、プロセスが最初から問題なく進めば発生しないアクティビティです。 手戻りの特定と定量化は、プロセスマイニングの主な目的の1つです。このフラグを使うと、手戻りのループを簡単に絞り込んで分析でき、プロセスの非効率性の頻度、コスト、原因を測定できます。収益サイクルにおける品質コストの実態を把握するうえで欠かせません。 重要な理由 手戻りのループの頻度と影響を数値化し、プロセスの非効率性や品質不良のコストを明らかにします。 入手先 派生属性です。データ変換時に、特定のアクティビティ名を手戻りとして判定するビジネスロジックを適用して算出します。 例 truefalse | |||
| 異議申し立ての理由 DisputeReason | 請求書または請求内容に対して、顧客または患者が異議を申し立てた理由です。 | ||
| 説明 この属性には、患者またはその他の支払責任者が請求に異議を申し立てた理由が記録されます。理由には、請求額の誤り、提供されていないサービス、保険処理上の問題などがあります。 「請求異議申し立ての解決指標」ダッシュボードでは、この情報が欠かせません。よくある異議申し立ての理由を把握すると、請求情報の取得、コーディング、請求処理における構造的な問題を特定できます。根本原因に対処すれば、異議申し立ての割合と解決に必要な事務作業を大幅に減らせます。 重要な理由 請求に異議が申し立てられる理由を明らかにし、修正が必要な請求の正確性や明確さに関する問題を把握できます。 入手先 Oracle Healthのケース管理またはカスタマーサービスモジュールに保存され、患者の口座に紐付けられていると考えられます。 例 サービスの請求内容に誤り請求の重複保険への請求内容に誤りサービス未提供 | |||
| 自動処理かどうか IsAutomated | アクティビティが自動化システムと人のどちらによって実行されたかを示すフラグです。 | ||
| 説明 この真偽値属性は、ボットやシステムのバッチ処理などのソフトウェアによる自動処理と、ユーザーによる手動処理を区別します。たとえば、「請求の作成」は自動処理、「否認への異議申し立て」は手動処理と考えられます。 この属性を分析すると、プロセスの自動化の度合いと、効率やエラー率への影響を把握できます。自動処理と手動処理の経路を比較し、さらなる自動化の機会を見つける際にも役立ちます。 重要な理由 人による処理とシステムによる処理を区別します。自動化の効果を分析し、新たな自動化の機会を見つけるうえで重要です。 入手先 通常はUserPerformingAction属性に基づいて判定します。たとえば、ユーザーIDが「SYSTEM」や「RPA_BOT」のアクティビティには、自動処理のフラグを設定します。 例 truefalse | |||
| 請求ID ClaimId | 保険支払者に提出した保険請求の一意の識別子です。 | ||
| 説明 この属性は、償還を受けるために作成して保険支払者に送信する請求に割り当てられた一意のIDです。1つの請求イベントから、その期間中に1件以上の請求が発生する場合があります。たとえば、訂正が必要な場合です。 請求IDを使うと、保険支払者に提出した特定の請求を追跡し、支払いや否認などの応答に直接紐付けられます。収益サイクル全体の中で、より細かな単位で追跡できます。 重要な理由 保険支払者との請求の進行状況を追跡するための個別の識別子です。請求イベント全体より細かな単位で確認できます。 入手先 請求の作成時にOracle HealthがこのIDを生成し、請求のメインテーブルに保存します。 例 CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| 請求額 ChargeAmount | 請求対象となるサービスまたは製品の総額です。 | ||
| 説明 この属性は、調整額、契約上の減額、支払いが適用される前の、サービスに対する初期の割引前請求額を表します。請求イベントにおける財務上の基準額です。 請求額を追跡することは、提供したサービスの総額の算出や、その後の調整や貸倒処理が財務に与える影響の把握など、財務分析に欠かせません。収益の実現状況を測るベースラインとしても機能します。 重要な理由 ケースの初期財務価値を確定します。これは、その後の財務分析や影響評価の基礎となります。 入手先 Oracle Healthの請求明細テーブルまたは請求トランザクションテーブルにあります。 例 150.001250.7585.50 | |||
収益サイクル管理のアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| 入金を計上 | 支払者から受領した入金を、患者口座の該当する請求項目に反映することを示します。ユーザーまたは自動処理によって記録される財務取引です。 | ||
| 重要な理由 入金処理の効率は、売掛金の正確性に影響します。処理が遅れると財務状況を正しく把握できず、二次請求も遅れる可能性があります。 入手先 入金取引テーブルで確認できます。入金処理ごとに固有の取引IDとタイムスタンプが記録されます。 記録 入金が口座に反映された時点で記録される財務取引です。 イベントタイプ explicit | |||
| 口座をクローズ | 口座残高がゼロになり、以降の処理が見込まれないことを示す最終アクティビティです。口座残高がゼロになった時点から推定することがよくあります。 | ||
| 重要な理由 収益サイクルが正常に完了したことを示します。この状態に至るまでの時間は、プロセス全体の効率を測る重要な指標です。 入手先 通常、すべての入金と調整の反映後に、未収残高が初めてゼロになり、その後もゼロを維持した時点を特定して推定します。 記録 すべての請求と入金を計上した後、口座残高が初めてゼロになった時点で算出します。 イベントタイプ calculated | |||
| 患者の受診記録を作成 | 特定の受診やサービスに対する患者口座の作成を示します。通常、登録システムまたは入退院・転棟（ADT）データ連携によって発生する明示的なイベントです。 | ||
| 重要な理由 請求イベントごとの収益サイクル全体の起点となり、プロセス全体の所要時間や登録の正確性を分析できます。 入手先 患者登録またはADTモジュールのログから取得します。受診記録の作成イベント、または受診記録や財務番号に関連付けられた最も早いタイムスタンプを確認してください。 記録 患者の登録時または入院時に記録されるイベントです。 イベントタイプ explicit | |||
| 支払者に請求を提出 | 作成した請求書類を保険会社などの支払者に電子または紙で提出することを示します。システムには、送信日時が記録されている必要があります。 | ||
| 重要な理由 このアクティビティを起点に入金サイクルが始まります。提出から入金までの時間を分析すると、支払者の対応状況や売上債権回転日数（DSO）を把握できます。 入手先 送信イベントを記録する請求管理モジュールから取得します。請求履歴の提出タイムスタンプ、またはステータスが「提出済み」に変わった記録を確認してください。 記録 クリアリングハウス経由で請求書類が正常に送信された際に記録されるイベントです。 イベントタイプ explicit | |||
| 請求を作成 | 個々の請求項目をUB-04やCMS-1500などの正式な請求書類にまとめる時点を示します。初回の請求書類を作成する、システム生成のイベントです。 | ||
| 重要な理由 支払者への請求準備が整ったことを示す重要な節目です。社内での請求項目確定から請求までの遅延を測定する際の終点となります。 入手先 請求書類の作成ログまたはテーブルに記録される明示的なイベントです。受診記録に関連付けられた主要な請求レコードの作成タイムスタンプを確認してください。 記録 請求レコードの作成時に記録されるイベントです。 イベントタイプ explicit | |||
| 修正した請求を提出 | 否認後や追加情報の要求を受けた後などに、修正した請求を支払者に提出することを示します。通常、訂正を示す情報が付いた新たな請求提出として特定します。 | ||
| 重要な理由 否認対応における手戻りのループを構成する重要なアクティビティです。頻度が高い場合、初回請求の正確性に問題がある可能性があります。 入手先 請求提出ログから取得します。同じ受診記録に対する新たな提出を確認してください。再提出コードや、より大きい反復番号が付いていることがあります。 記録 請求の再提出を記録したイベントです。特定の請求頻度タイプコードで識別できることがよくあります。 イベントタイプ explicit | |||
| 口座を調整 | 契約上の減額、償却、割引など、口座残高に対する財務調整を示します。調整ごとに個別の財務取引として記録されます。 | ||
| 重要な理由 調整は収益に直接影響します。頻度、種類、金額を分析すると、収益の漏れや請求の誤りを特定できます。 入手先 財務取引テーブルで確認できます。調整ごとに、固有の取引コードとタイムスタンプを含む明細として記録されます。 記録 特定の調整コードを付けて記録される財務取引です。 イベントタイプ explicit | |||
| 否認に異議を申し立て | 否認された請求に対して、ユーザーまたはシステムが異議申し立てを開始したことを示します。通常、ステータスの更新、または作業キューに作成された特定のタスクとして記録されます。 | ||
| 重要な理由 このアクティビティを起点に、手戻りのループが始まります。異議申し立ての頻度と成功率を分析することは、収益回収の取り組みを改善するうえで重要です。 入手先 ユーザーが明示的に開始したイベントとして記録される場合と、請求のステータスが「異議申し立て済み」や「審査中」に変わったことから推定する場合があります。 記録 否認された請求に対してユーザーが異議申し立てを開始した際のステータス変更または記録イベントです。 イベントタイプ explicit | |||
| 回収業務を開始 | 未払いを理由に、患者口座が回収プロセスに移されたことを示します。通常、口座の財務区分またはステータス区分の変更として記録されます。 | ||
| 重要な理由 貸倒債権を管理するうえで重要な段階です。この段階に至る要因と回収の成功率を分析することは、財務の健全性を保つために欠かせません。 入手先 口座のステータスが「回収対象」または「貸倒債権」に変わったことから推定します。このステータス変更にはタイムスタンプが必要です。 記録 口座のステータスが「回収対象」または同様の状態に変わったことから推定します。 イベントタイプ inferred | |||
| 患者に明細書を送付 | 患者負担分の請求書類を作成し、患者に送付したことを示します。患者請求モジュールに記録される明示的なアクションです。 | ||
| 重要な理由 これを起点に、収益サイクルの患者からの入金部分が始まります。追跡することで、患者からの回収状況を分析できます。 入手先 患者請求または通信のログから取得します。システムには、明細書の作成日または送付日が記録されている必要があります。 記録 患者向け明細書を作成し、印刷または電子送付した際に記録されるイベントです。 イベントタイプ explicit | |||
| 支払明細を受領 | 支払者から電子支払明細（ERA）または紙の給付内容説明書（EOB）を受領したことを示します。この文書には、支払い、否認、調整の対象となった請求項目が記載されています。 | ||
| 重要な理由 支払者からの最初の回答です。入金の進み具合を把握し、否認の傾向を早期に特定するうえで重要です。 入手先 支払明細処理モジュールに記録されます。請求に関連付けられたERAファイル（835取引ファイルなど）のインポートまたは作成タイムスタンプを確認してください。 記録 支払者の支払明細ファイル（ANSI 835など）のインポートと処理時に記録されるイベントです。 イベントタイプ explicit | |||
| 請求の否認を受領 | 支払明細に示された請求または特定の請求明細の否認を示します。多くの場合、支払明細データに含まれる否認コードから推定します。 | ||
| 重要な理由 否認を追跡すると、コーディングの誤りや資格要件の問題など、根本原因を特定し、請求の受理率を高めるうえで役立ちます。 入手先 支払明細（ERA／835）データから推定します。請求または明細にゼロ以外の否認額と対応する否認理由コードがある場合、このイベントが発生したと判断します。 記録 否認理由コード（CARC／RARC）を含む支払明細データから推定します。 イベントタイプ inferred | |||
| 請求項目をコーディング | 医療コーダーが、確定した請求項目にCPTやICD-10などの標準コードを割り当てるプロセスです。請求項目または受診記録のステータス変更で追跡できることが一般的です。 | ||
| 重要な理由 コーディングの遅れは、よくあるボトルネックです。このアクティビティを追跡すると、コーディングのワークフローにおける非効率と、請求スケジュールへの影響を特定できます。 入手先 多くの場合、患者の受診記録または請求バッチのステータス変更から推定します。たとえば「未コーディング」から「コーディング済み」への変更が該当します。ステータス変更のタイムスタンプが必要です。 記録 受診記録または請求のステータスが「コーディング済み」または「請求準備完了」に変わったことから推定します。 イベントタイプ inferred | |||
| 請求項目を確定 | 請求対象となるサービスや項目を患者口座に登録したことを示します。臨床システムから自動で登録される場合と、スタッフが手動で入力する場合があります。 | ||
| 重要な理由 このアクティビティは、サービス提供から請求開始までの時間を示す「請求遅延」の測定に欠かせません。請求遅延は、キャッシュフローと収益の正確性に直接影響します。 入手先 請求取引テーブルから取得し、各請求明細の作成タイムスタンプで特定します。Oracle Healthでは、請求関連のテーブルに記録されていることが一般的です。 記録 新しい請求項目ごとに作成される取引ログです。 イベントタイプ explicit | |||
データ抽出ガイド
ステップ
- データベースアクセスの申請：Oracle Health Revenue Cycleデータベースの読み取り専用認証情報を取得します。患者、受診、請求、金融取引のデータを含むスキーマへのアクセスが必要です。通常、ITセキュリティチームとデータベース管理チームの承認が必要です。
- スキーマ名とテーブル名の確認：データベース管理者またはシステムアナリストと連携し、使用中のOracle Health環境における正確なスキーマ名とテーブル名を確認します。クエリ内の名称は一般的な仮の値であり、実際の環境に合わせて置き換える必要があります。
- SQLクライアントのインストール：Oracle SQL DeveloperやDBeaverなど、互換性のあるSQLクライアントをワークステーションにインストールします。このツールを使ってデータベースに接続し、抽出スクリプトを実行します。
- データベース接続の設定：SQLクライアントで新しいデータベース接続を設定し、指定されたホスト、ポート、サービス名、認証情報を入力します。接続テストを行い、正常に接続できることを確認します。
- SQLクエリのカスタマイズ：提供されたSQLスクリプトを新しいクエリエディターにコピーします。
[START_DATE]や[END_DATE]などの仮の値を探し、分析対象の日付範囲（例：「2023-01-01」）に置き換えます。特定のPatient Classで絞り込むなど、分析の目的に合わせてフィルター条件を調整します。 - 抽出スクリプトの実行：カスタマイズした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という名称の場合があります。
クエリの例 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;始める準備はできていますか？
このテンプレートを使って、分析に適したデータを準備しましょう。収益サイクル管理プロセスの改善に、今日から取り組めます。
収益サイクルを改善し、入金を早める
ボトルネックを解消し、サイクルタイムを30％短縮して、キャッシュフローを改善します。
クレジットカードは不要です。数分で設定できます。