医療請求 RFP: 含める内容と回答の評価方法

Billing
Billing

Stripe Billing は、定期課金から段階制、ハイブリッドまで、あらゆる料金モデルに対応。ビジネスに合わせた柔軟な顧客管理を実現します。

もっと知る 
  1. はじめに
  2. 医療請求 RFP とは?
  3. 医療請求 RFP に含めるべきセクションの例とは?
    1. プロジェクト概要
    2. サービスの範囲
    3. テクノロジー連携要件
    4. コンプライアンスとレポート要件
    5. 料金体系の要件
    6. 評価基準とパフォーマンス指標
  4. 他の業界と比較して、医療請求 RFP に特有の点とは?
    1. すべてのレイヤーでの PHI 漏洩リスク
    2. 政府支払人の複雑さ
    3. 支払い拒否管理
    4. 患者支払いの機微性
  5. 医療請求 RFP の実際の運用とは?
    1. 社内合意
    2. マーケットスキャン
    3. 発行と質疑応答期間
    4. 提案レビュー
    5. ショートリストとデモンストレーション
    6. リファレンスチェック
    7. 契約交渉
  6. 最新の決済インフラは、医療請求の提案をどのように強化しますか?
    1. 統合決済の受け付け
    2. サブスクリプションとメンバーシップ請求
    3. PCI DSS 準拠
    4. EHR の相互運用性
  7. 医療請求 RFP で考慮すべきリスクと制約とは?
    1. 契約段階でのスコープクリープ
    2. 連携に関する過信
    3. 署名後に消えるパフォーマンス指標
    4. 契約終了時の PHI
    5. 導入スケジュールのリスク
  8. 医療請求 RFP への回答をどのように評価するか?
  9. Stripe Billing でできること

医療業界における提案依頼書 (RFP) から生まれる平均売上は 10 億ドルを超えていますが、その獲得は並大抵のことではありません。医療請求 RFP は、医療機関が請求ベンダーを選定する際に発行する文書であり、特有の要件が伴います。保護対象医療情報 (PHI) の漏洩リスク、政府支払人を取り巻く状況の課題、支払い拒否管理、患者支払いの機微性といった重要領域は、すべて文書自体で網羅する必要があります。これらの領域が、提案の比較や契約交渉の段階になって初めて表面化するようでは遅すぎます。

以下では、医療 RFP の例、RFP プロセスの進め方、ベンダーから受け取る提案の評価方法について説明します。

ハイライト:

  • 医療請求 RFP は、PHI の取り扱い、電子医療記録 (EHR) 連携の具体事項、支払い拒否管理プロセスについて明示的に扱う必要があります。

  • 請求代行サービスの RFP と請求システムの RFP の区別は、作業範囲の記述から料金体系まで、あらゆる点に影響します。

  • 最新の決済インフラは、患者支払いの受け付け、継続課金、消し込みを 1 つの連携に統合することで、ベンダーの提案を強化できます。

医療請求 RFP とは?

医療請求 RFP は、医療機関が請求業務、請求システム、あるいはその両方の全部または一部を取り扱うベンダーを探す際に発行する正式な文書です。範囲、法令遵守要件、技術仕様、そして提案を採点する基準を定義します。

医療請求 RFP に含めるべきセクションの例とは?

適切に構築された医療請求 RFP の構造は、組織の規模、診療科、支払人構成によって内容が異なる場合でも、一般的に予測可能な構成に従います。各セクションはそれぞれ特定の役割を果たします。

プロジェクト概要

ベンダーを求める理由を具体的に説明します。業界ベンチマークを超える支払い拒否率、いまだに紙の明細書で運用されている患者債権回収ワークフロー、臨床システムと請求システム間の消し込みを破綻させた EHR の移行など、抱えている問題を明示します。

サービスの範囲

ベンダーに処理してもらう必要がある業務を列挙します。請求ライフサイクル管理、コーディングサポート、患者への請求書発行と債権回収、保険金の消し込み、レポート作成などです。含める項目が増えるほどベンダーが対応すべき事項も増えるため、回答の長さと評価時間も長くなります。

テクノロジー連携要件

