レセプトシステム開発の発注/外注/依頼/委託方法について

レセプトシステムの発注・外注では、安い製品を選ぶだけでは不十分です。医科・歯科・調剤・訪問看護の業務範囲、診療報酬改定への対応、外部システム連携、データ移行、障害時の代替運用まで含めて、将来の運用を見据えて委託先と契約することが重要です。

この記事では、レセプトシステムを発注・外注・委託するときの進め方を、発注形態の選択、RFPと要件整理、契約形態、費用相場、委託先選定、見積比較の順に解説します。既製品の導入が向くケースと独自開発が必要なケースを分け、2026年時点の制度変更や公開価格、導入事例も踏まえて、発注前に確認すべき項目を具体化します。

▼全体ガイドの記事
・レセプトシステム開発の完全ガイド

レセプトシステムを発注・外注する前に知っておきたい全体像

レセプトシステムは、診療や調剤の情報を診療報酬明細書にまとめ、点検や請求、返戻・査定への対応まで支える業務システムです。発注時は「レセコン本体」だけでなく、周辺機能と運用支援をどこまで委託するかを決める必要があります。

同じものではありません。レセコンは患者情報、保険資格、診療行為、点数計算、会計、レセプト作成を担う医事会計システムです。一方、レセプト点検システムは作成した請求データの算定漏れや記載誤りを確認する仕組みで、保険者向けのレセプト分析基盤は請求後のデータ分析を主な目的とします。RFPには「何を導入するか」だけでなく、「どの業務をどのシステムに残すか」まで書く必要があります。

医科・歯科・調剤・訪問看護のどれを対象にするか、診療所か病院か、外来だけか入院・DPCまで扱うか、単院か複数拠点かを最初に分けます。診療所の標準的なレセコン導入と、病院の医事会計・電子カルテ・DPC・部門システムを統合する開発では、必要な専門性も費用も大きく変わります。受付、資格確認、診療入力、会計、レセプト作成、点検、請求、返戻、再請求、経営分析のどこまでを発注するかを一覧にすると、ベンダーとの認識違いを抑えられます。

レセプトシステムの発注形態はどれを選ぶべきですか？

発注形態は、標準パッケージ・クラウド導入、既存システムへの追加開発、ハイブリッド型、フルスクラッチ開発の4つに分けて考えると整理しやすいです。診療報酬や公費のルールに継続して追随する必要があるため、機能の自由度だけでなく、制度改定への責任を誰が負うかで選ぶことが大切です。

新規開業、小規模診療所、一般的な医科・歯科・薬局業務であれば、実績のあるパッケージやクラウドを導入し、標準機能に業務を合わせる方法が有力です。診療報酬・薬価・傷病名・公費などのマスター更新、オンライン請求、障害対応がサービス側で継続されるため、ゼロから開発するより短期間で稼働しやすいです。

公開価格の一例として、日本医師会ORCA管理機構のWebORCAクラウド版は、基本サービスが1医療機関あたり月額2,200円（税込）です。TLS1.2サービスは端末証明書1枚あたり月額550円で、10枚までは月額2,200円が上限とされています（出典: 日本医師会ORCA管理機構「WebORCA クラウド版」）。ただし、導入支援、端末、回線、オンライン資格確認、周辺連携、教育、保守がすべて含まれる価格ではないため、月額だけで総額を判断してはいけません。

電子カルテやレセコンを残しながら、予約、問診、決済、オンライン資格確認、電子処方箋、経営分析などを追加したい場合は、既存システムへの連携開発が向いています。全面刷新より業務変更を抑えられますが、患者ID、保険情報、診療行為コード、病名コード、請求データのマッピングを先に設計しなければなりません。

RFPには、API・CSV・HL7/FHIRなどの連携方式、送信失敗時の再送、重複登録の防止、監査ログ、個人情報の取り扱い、障害発生時の責任分界を明記します。既存ベンダーがAPIを公開しているか、連携仕様書を引き渡せるかによって、見積もりの確度が変わります。

