レセプトシステムの発注は、まず対象業務を決め、発注形態を選んだうえでRFPを作り、契約と見積もりを比べて進めます。テストと移行まで確認すると、制度改定にも対応できる運用につながります。
発注形態、費用の相場、委託先の選び方、開発後の移行の順に説明します。
▼全体ガイドの記事
・レセプトシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
レセプトシステムを発注・外注する前に知っておきたい全体像
レセプトシステムは、診療や調剤の情報を診療報酬明細書にまとめる業務システムで、点検、請求、返戻・査定への対応も支えます。発注時は、レセコン本体に加えて、周辺機能と運用支援をどこまで委託するかを決めます。
レセコン・レセプト点検システム・分析基盤の違い
三者は、それぞれ役割が異なります。レセコンは、患者情報、保険資格、診療行為、点数計算、会計、レセプト作成を担います。
一方で、レセプト点検システムは、請求データの算定漏れや記載誤りを確認します。保険者向け分析基盤は、請求後のデータ分析が目的です。
役割が異なるため、RFPには導入対象に加えて、各業務をどのシステムに残すかも書きます。
最初に決める対象範囲
まず、対象を医科・歯科・調剤・訪問看護に分け、施設が診療所か病院かを決めます。そのうえで、外来だけか、入院・DPCも含むかを決めます。
単院か複数拠点かも整理しておきます。標準的な診療所への導入と、病院の医事会計・電子カルテ・DPC・部門システム統合とでは、必要な専門性も費用も異なります。
受付から経営分析までの業務を、どこまで発注するかで一覧にします。資格確認、点検、返戻、再請求などの扱いを、ここで明確にします。一覧があれば、ベンダーとの認識違いを抑えられます。
レセプトシステムの発注形態の選び方
発注形態は、標準パッケージ・クラウド、追加開発、ハイブリッド、フルスクラッチに分けられます。選ぶ際は、制度改定への対応を誰が担うかも基準になります。
標準パッケージやクラウド導入が向くケース
標準パッケージやクラウドでは、どの施設に向くかと、サービスにどこまでの対応が含まれるかを確かめます。
- 導入対象：新規開業、小規模診療所、一般的な医科・歯科・薬局業務が該当します。
- 制度対応：診療報酬・薬価・傷病名・公費のマスター更新、オンライン請求、障害対応を、サービス側が継続します。
- 稼働時期：標準機能に業務を合わせる形は、ゼロからの開発より短期間で稼働しやすい点が特徴です。
公開価格の例では、WebORCAクラウド版の基本サービスが1医療機関あたり月額2,200円（税込）、TLS1.2は端末証明書1枚あたり月額550円です。
証明書は10枚まで月額2,200円が上限です（出典：日本医師会ORCA管理機構「WebORCA クラウド版」）。
ただし、この価格に導入支援や端末、保守が含まれるとは限りません。ほかの費用として、次の項目も確かめる必要があります。
- 回線：別途費用になるかどうか。
- オンライン資格確認：対応費用の有無。
- 周辺連携：連携費用の範囲。
- 教育：研修費用の有無。
月額だけで総額を判断しないよう注意します。
既存システムへの追加開発・ハイブリッド型が向くケース
既存システムを活かす連携開発では、追加機能とデータ連携の設計を先に固めます。
- 追加機能：候補になるのは、予約、問診、決済、資格確認、電子処方箋、経営分析です。
- 連携設計：患者ID、保険情報、診療行為・病名コード、請求データの対応付けが中心です。
既存の仕組みを残す分、全面刷新に比べて業務の変更を抑えられます。
RFPには、API・CSV・HL7/FHIRなどの連携方式や、送信失敗時の再送、重複登録の防止を書きます。監査ログや個人情報の扱いも含め、障害が起きた際にどこまでを誰が受け持つかも明記します。
既存ベンダーがAPIを公開しているか、連携仕様書を出せるかによって、見積もりの確からしさが変わります。
スクラッチ開発を検討する場合
標準製品では満たせない要件があるときに、スクラッチ開発を検討します。
- 対象要件：特殊な診療報酬、複数法人の業務、独自の請求・分析、大規模データ処理が該当します。
- 段階開発：請求連携・点検、受付・会計、返戻・分析に分け、PoCや段階稼働を組み込みます。
新規開業や小規模診療所、一般的な医科・歯科・薬局業務では、標準機能に業務を合わせる方法が有力です。
自由度は高い一方で、診療報酬改定への追随は自社か開発会社が担います。この追随の対象は、公費・薬価マスター、請求記録条件仕様、返戻・再請求にも及びます。
標準のサービスでは、マスター更新、オンライン請求、障害対応をサービス側が継続します。スクラッチでは、これらを誰が続けるかを契約で明確にしておく必要があります。
発注時には、並行運用と切替リハーサルも計画に組み込みます。
初期開発だけでなく、制度改定対応の保守契約も確かめます。開発会社を変える場合に備えて、データと仕様書の引き渡し条件も定めておきます。
どの型を選ぶ場合も、制度改定への対応を誰が担うかは、契約前に確かめておく必要があります。
電子カルテやレセコンを残して、予約、問診、決済、オンライン資格確認、電子処方箋、経営分析を追加する場合は、既存を活かす追加開発が適しています。その際は、患者ID、保険情報、診療行為コード、病名コード、請求データの対応付けを先に設計します。
RFPと要件整理の進め方
見積もりの前提を定めるには、「使いやすくしたい」「返戻を減らしたい」といった希望を、具体的な要件に置き換える必要があります。そのため、業務の流れを書き出し、必須要件と希望要件に分けてRFPを作ります。
現場業務の書き出し（受付から再請求まで）
業務フローとRFPの要件を、工程、施設の種類、優先度ごとに整理します。
- 業務フロー：受付から資格確認、診療入力、会計、レセプト作成、点検、請求、返戻、再請求までを図にします。
- 工程情報：工程ごとに、担当者、入力データ、参照マスター、帳票、承認者、エラー対応を記録。
- 施設別要件：病院では入院・DPC・未収金・部門を、薬局では調剤・在庫・薬歴・訪問対応を加えます。
- 優先度：MUST、SHOULD、WANTの区分で、必須と希望を分けます。
MUSTには、オンライン請求、資格情報、診療報酬計算を置きます。さらに、返戻・再請求と法令・制度対応も必須に含めます。一方で、WANTに独自帳票や高度な分析を詰め込むと、初期費用と納期が膨らみます。そのため、初回稼働後の候補として分けておきます。
データ項目と外部連携の仕様
移行と連携の仕様は、対象データ、定義、保存・移行条件、テスト方法の四つに分けて決めます。
- 対象データ：患者基本情報、保険者番号、資格、公費、負担割合、医療機関、診療行為、薬剤、材料、病名、請求・返戻履歴が含まれます。
- データ定義：コード、桁数、必須・任意の区分、更新元、履歴、削除条件、エラー時の扱い。
- 移行条件：移行年数、過去レセプトの参照専用化、旧システムの保管期間の取り決め。
- テスト：複数保険、公費、高額療養費、月跨ぎ、訂正、返戻、請求取消を含めた確認。
移行テストでは、件数だけでなく、金額や帳票が一致するかも確かめます。
RFPに含めるセキュリティとBCP
安全管理と事業継続は、ガイドライン、委託先、環境ごとの復旧策から確かめます。
- ガイドライン：厚生労働省は2026年6月に安全管理ガイドライン第7.0版を公表しました。
- 委託先管理：アクセス権限、認証、暗号化、ログ、バックアップ、脆弱性、事故報告の扱い。
- クラウド：保管場所、バックアップ世代数、復旧目標時間、通信障害時の手順、停止時の連絡先。
- オンプレミス：サーバー故障やランサムウェアからの復旧手順を定めます。
レセプトシステムは医療情報を扱うため、安全管理も機能要件と同じ重さで確かめます。
同版では、経営管理、企画管理、システム運用、保守委託機関などの編が示されています（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年）。
請求締切まで診療を続けるための代替運用も、受入テストに含めます。
画面やデータ、例外処理まで業務要件に落とし込むと、現場の流れが見えてきます。そのうえで、テストは複数保険や高額療養費などを含む、実データに近いケースで行います。
契約形態と発注時の役割分担
要件は、確定しているものと、調査しながら決めるものに分けます。企画・要件定義と設計・開発の工程では、責任と成果物を分けておきます。テスト・移行と保守・運用の工程でも同じように分けておくと、変更があったときに判断しやすくなります。
請負契約の要件と検収条件
請負契約では、納品物、検収条件、変更時の扱いを事前に合意しておきます。
- 納品物：画面一覧、機能・連携仕様、移行・テスト計画、操作マニュアルを明記します。
- 検収条件：期限、未達時の修正、追加要望の扱いを定めたうえで、画面表示だけでは完了にしない。
- 業務シナリオ：複数保険、公費、返戻、再請求、改定後マスター、請求ファイルの合否基準。
特に、画面表示だけで受入を完了にしない点は、契約書に残しておきます。また、医療機関の確認が遅れた場合や、制度変更が途中で起きた場合の費用と納期も、事前に決めておきます。
変更が多い工程での準委任・時間精算
準委任や時間精算型は、作業量を事前に決めにくい工程で使われます。
- 対象工程：現状調査、要件定義、PoC、既存データ調査が該当します。
- 契約条件：担当者、上限時間、成果物、定例報告、課題管理、追加作業の承認。
- 発注体制：医事、現場、情報システム、経営の代表者と、業務判断の責任者を置きます。
要件定義は準委任で進め、仕様が確定した後に請負へ切り替える方法もあります。なお、発注側に責任者がいないと、会議を重ねても仕様が決まりません。
データ・仕様・改定対応の所有者
契約が終わった後のデータ移行や、診療報酬改定に備えて、責任の範囲を確かめます。
- データと仕様：契約終了時の患者データ返却形式、マスターやAPI仕様書の保有者、ログ保存年数。
- 改定対応：標準保守の対象、改定期限、テスト環境、問い合わせ窓口、追加費用の有無を、契約書と仕様書で照らし合わせる。
データを取り出せないと、次のベンダーへ移行できず、費用や交渉力にも影響します。
レセプトシステムの発注費用・開発費用の相場
標準製品の月額と独自開発の初期費用は、同じ相場として比べられません。そのため、公開価格、販売事業者の構成例、一般システムからの推定を分けて見ます。
標準導入・クラウドの価格に含まれるもの
標準導入の価格は、一般的な公開プランと、個別の構成例に分けて見ます。
- 公開プラン：初期費用0円から数十万円、月額数千円から数万円程度の例があります。
- CLIUS Direct：電子カルテ一体型で月額19,800円、初期費用0円からの公開例です。
- ORCA構成：導入基本25万円、機器設定10万円、機器一式約64.8万円、年間保守18万円です。
訪問支援や追加端末、連携設定などの条件は、個別に確かめる必要があります。また、CLIUSはレセコン単体の相場ではありません。
患者データの抽出15万円と取込25万円を加えると、データ移行前で約100万円から、移行を含めると約140万円程度になる構成です（出典：パシフィックシステム「ORCA 導入価格」）。
ORCAの金額は一事業者の構成例で、端末数や施設規模、連携内容によって変わります。そのため、内訳の比較に使うのが適しています。
独自開発の費用の見積もり範囲
独自開発の予算は、業務システム一般の数値を土台にした推定として扱います。
- 一般的な開発規模：小規模300万〜1,500万円、標準1,500万〜4,000万円です。
- SE単価：月額80万〜120万円を、推定の土台にします。
- 追加連携：500万〜1,500万円程度、期間は3〜6か月が目安です。
- 独自業務システム：1,500万〜4,000万円程度、期間は6〜12か月が目安です。
- 病院統合：3,000万〜1億5,000万円以上、期間は9〜18か月以上の可能性があります。
レセプト固有のマスター、請求仕様、医療情報セキュリティ、外部連携を加味した数値です（出典：NotebookLMリサーチノート「業務システム全般_1」）。
公的な一律の相場ではなく、正式な見積もりの前に置く予算の仮置きです。
費用と期間は、要件やデータ移行の範囲で変わる推定です。並行稼働や制度対応の範囲も、同じように影響します。
保守・運用費用と初期費用の分け方
保守費は初期費用と分けて、契約項目と5年間の総額を確かめます。
- 保守費の目安：初期開発費の年5〜15％という考え方があります。
- 契約項目：クラウド、ユーザー・端末数、請求件数、マスター更新、改定対応、問い合わせ時間。
- 運用項目：オンサイト、バックアップ、監視、障害対応、追加開発を確認します。
年5〜15％は一般システムの目安で、レセプトにそのまま当てはまるとは限りません。
初期費用と月額は分けて見積もり、5年間の総保有コストで比べます。改定対応や訪問サポートが別料金かも確かめます。
- 機器・回線：見積もりに含むかどうか。
- 移行：データ移行の費用。
- 連携開発：外部システムとの接続費用。
- 教育：研修にかかる費用。
ORCA構成例（出典：パシフィックシステム「ORCA 導入価格」）や、業務システム一般の数値（出典：NotebookLMリサーチノート「業務システム全般_1」）は、前提がそれぞれ異なります。
見積もりでは、障害対応と追加開発も別項目にします。
委託先の選定と見積比較の確認点
知名度や提示額だけで決めないよう、診療科と施設規模の経験、制度変更への対応体制を見ます。そのうえで、同じRFPを渡して相見積もりし、機能、前提、除外範囲、納期、保守条件をそろえて比べます。
診療科・施設規模・制度対応の実績
実績では、施設・診療内容との適合性と、制度改定時の対応力を確かめます。
- 類似施設：医科・歯科・調剤・訪問看護、診療所・病院、外来・入院・DPCの区分で照合。
- 導入経験：単院・複数拠点の類似案件数、担当範囲、稼働後の年数を尋ねます。
- 連携実績：請求、資格確認、電子処方箋、電子カルテ、予約、決済、会計との接続実績。
営業資料だけでなく、制度改定時の対応内容と期限も確かめます。2026年には、医科・DPC向けの共通算定モジュールが本格実施され、改修コストの削減が期待されています。一方で、歯科・薬局・訪問看護の導入時期は未定です。
制度対応の前提は、診療科によって異なります（出典：厚生労働省「共通算定モジュールとの連携コード値一覧」等、2026年）。
見積書の作業と前提での比較
見積もりは、対応区分、作業範囲、前提条件をそろえて比べます。
- 要件別の区分：標準機能、設定対応、追加開発、対象外の区分。
- 作業範囲：移行、データ整理、端末、マスター、連携試験、研修、並行稼働、切替立会い。
- 前提条件：患者・請求件数、利用者・端末・拠点数、連携先、移行年数、稼働日、施設側作業。
対象外が多い見積もりは安く見えやすいため、同じ条件にそろえて総額で比べます。前提条件への回答が曖昧だと追加費用のリスクが高まるので、提案内容と議事録に回答を残します。
価格以外の評価項目と点数化
価格以外の評価軸を設けて、目的に合う配点と、導入後の指標を決めます。
- 評価項目：実績、施設適合、改定、連携、移行、安全、支援、データ返却など7〜9項目。
- 配点：返戻削減が目的なら、点検・資格確認・再請求の配点を厚くします。
- 効果指標：返戻件数、点検時間、入力回数、締め後の修正、復旧時間などで測る形。
NTT東日本の歯科事例では、資格確認とオンライン請求により、月20件ほどの資格過誤による返戻がゼロになったと紹介されています（出典：NTT東日本「歯科クリニックの受付業務とレセプト点検が激変」、2026年時点で確認できる掲載事例）。
この事例は一施設の結果で、同じ効果を保証するものではありません。
導入件数、担当範囲、稼働年数は、単院か複数拠点か、外来か入院かといった区分ごとに尋ねます。連携の実績も、自院に近い構成かどうかで確かめます。操作研修や並行稼働、切替当日の立会いを見積範囲に含むかを確かめ、患者数や稼働希望日などの前提条件を尋ねます。
開発後のテスト・移行・運用を成功させる方法
納品日に画面が動いただけでは、完了とは言えません。計算や請求ファイル、返戻・再請求などの業務結果まで確かめます。障害時の手順も含めます。
現場が毎月の締め作業を安全に行える状態まで、作り込みます。
実際の例外ケースによる受入テスト
受入テストでは、例外ケースと出力結果、改定後の並行計算を確かめます。
- 資格・負担：保険、公費、負担割合の変更、高額療養費、月途中の資格喪失を試します。
- 診療・請求：薬剤・材料、年齢条件、月跨ぎ、訂正、返戻、請求取消。
- 合否確認：入力、点数、患者負担、ファイル、帳票、ログ、通知、再処理の検証。
診療科ごとに異なる実例は、現場から集めて、匿名化データか再現ケースとして用意します。
合否は操作性だけでなく、業務結果と出力内容で判断します。
改定後のマスターで旧システムと並行計算し、差分の原因を追える状態にしておきます。
データ移行と切替日の管理（別プロジェクト）
移行工程と切替準備は、分けて管理します。
- 移行工程：抽出、形式・コード変換、名寄せ、取込、照合、差分修正、バックアップ。
- 旧環境：全データを移せない場合に、参照専用で残す期間と照会方法を定める。
- 切替準備：リハーサル、並行稼働、ロールバック条件、窓口、紙・手作業の様式。
患者データをすべて移せない場合は、参照専用の旧環境を残す期間と、問い合わせ時の確認方法を決めます。移行を一度きりの取込作業と見なすと、稼働後の過去履歴の参照や返戻対応で問題が起きやすくなります。
切替前には、準備内容を委託先と確かめておきます。
診療を止められない施設では、夜間・休日の切替や旧システムの保管、請求締切をまたぐ責任者を、委託先と決めます。
教育と稼働後サポートの窓口
役割別の教育と、稼働後の支援体制、障害時の代替策を整えておきます。
- 研修：受付、医事、請求責任者、管理者ごとに実施します。
- 現場支援：マニュアル、エラー対応表、改定時の再研修を用意し、キーユーザーが窓口を担います。
- 契約内容：受付時間、緊急障害、初動、復旧目標、訪問、改定窓口、保守対象外。
通信障害や端末故障に備えて、代替手順と連絡先を、現場がすぐ見られる形にしておきます。
テストでは、通常の外来に加えて、保険変更や公費併用、高額療養費、月途中の資格喪失などの例外も対象にします。薬剤や年齢条件、請求取消なども含めます。
合否は、入力結果と点数、出力ファイルの中身などで判断します。
移行は、抽出から照合、差分修正、バックアップまでの工程に分けて計画します。
移行できない履歴がある場合は、旧環境を参照専用で残す期間と、問い合わせ時の確認方法を決めます。切替前には、リハーサルや並行稼働、ロールバック条件、問い合わせ窓口を準備します。紙や手作業の様式も用意します。
よくある質問（FAQ）
費用や納期は施設の条件によって変わります。ここでの回答は、自院のRFPと見積もりの比較に置き換えて確かめてください。
レセプトシステムは既製品と独自開発のどちらがよいですか？
一般的な診療所や新規開業では、改定対応と請求機能が整った既製品やクラウドを基本にします。そのうえで、必要な連携だけを追加する方法が適しています。
特殊な診療報酬や複数法人の独自業務、大規模な分析・統合がある場合は、ハイブリッドや段階的な独自開発を検討します。
独自開発では、初期費用だけでなく、改定対応と保守を長期の契約で負担できるかも判断します。
レセプトシステムの発注予算はどのように決めますか？
標準導入、追加連携、独自開発を分けて考えます。そのうえで、初期費用や月額、保守などを含む5年間の総額を置きます。
- 標準導入：公開価格や販売事業者の構成例が参考になります。
- 独自開発：推定レンジは仮置きとし、要件定義後の見積もりで更新します。
- 共有する内容：予算の上限に加えて、MUST要件と第一段階の効果も伝えます。
こうした情報をそろえて伝えると、過不足の少ない提案につながります。
委託先にはどのような質問をすればよいですか？
類似する診療科や施設規模の実績、改定対応の期限、請求・資格確認・電子処方箋への対応、移行範囲を聞きます。
障害復旧、保守時間、追加費用の条件、契約終了時のデータ返却についても確かめます。
導入と保守の責任者、医療制度に詳しい担当者がいるかという体制も聞きます。
オンライン請求や返戻再請求はRFPに必要ですか？
必要です。オンライン請求を行う医療機関・薬局では返戻もオンライン化され、使用中のレセコンの対応確認を厚生労働省が案内しています（出典：厚生労働省・地方厚生局「オンラインによる返戻再請求の実施について」、2024年以降の案内）。
RFPには、請求ファイルの作成から再請求までを一連の業務として記載します。送信前の点検や履歴管理、エラー時の再処理も、その流れに含めます。
まとめ
まず、レセコン、点検、分析、周辺連携の範囲を分けたうえで、標準・クラウド、追加連携、ハイブリッド、スクラッチから選びます。
標準機能を活用し、独自の部分だけを段階的に委託すると、費用と制度対応のリスクを抑えやすくなります。
RFPには、MUST/WANTの区分や移行、連携などを明記します。受入テストやセキュリティ、BCP、データ返却も含めます。そのうえで、機器や保守などを含めた総額と、実績・責任体制を比べます。
2026年は、令和8年度診療報酬改定や共通算定モジュール、安全管理ガイドライン第7.0版などの変化を踏まえる必要があります。改定に追随でき、返戻を減らせて、障害時にも請求を続けられる委託先であることが、安定した運用につながります。
▼全体ガイドの記事
・レセプトシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。