ベンダーが連携する必要のある EHR または診療管理システム (PMS) を明示します。また、アプリケーションプログラミングインターフェイス (API) ファーストのアーキテクチャが必須か、ファイルベースのデータ交換も受け入れるか、そしてシステムが手作業の介在なしに決済と請求を照合できるかどうかも指定します。サブスクリプション型またはメンバーシップ型ケアモデルを採用している場合は、その点も明記します。

コンプライアンスとレポート要件

PHI の保護対策、決済処理における Payment Card Industry Data Security Standard (PCI DSS) のコンプライアンス、すべての請求活動に関する監査ログの記録、そして財務チームが回収実績と未回収の売掛金 (AR) を明確に把握できる財務レポートについて、ベンダーに対応を求めます。

料金体系の要件

明細化された料金体系をリクエストします。バンドル料金では、サービス要素ごとに支払っている金額が不明瞭になるためです。請求単位の取引コスト、連携と導入の費用、トレーニング費用、およびベンダー手数料が回収成果に連動する成果連動型の料金体系についても提示を求めます。

評価基準とパフォーマンス指標

RFP の回答と、導入後のベンダーのパフォーマンスの両方を採点するために使用するベンチマークを定義します。具体的には、クリーンクレーム率の目標、AR 日数、初回解決率 (FPRR)、支払い拒否のフォローアップに関するサービスレベル契約 (SLA) のコミットメントなどです。これらを RFP に含めることは、ベンダーに説明責任を求める姿勢を示すシグナルとなり、具体的な数値にコミットする意思のないベンダーを除外することにもつながります。

他の業界と比較して、医療請求 RFP に特有の点とは?

医療請求 RFP には、ロジスティクスソフトウェアや金融サービスの RFP とは一線を画すいくつかの違いがあります。PHI の漏洩リスク、政府支払人の課題、支払い拒否管理、患者支払いの機微性が重なり合うことで、独自のニーズが生まれます。以下でその内容を説明します。

すべてのレイヤーでの PHI 漏洩リスク

請求取引の多くには保護対象医療情報が関わります。つまり、アメリカではベンダーとの契約に事業提携者契約 (BAA) などの合意文書が必要となります。RFP では、PHI がどのように取り扱われ、保管され、転送されるのか、そして契約終了時に PHI がどうなるのかを正確に説明するようベンダーに求める必要があります。

政府支払人の複雑さ

アメリカの Medicare や Medicaid などの政府請求は、民間支払人への請求にはないルールのもとで運用されています。この分野で働くベンダーは、政府請求ガイドライン、地域保険適用判断 (LCD)、および政府プログラムで求められる特定の請求書式を理解する必要があります。政府プログラムの経験が必須と明記されていない RFP には、民間支払人の請求は問題なく処理できても政府支払人への対応には苦労するベンダーから、回答が集まりがちです。

支払い拒否管理

医療請求を管理する際、支払い拒否は日常的な業務の一部です。ベンダーが支払い拒否にどう対応するかによって、売上回収の大部分が決まります。支払い拒否管理のプロセスについて、異議申し立ての平均成功率や対応期間を含め、詳しく説明するようベンダーに依頼してください。

患者支払いの機微性

患者は、支払うべき金額とその理由に戸惑う可能性があり、強引な回収体験は診療関係を損ないかねません。RFP では、患者とのやり取りの方法、対応している支払い支援オプション、そして外部の回収機関に委託する前の債権管理の方法について、ベンダーに質問する必要があります。

医療請求 RFP の実際の運用とは?

医療 RFP のプロセスには数週間かかることがありますが、複数の診療部門を抱える複雑な医療ネットワークではさらに長引く可能性があります。知っておくべき手順を以下にご紹介します。

社内合意

RFP を発行する前に、範囲を定義し、財務、臨床業務、情報技術 (IT)、法令遵守の各部門から関係者の承認を得ます。ベンダーは、チームがまだ答えを出していない質問をしてくる可能性があるため、先に社内で対応しておくのが賢明です。

マーケットスキャン

既知のベンダー、紹介、事前の情報提供依頼書 (RFI) への回答を組み合わせて、RFP の送付先ベンダーを特定します。既存のベンダーについて十分な知識を持たないカテゴリーに参入する際は、RFI のステップをスキップしないでください。

