Categories: PMG Insights Blog

October 21, 2013

Healthcare Revenue Cycle Managementは、複雑です。 ICD-10が目前に迫っており、事態がこれ以上簡単になるとは思えません。

1. Did you get paid?
2. If you didn’t get paid, why not?
3. If you did paid, did you get what you should have according to your insurance contracts?

質問1はかなりカット＆ドライです。 質問2はもう少し複雑になります。 特定の請求が拒否された理由を見つけるために送金状やEOBを見ることはそれほど難しくありませんが、拒否された請求の原因を知っていますか？ コーディングの問題なのか、それともフロントや登録スタッフの質に問題があるのか？ PM/請求システム内の設定に問題があるのでしょうか、それとも請求が正しく入力されていないのでしょうか？ このような理由で拒否される請求の頻度を知ることができますか？ この情報によって、収益サイクルを改善することができますか。

否認のデータが紙の束に埋もれている場合、それを見つけるのは面倒だと言えます。 これを聞いたとき、私はいつも少し不安になります。 なぜしないのか」と尋ねると、「時間がない」「請求システムからレポートを実行するよりも、EOBから直接否認を処理する方が簡単だ」というのが最も一般的な答えです。 実際には、請求システムにデータを入力しない主な理由は、そうしないことでどれだけのお金をテーブルの上に置いているかに気づいていないためです。 請求担当者は、最大の頭痛の種が何であるか知っていると言いますが、それを定量化するように頼むと、彼らはできません。 通常、「よくあることです」「たくさんあります」といった答えが返ってきます。

もし彼らが知っていたら、否認の管理と解決にもっと戦略的なスタンスを取っていたでしょうということです。 もし知っていたら、もっと戦略的に否認の管理と解決に取り組んでいたでしょう。 請求担当者はEOBを丹念に調べ、クレームに電話をかけたり、キャリアのウェブサイトで修正したりしますが、そもそも否認の原因となったプロセスの問題は決して修正されません。

支払人がクレームを支払わないことを警告するのは、クレームサイクルのどの段階なのかを知っておくことが重要です。 請求の提出プロセスにおいて、支払人は請求ファイルを「フォーマット」と「コンテンツ」の2つの領域で分析します。 今は「収益を最適化する」ための請求のことは忘れ、支払人に何らかの請求をする必要があるのです。 HIPAA X12の各フォーマットは、支払人ごとにすべて同じです。 ループセグメント2000Bは、特定のフォーマットの中で変わることはありません。 もしあなたのクレームファイルが最小限のフォーマット基準を満たさない場合、支払人はファイル全体を拒絶し、たとえ良いクレームでも蹴散らされます。 すべての請求システムが拒否された請求ファイルを追跡する機能を持っているわけではありませんが、もしあなたがクリアリングハウスや請求サービスを使用しているのであれば、間違いなくそうでしょう。

たとえ標準フォーマットの要件を満たしていても、特定の請求フォーマットの中で、支払人は請求ファイルで提供されるコンテンツを決定する独自のガイドラインを使用することができます。 例として（表 1）、ある州のメディケイドプランは、訪問の CPT 詳細情報をすべてフルフィーで請求するよう求めるかもしれませんが、別の州は、CPT 詳細情報を 0.00 ドルにして、T1015 をフルフィーで請求するよう求めます。

同じ請求ファイル形式を使用する 2 つの異なる支払者は、異なる内容で満たすことを要求することができます。

（表1）

支払者があなたの請求ファイルを受け入れると、あなたは、次のことを行うことができるようになりました。 彼らは、最も初歩的な支払いルール（つまりは、「支払い」）をクリアしているかどうかを確認するために、これらの請求を精査し始めるのです。例えば、患者の保険 ID が ID 番号形式の規則と一致するかどうかなど）。 この時点で、審査に通らなかった個々の請求は、支払者のシステムから「拒否」されます。 保険会社はそのクレームをシステムに登録することさえしません。 完全に追い出されるだけです。 これは、リジェクトとディニュアルの重要な違いである。 これらの拒絶は、スクラバーレポートとして、ダウンロードすることができます（通常、クレームをアップロードしたのと同じ場所から）。 これらの拒否されたクレームを追跡するための強力なプロセスがない場合、ファイリングリミットやその他の項目で収益を失う可能性があります。 支払人のシステムにクレームがないことは、早い段階で失敗を招くことになります。 請求がこのスクラバープロセスに合格すると、支払いまたは拒否の判定が行われます。

Denial Reason Codes CO-45 & CO-109

これらの拒否の理由は「理由コード」を使って伝えられます。 これらのコードは、請求業務の生命線です。 ワシントン出版は、これらのコードとその説明のリストをhttp://www.wpc-edi.com/reference/で無料公開しています。 このリンクをお気に入りの1つにしてください。

多くの理由コードは本質的に情報的であるため、少し水を差す傾向があります。 たとえば、100ドルの請求を送信し、保険契約が80ドルのサービスしかカバーしていない場合、請求を支払ってCO-45（Charge Exceeds fee schedule/maximum allowable or contracted/legislated fee arrangement）のコードを返すかもしれません。 この場合、あなたは支払いを受け、支払人は単に請求のどの部分が保険契約に従って許可されなかったかを伝えています。

他のコードはもっと具体的になります。 CO-109 (Claim/service not covered by this payer/contractor) は、解決すべき給付の調整の問題がある可能性があることを示しています。 もし、このようなコードがたくさん出てきたら、フロントでの仕事が必要であることがわかります。 9160>

CO-16 Denial Code

いくつかの拒否コードは、別のレイヤー、リマークコードにあなたをポイントします。 リマークコードは、さらに具体的になります。 ある請求に対して、CO-16（Claim/Service lacks information which is needed for adjudication）という理由コードが表示される場合があります。 少なくとも一つのリマークコードが提供されなければならない）。 このCO-16は、それ自体では情報提供のみで、何を修正する必要があるかはわかりません。 リマークコードと CPT と組み合わせると、全体像が見えてきます。

さて、このような情報をすべて、年間送信するプロシージャーコードの数に掛けてみてください。 結局、かなりの量になります。 実際、スタッフがEOBから直接分析することを期待できる数よりもはるかに多いのです。 では、これらの情報がすべて利用可能であるならば、なぜ請求システムに登録する必要があるのでしょうか。 まず、収益サイクルに関しては、課金システムが「真実の源」であるべきです。 すべての請求業務とレポートは、請求システムによって作成された財務レポートに結びつけられる必要があります。

最も重要なことは、否認データを請求システムに投稿することで、否認レポートを実行し、ボリュームと支払者によって比較し始めることができるように設定することです。 これなしでは、スタッフ (管理者と介護者の両方) のために実用的なデータを作成する機会を失います。 フロントでの簡単なプロセス変更またはPMシステムの修正により、これらの請求が最初に拒否されることを防ぐことができます。 決して支払われない訪問を看護師が行っていることが判明し、そのお金をドブに捨てていることになるかもしれません (そのお金は、ヘルス センターの他のニーズを満たすために重要です)。 影響が小さいかもしれない問題を追いかけるのに、多くの時間を費やすことになります。 支払い計上時にこれらの理由コードを転記するのに費やす時間は、収益サイクル業務に加えることのできる最もインパクトのある変更の1つになり得ます。