標準製品では特殊な診療報酬、複数法人の業務、独自の請求・分析フロー、保険者向けの大規模データ処理などを満たせない場合に、スクラッチ開発を検討します。自由度が高い一方、診療報酬改定、公費・薬価マスター、請求記録条件仕様、返戻・再請求への追随を自社または開発会社が継続して担います。

いきなり受付から分析までを一度に作るのではなく、請求データ連携・点検、受付・会計、返戻・分析のように分割し、PoC、段階稼働、並行運用、切替リハーサルを組み込みます。発注時には、初期開発だけでなく制度改定対応の保守契約と、開発会社を変更する場合のデータ・仕様書の引き渡し条件まで確認します。

RFPと要件整理はどのように進めますか？

レセプトシステムの見積もりが大きくぶれる原因は、業務要件が「使いやすくしたい」「返戻を減らしたい」といった目的だけで止まり、画面・データ・例外処理まで落とし込めていないことです。現場の業務を一連の流れで可視化し、必須要件と希望要件を分けてからRFPを作成します。

最初に「受付→資格確認→診療入力→会計→レセプト作成→点検→請求→返戻→再請求」の流れを図にします。各工程で、担当者、入力データ、参照するマスター、出力帳票、承認者、エラー時の対応を記録します。病院であれば入院・DPC・未収金・部門システムを、薬局であれば調剤、在庫、薬歴、訪問対応を、対象範囲に応じて追加します。

要件はMUST、SHOULD、WANTの3段階に分けます。MUSTにはオンライン請求、資格情報、診療報酬計算、返戻・再請求、法令・制度対応など、止められない業務を置きます。WANTに独自帳票や高度な分析を詰め込みすぎると、初期費用と納期が膨らむため、第一段階の稼働後に追加する候補として分離します。

患者基本情報、保険者番号、資格情報、公費、負担割合、医療機関情報、診療行為、薬剤、材料、病名、請求・返戻履歴など、移行と連携の対象データを一覧化します。項目名だけでなく、コード体系、桁数、必須・任意、更新元、履歴保持、削除条件、エラー時の扱いまで確認します。

既存システムから何年分のデータを移すのか、過去のレセプトを参照専用で残すのか、旧システムをいつまで保管するのかも要件です。移行テストでは、複数保険、公費、高額療養費、月跨ぎ、訂正、返戻、請求取消などの実データに近いケースを使い、件数だけでなく金額や帳票の一致まで検証します。

レセプトシステムは医療情報を扱うため、機能要件と同じ重さで安全管理を確認します。厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン」第7.0版を公表し、経営管理、企画管理、システム運用、保守委託機関などの編を示しています（出典: 厚生労働省「医療情報システムの安全管理に関するガイドライン 第7.0版」、2026年）。委託先には、アクセス権限、認証、暗号化、ログ、バックアップ、脆弱性対応、委託先管理、インシデント報告の方法を質問します。

クラウドを選ぶ場合は、データの保管場所、バックアップの世代数、復旧目標時間、通信障害時の入力・請求手順、サービス停止時の連絡先を契約前に確認します。オンプレミスでも、サーバー故障やランサムウェアを想定した復旧手順が必要です。平常時の便利さだけでなく、診療を止めずに請求締切を迎えるための代替運用を、受入テストの対象にします。

契約形態と発注時の役割分担をどう決めますか？

レセプトシステムの契約では、要件が固まっている部分と、調査しながら決める部分を分けて契約します。すべてを一つの契約に詰め込むより、企画・要件定義、設計・開発、テスト・移行、保守・運用の責任と成果物を分けた方が、変更時の判断がしやすくなります。

請負契約は、合意した成果物を完成させ、検収する開発に向いています。画面一覧、機能仕様、連携仕様、移行計画、テスト計画、操作マニュアルなど、何を納品するかを明記し、検収の期限、未達時の修正、追加要望の扱いも定めます。

レセプトでは、画面が表示されるだけでは受入完了になりません。複数保険、公費、返戻、再請求、診療報酬改定後のマスター、オンライン請求ファイルなど、業務シナリオごとの合否基準を契約書や別紙に置きます。「医療機関の確認が遅れた場合」「制度変更が途中で発生した場合」の費用と納期も、事前に取り決めます。