発行と質疑応答期間

ベンダーからの質問の期限を定めたうえで RFP を配布し、すべての回答者に同時に回答を公開します。これによりプロセスの公正性が保たれ、有力なコネクションを持つベンダーが他社の得られない情報を入手することを防げます。

提案レビュー

部門横断的な審査チームで、評価基準に照らして回答を採点します。財務、IT、法令遵守の各部門は、調達部門のみの審査では見落とされる問題を見つけることが少なくありません。

ショートリストとデモンストレーション

最終候補のベンダーを数社招き、ライブデモやシステムウォークスルーを実施します。その際、ベンダーが準備したスクリプトではなく、実際の請求環境から引き出したシナリオを用います。

リファレンスチェック

同じ診療科または同規模の、ベンダーが現在取引しているクライアントに連絡します。ベンダーが自発的に提供したリファレンスだけに頼らないようにしてください。支払い拒否管理の実績と EHR 連携の信頼性について具体的に尋ねます。

契約交渉

RFP の回答における料金体系と SLA のコミットメントをベースラインとして使用します。ベンダーが契約時に具体的な内容を反故にしようとする場合、それは真剣に受け止めるべきシグナルです。

最新の決済インフラは、医療請求の提案をどのように強化しますか?

ベンダーが RFP の回答で決済機能について説明する際、従来の請求システムと最新の決済インフラのギャップがすぐに明らかになることがあります。以下の点に留意してください。

統合決済の受け付け

統合インフラは、カードとデジタルウォレットの受け付け、請求書の自動発行、支払い計画の管理をサポートします。これは RFP の文脈で重要です。なぜなら、ベンダーが対面決済、オンライン患者ポータル、継続課金のために別々のシステムをつなぎ合わせる必要がないことを意味するからです。消し込みは 1 つの連携を通じて、これらすべてにわたり一貫して実行されます。

サブスクリプションとメンバーシップ請求

サブスクリプション型またはメンバーシップ型ケアモデルに移行した組織では、継続課金とプラン変更時の比例配分の自動処理に対応する必要があります。従来の請求プラットフォームの多くはそれを想定して構築されていないため、手作業による消し込み作業、レポートの抜け、エラーが発生しやすい回避策につながります。

PCI DSS 準拠

PCI DSS レベル 1 コンプライアンスは、医療請求 RFP のコンプライアンスセクションで一般的に求められる決済処理の領域をカバーします。コンプライアンス対応の決済インフラを基盤とすることで、医療機関にとって PCI の維持管理が簡素化されます。

EHR の相互運用性

請求代行サービス会社にとどまらず決済代行業者として事業を行うベンダーは、既存の EHR や PMS を置き換えるのではなく、そのまま連携できます。これこそが、RFP で EHR の相互運用性について質問する際にベンダーが実証すべき点です。

Stripe Billing は、PCI DSS レベル 1 認定を受け、グローバルな利用向けに構築された単一のプラットフォームで請求と決済を統合します。

医療請求 RFP で考慮すべきリスクと制約とは?

適切に構成された RFP はベンダーのリスクを軽減しますが、排除はできません。制約の多くは、RFP の書き方によって対処できます。

契約段階でのスコープクリープ

ベンダーは、曖昧な RFP の記述に対して同様に曖昧な提案で応じ、契約段階で範囲を大幅に狭めてくる場合があります。契約書が提案内容を反映せざるを得ないほど、作業範囲セクションを十分に具体的に記述してください。

連携に関する過信

「[EHR 名] と連携している」という表現は、認証済みの双方向連携から、カンマ区切り値 (CSV) のエクスポートまで、あらゆるものを意味しうる表現です。連携について詳しく説明するようベンダーに依頼してください。どのデータがどの方向にどの頻度で流れるか、EHR が更新された際に何が破綻するのかを含めて確認します。また、連携は実装に必要なエンジニアリング作業の規模も異なる場合があります。連携を実現するために組織側に求められる開発レベルも確認してください。

署名後に消えるパフォーマンス指標

ベンダーが RFP の回答で約束するクリーンクレーム率と AR ベンチマークは、未達の場合の結果を明示したうえで契約書に記載する必要があります。SLA に記載されていなければ、それはコミットメントではありません。

