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