準委任契約や時間精算型は、現状調査、要件定義、PoC、既存データの調査など、作業量を事前に確定しにくい工程に向いています。作業時間だけでなく、担当者、上限時間、成果物、定例報告、課題管理、追加作業の承認手順を定めることが重要です。

要件定義を準委任で進め、仕様が固まった後の開発を請負に切り替える構成もあります。発注者側に業務判断ができる責任者がいないと、会議だけが増えて仕様が決まらないため、医事、現場、情報システム、経営の代表者をプロジェクト体制に置きます。

契約終了時に患者データをどの形式で返却するか、移行に必要なマスターやAPI仕様書を誰が保有するか、ログを何年間保存するかを確認します。サービス解約後にデータを取り出せないと、次のベンダーへ移行できず、長期的な費用や交渉力に影響します。

また、診療報酬改定、公費制度、薬価、請求仕様の変更に対して、どの範囲を標準保守で対応するのかを分けます。改定対応の期限、テスト環境の提供、改定後の問い合わせ窓口、追加費用の有無を契約書とサービス仕様書の両方で確認します。

レセプトシステムの発注費用・開発費用の相場

レセプトシステムの費用は、標準製品の月額利用料と、独自開発の初期費用を同じ相場として比べてはいけません。公開価格で確認できる導入例、販売事業者の構成例、一般的な業務システムからの推定を分けて見ると、見積もりの妥当性を判断しやすくなります。

標準導入では、初期費用が0円から数十万円程度、月額が数千円から数万円程度の公開プランもあります。たとえば、電子カルテとレセコンを含むCLIUS Directには月額19,800円、初期費用0円からという公開例がありますが、訪問サポート、追加端末、連携設定、レクチャーなどの条件は個別に確認が必要です。これは電子カルテ一体型の導入例であり、純粋なレセコン単体の相場を示すものではありません。

また、ORCAの導入価格を公開する販売事業者の例では、導入基本サービス25万円、機器設定10万円、機器一式約64.8万円、年間保守18万円とされ、患者データの抽出15万円と取込25万円を加えると、データ移行前で約100万円から、移行を含めて約140万円程度になる構成です（出典: パシフィックシステム「ORCA 導入価格」）。これは一事業者の構成例であり、端末数、機器、施設規模、連携内容で変わるため、発注時は内訳の比較に使います。

独自開発の公的な一律相場はありません。以下は、業務システム一般で示される小規模300万〜1,500万円、標準1,500万〜4,000万円、SE月額80万〜120万円という情報を土台に、レセプト固有のマスター、請求仕様、医療情報セキュリティ、外部連携を加味した推定レンジです（出典: NotebookLMリサーチノート「業務システム全般_1」）。正式な見積もりではなく、発注前の予算仮置きとして利用します。

既存レセコンへの小規模な追加開発・連携は500万〜1,500万円程度、診療所や複数拠点向けの独自業務システムは1,500万〜4,000万円程度、中〜大規模病院の統合・刷新は3,000万〜1億5,000万円以上になる可能性があります。期間も、追加連携は3〜6か月、独自業務システムは6〜12か月、病院の統合は9〜18か月以上が目安ですが、これは要件、データ移行、並行稼働、制度対応の範囲で変動する推定です。

保守・運用は、初期開発費の年5〜15％程度を目安に置く考え方がありますが、一般的な業務システムの目安であり、レセプトシステムにそのまま当てはまるとは限りません。実際の契約では、クラウド利用料、ユーザー・端末数、請求件数、マスター更新、診療報酬改定、問い合わせ時間、オンサイト対応、バックアップ、セキュリティ監視などに分かれることがあります。

見積書では、初期費用、機器・回線、データ移行、連携開発、教育、月額利用料、改定対応、保守、障害対応、追加開発を別項目にします。5年間の総保有コストで比較し、月額が安い代わりに改定対応や訪問サポートが別料金になっていないかを確認します。

委託先の選定と見積比較で確認すべきポイント