契約終了時の PHI

契約締結前に、ベンダー切り替え時に患者データがどう扱われるかをベンダーに必ず説明してもらいます。返却スケジュール、破棄証明、データ形式の要件はすべて RFP に列挙する必要があります。これにより、後になって圧力下で交渉するのではなく、ベンダーが提案書の段階でこれらに対応するようになります。

導入スケジュールのリスク

ベンダーは、特に EHR 連携が関わる場合、本番稼働スケジュールを過小評価する可能性があります。類似案件での導入スケジュールを提示するようベンダーに依頼し、その数値に基づいて契約上のマイルストーンを設定します。

医療請求 RFP への回答をどのように評価するか?

一般的には、RFP で定義した基準に照らして提案を採点します。

ベストプラクティスをいくつかご紹介します。

  • 一次評価でのブラインド採点: ベンダーのプレゼンテーション前に、審査担当者に基準に照らして提案を採点してもらい、第一印象で評価が歪まないようにします。審査は部門横断チームで行うことを忘れないでください。

  • 曖昧な回答は減点: プロセスを一般論で説明する提案は、プロセス、ツール、指標を具体的に挙げる提案よりも低く採点すべきです。提案の曖昧さは、契約段階での曖昧さを予兆するサインであることが多いです。

  • ビジネスインパクトに応じて基準を重み付け: 最大の課題が支払い拒否率であれば、その基準にはレポートダッシュボードのデザインよりも大きな重みを置く必要があります。提案が届く前に採点ルーブリックを構築することで、ベンダーの回答によって評価方法が左右されないようにします。

  • 提案から契約へのズレに注意: 評価プロセスは、記載した問題に対応できなかったベンダーを見抜く機会でもあります。RFP のすべての項目に対応していながら、プロジェクト概要で挙げた具体的な課題には触れていない提案は、契約締結後にそのベンダーがどのようにコミュニケーションするかを示唆しています。

Stripe Billing でできること

Stripe Billing を使用すると、シンプルな継続課金から従量課金、商談による契約まで、自由に請求や顧客管理を行えます。ノーコードで、グローバルな継続課金をわずか数分で開始できます。API を活用した独自のシステム構築も可能です。

Stripe Billing でできること:

  • 柔軟な料金体系の提供: 従量課金、段階制料金体系、定額料金 + 超過料金など、柔軟な料金モデルでユーザーのニーズにすばやく対応できます。クーポン、無料トライアル、比例配分、アドオンのサポートも組み込まれています。

  • グローバルに拡大: 顧客が希望する決済手段を提供することでコンバージョンを向上させます。Stripe は 100 以上の現地決済手段と 130 以上の通貨をサポートしています。

  • 売上を伸ばし解約を防止: Smart Retries と回収ワークフローの自動化で、売上回収を効率化し、決済不履行による解約を減らせます。Stripe のリカバリツールは、2024 年に 65 億ドル以上の売上回収をサポートしました。

  • 業務効率の向上: Stripe のモジュール型税務管理、収益レポート、データツールを活用して複数の収益管理システムを 1 カ所に統合します。外部のソフトウェアとも簡単に連携できます。

Stripe Billing について詳しくはこちらをご覧ください。今すぐ始める場合はこちら

この記事の内容は、一般的な情報および教育のみを目的としており、法律上または税務上のアドバイスとして解釈されるべきではありません。Stripe は、記事内の情報の正確性、完全性、妥当性、または最新性を保証または請け合うものではありません。特定の状況については、管轄区域で活動する資格のある有能な弁護士または会計士に助言を求める必要があります。

その他の記事

  • 問題が発生しました。もう一度お試しいただくか、サポートにお問い合わせください。

今すぐ始めましょう

アカウントを作成し、支払いの受け付けを開始しましょう。契約や、銀行情報の提出などの手続きは不要です。貴社ビジネスに合わせたカスタムパッケージのご提案については、営業担当にお問い合わせください。
Billing

Billing

新規事業や新製品の収益化と、継続的な決済の受け付けをサポートします。

Billing のドキュメント

サブスクリプションの作成と管理、使用量の追跡、請求書の発行を行います。