委託先は、知名度や提示金額だけで決めず、対象となる診療科・施設規模の経験と、導入後に制度変更へ対応する体制を確認します。相見積もりは同じRFPを渡し、機能、前提、除外範囲、納期、保守条件を揃えて比較することが重要です。

「医療業界の実績」があるだけでは不十分です。医科・歯科・調剤・訪問看護のどれか、診療所か病院か、外来か入院・DPCか、単院か複数拠点かを分けて、類似案件の導入件数、担当範囲、稼働後の年数を聞きます。オンライン請求、オンライン資格確認、電子処方箋、電子カルテ、予約、決済、会計との連携実績も、自院の構成に近いものかを確認します。

2026年は、医科・DPC向けの共通算定モジュールが本格実施され、診療報酬改定に関するシステム改修コストの削減が期待されています。一方、歯科・薬局・訪問看護への導入時期は決まっていないとされています（出典: 厚生労働省「共通算定モジュールとの連携コード値一覧」等、2026年）。診療科によって制度対応の前提が異なるため、営業資料ではなく、実際の改定時に何をどの期限で対応したかを確認します。

見積書を受け取ったら、要件ごとに「標準機能」「設定で対応」「追加開発」「対象外」を並べます。特に、データ移行の対象期間、移行前のデータクレンジング、端末設定、マスター登録、連携試験、操作研修、並行稼働、切替当日の立会いが含まれているかを確認します。対象外が多い見積もりは安く見えるため、同じ条件に置き換えて総額を比較します。

さらに、見積もりの前提条件を質問します。患者数、月間レセプト件数、利用者数、端末数、拠点数、連携先、過去データの年数、稼働希望日、施設側が用意する作業を確認します。回答が曖昧な会社は、開発中に追加費用が発生するリスクが高いため、提案内容と議事録に残します。

選定評価は、価格だけでなく、類似実績、診療科・施設規模への適合、制度改定対応、外部連携、データ移行、セキュリティ、導入後サポート、契約終了時のデータ返却の7〜9項目に分けると比較しやすいです。重要度に応じて配点を変え、例えば返戻削減が目的なら点検・資格確認・再請求の評価を高くします。

導入効果も「業務を効率化する」と書かず、返戻件数、点検時間、入力回数、請求締め後の修正件数、障害からの復旧時間などの指標にします。NTT東日本の歯科クリニック事例では、オンライン資格確認とオンライン請求の導入により、月20件ほどあった資格過誤による返戻がゼロになったと紹介されています（出典: NTT東日本「歯科クリニックの受付業務とレセプト点検が激変」、2026年時点で確認できる掲載事例）。これは一施設の事例であり、同じ効果を保証するものではありませんが、発注時に測定指標を設定する参考になります。

開発後のテスト・移行・運用を成功させる方法

レセプトシステムは、納品日に画面が動けば終わりではありません。診療報酬の計算、請求ファイル、返戻・再請求、権限、帳票、連携、障害時の手順を実データに近い条件で確認し、現場が毎月の締め作業を安全に回せる状態まで作り込みます。

テストケースには、通常の外来だけでなく、保険変更、公費併用、負担割合変更、高額療養費、月途中の資格喪失、薬剤・材料、年齢条件、月跨ぎ、訂正、返戻、請求取消を含めます。医科・歯科・調剤・訪問看護で必要なケースが違うため、現場担当者に「実際に困った例」を出してもらい、匿名化したデータや再現用のケースとして登録します。

受入基準は、画面の操作性だけでなく、入力結果、点数、患者負担、出力ファイル、帳票、ログ、エラー通知、再処理結果で判断します。改定後のマスターを適用した状態で、旧システムとの並行計算を行い、差分が出た場合に原因を追えるようにします。

移行では、対象データの抽出、形式変換、名寄せ、コード変換、取込、照合、差分修正、バックアップを工程化します。患者データをすべて新システムへ移せない場合は、参照専用の旧環境を残す期間と、問い合わせ時の確認方法を決めます。移行を「一度の取込作業」と見なすと、稼働後の過去履歴参照や返戻対応で問題が起きやすいです。

切替前には、リハーサル、並行稼働、ロールバック条件、問い合わせ窓口、紙や手作業に切り替える場合の様式を準備します。診療を止められない施設では、夜間・休日の切替、旧システムの保管、請求締切をまたぐ場合の責任者を、委託先と共同で確認します。

導入教育は、全員に同じ説明を一度行うだけでは定着しません。受付、医事、請求責任者、管理者ごとに操作と判断が異なるため、役割別の研修、操作マニュアル、よくあるエラーへの対応表、改定時の再研修を用意します。現場のキーユーザーを決め、一次問い合わせを集約すると、委託先への連絡も効率化できます。

サポート契約では、受付時間、緊急障害の定義、初動時間、復旧目標、オンサイト対応、改定時の相談窓口、保守対象外の条件を確認します。クラウドであっても、通信障害や端末故障は起こり得るため、代替手順と連絡先を現場がすぐ確認できる形にします。

よくある質問（FAQ）

最後に、レセプトシステムの発注・外注で特に質問の多い点をまとめます。費用や納期は施設の条件で変わるため、回答を自院のRFPと見積比較に置き換えて確認してください。

一般的な診療所や新規開業であれば、改定対応や請求機能が整った既製品・クラウドを基本にし、必要な連携だけを追加する方法が適しています。特殊な診療報酬、複数法人の独自業務、大規模な分析や統合がある場合は、既存製品とのハイブリッドや段階的な独自開発を検討します。独自開発を選ぶ場合は、初期費用だけでなく、改定対応と保守を長期契約で負担できるかを判断します。

まず、標準導入、追加連携、独自開発を分け、初期費用、移行費用、端末・回線、教育、月額、保守、改定対応を含む5年間の総額を置きます。標準導入は公開価格や販売事業者の構成例を参考にできますが、独自開発は推定レンジに過ぎないため、要件定義後の見積もりで更新します。予算上限だけを伝えず、MUST要件と第一段階で実現したい効果を共有すると、過不足の少ない提案を受けやすくなります。

類似する診療科・施設規模の実績、診療報酬改定への対応期限、オンライン請求・資格確認・電子処方箋への対応、データ移行の範囲、障害時の復旧、保守の時間帯、追加費用の条件、契約終了時のデータ返却を質問します。可能であれば、提案担当だけでなく、導入責任者、保守責任者、医療制度に詳しい担当者の体制も確認します。

必要です。オンライン請求を行う医療機関・薬局では、返戻レセプトの扱いもオンライン化されており、使用中のレセコンが対応しているか確認するよう厚生労働省が案内しています（出典: 厚生労働省・地方厚生局「オンラインによる返戻再請求の実施について」、2024年以降の案内）。RFPには、請求ファイルの作成、送信前点検、返戻データの取込、修正、再請求、履歴管理、エラー時の再処理を一連の業務として記載します。

まとめ

レセプトシステムの発注・外注では、最初にレセコン、点検、分析、周辺連携の対象範囲を分け、標準パッケージ・クラウド、追加連携、ハイブリッド、スクラッチのどれが自院に合うかを判断します。標準機能で足りる部分を無理に開発せず、独自性が必要な部分だけを段階的に委託すると、費用と制度対応のリスクを抑えやすくなります。

次に、受付から請求・返戻・再請求までの業務をRFPに落とし込み、MUST/WANT、データ移行、連携仕様、受入テスト、セキュリティ、BCP、契約終了時のデータ返却を明記します。見積もりは初期費用だけでなく、機器、移行、教育、月額、保守、診療報酬改定対応を含む総額で比較し、類似実績と導入後の責任体制を確認することが大切です。

特に2026年は、令和8年度診療報酬改定、共通算定モジュール、医療情報システム安全管理ガイドライン第7.0版など、制度・安全管理の変化を前提に選定する必要があります。価格の安さだけで決めず、改定に追随し、返戻を減らし、障害時にも請求業務を継続できる委託先を選ぶことが、長期的に安定したレセプト運用につながります。

▼全体ガイドの記事
・レセプトシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。