医療機関向け医事会計システム開発の発注/外注/依頼/委託方法について

医療機関向け医事会計システムの発注では、まず業務範囲と標準機能を確認します。そのうえで、RFP、比較、契約、移行の順に進めると、請求を止めずに運用できます。

全体像は、医療機関向け医事会計システム開発の完全ガイドにもまとめています。

▼全体ガイドの記事
・医療機関向け医事会計システム開発の完全ガイド

医療機関向け医事会計システムの発注・外注の範囲

医療機関向け医事会計システムは、患者情報や保険資格、診療行為、点数、公費をもとに窓口負担額を計算します。レセプト作成・点検からオンライン請求までを支える、医療事務の基幹システムです。

発注する側は、電子カルテ、オーダリング、オンライン資格確認、自動精算機、財務会計との間で、どこまでを誰が受け持つかも契約の対象として決めておきます。

医事会計と財務会計の違い

医事会計と財務会計は、扱う対象と計算内容が異なります。

  • 医事会計:患者ごとの診療内容から保険請求額と窓口負担を算定します
  • 財務会計:医療法人や病院全体の仕訳、決算、資金管理を扱います

両者は売上や入金データで連携しますが、同じシステムとは限りません。そのため、RFPでは「患者向け会計」「診療報酬請求」「経営・財務会計」を分けて記載すると、対象範囲の誤解を防げます。

診療所と病院での発注条件の違い

施設規模によって、必要な機能と運用体制は変わります。

  • 無床診療所:受付・診療入力・会計・レセプトは標準機能が中心。電子カルテ等と連携
  • 有床診療所・中小病院:入院・定期請求、DPC、病棟・部門システム、未収金管理が加わる
  • 大病院・複数病院:共通マスターや診療科別例外、経営分析、24時間保守、災害時の代替運用も調達

無床診療所では、オンライン資格確認との連携も整理します。一方で、有床診療所や中小病院は、移行とテストの範囲が広がります。

発注形態の選び方

標準パッケージ、クラウドサービス、パッケージへの追加開発、スクラッチ開発を並べた発注形態の図。
標準機能で満たせる範囲を起点に、追加開発の必要性を見極めます。

発注形態は、標準パッケージ、クラウドサービス、パッケージへの追加開発、スクラッチ開発の順に検討します。まず、標準機能で事業継続に必要な要件を満たせるかを確かめます。満たせるなら、改定対応や保守の負担を抑えやすい方式が有力です。

独自業務がある場合は、全面的な作り込みを先に決めず、標準機能で吸収できる差分と、追加開発が必要な差分に分けます。

クラウド型とパッケージ型の使い分け

院内の設備や運用体制に合わせて、方式ごとの利点と管理項目を比べます。

  • クラウド型:新規開業や少人数体制と好相性で、院内サーバーの設置・更新を減らしやすい
  • クラウド型の確認事項:障害時の代替運用、端末認証、バックアップ、データ返却条件
  • 院内サーバー型:既存ネットワークや周辺機器と密に連携しやすい
  • 院内サーバー型の確認事項:サーバー更新、バックアップ、制度改定時の検証担当

追加開発とスクラッチ開発を選ぶ場面

追加開発は、公費や特殊な請求、既存部門システムとの連携など、標準パッケージで扱えない差分を補う場合に向いています。

スクラッチ開発は、複数病院の統合や特殊業務があり、標準製品では事業継続上の要件を満たせない場合に限って検討します。

作り込むほど、診療報酬改定時の検証範囲やベンダーロックインが広がります。そのため、変更しない業務を決めることも、発注判断の一部になります。

分割発注とハイブリッド型の扱い

分割発注では、担当範囲と各社共通の取り決めを明確にします。

  • 発注先の分担:医事会計本体は専門ベンダー、電子カルテや自動精算機は各メーカーへ発注
  • 注意点:専門性を生かせる一方、障害時の原因や責任が曖昧になりやすい
  • 事前合意:インターフェース仕様、マスターの正本、一次窓口、切替判定、追加費用の負担者を全社共通文書に記載

要件整理と進行管理は、別の支援会社に委託することもできます。

ポイント

標準機能で事業継続に必要な要件を満たせるかを先に確かめ、満たせない部分だけを追加開発の対象にします。独自業務の差分も、標準機能で吸収できるかどうかで分けて考えると判断の目安になります。

医療機関向け医事会計システムの発注・外注の進め方

外注は、見積を取って終わりではありません。次の工程を一続きで設計します。

  1. 現行業務を洗い出す
  2. 調達方式を決める
  3. RFPを配布する
  4. 提案を評価して契約する
  5. 設計・設定とテストを進める
  6. 職員を教育する
  7. システムを切り替える
  8. 稼働後に改善する

請求業務には月次の締め日があるため、開発日程に加えて、並行稼働とレセプト請求のリハーサル日程を先に置いておきます。

企画段階で決める項目

企画段階では、導入目的、施設の業務条件、調達時期を固めます。

  • 導入目的:会計時間短縮や返戻減少など、業務成果で示す
  • 施設・業務条件:施設区分、診療科、病床、DPC、訪問診療、公費、自費の一覧
  • 既存環境:電子カルテ、周辺機器、端末数、拠点数の状況
  • 調達時期:現行契約の更新日・保守期限の確認と、切替不能な時期の回避

これらの条件をもとに、調達スケジュールを作ります。目的には、請求担当者の負担軽減や経営分析の精度向上も含めます。

RFPに書く項目

RFPには、業務要件と提案・見積の回答条件を具体的に書きます。

  • 基本情報:背景、対象範囲、現行環境、必須と希望の要件
  • 導入条件:連携・移行の対象、導入日程、保守の条件
  • 回答形式:提案書の様式と、見積の分解方法の指定
  • 受入条件:返戻の取り込み、原因と修正履歴の確認、再請求まで追跡できること
  • 優先度と対応方法:MUST、SHOULD、WANTの区分と、標準機能・設定・追加開発・運用回避のどれで対応するかの回答

提案評価から稼働までの確認事項

提案評価では、デモの見栄えより、実際の業務シナリオを確かめます。シナリオには、診療科や公費の扱いに加え、返戻、未収金、入院請求を含めます。

契約後は、要件定義と基本設計、設定・追加開発から本番切替までの判定基準を、工程ごとに合意します。テストは単体・連携・総合・受入の各段階があり、教育や並行稼働も含めて決めておきます。

切替の前に、本番と同等のデータで請求額を照合します。そのうえで、旧システムとの件数と金額の差を説明できる状態にしておきます。

ポイント

判断の目安は、開発日程より先に、請求の締め日と並行稼働、レセプト請求のリハーサルの日程を置けるかどうかです。外注は見積の取得で終わらず、稼働後の改善までを一続きで見ます。

RFP・要件整理で抜け漏れを防ぐポイント

RFP・要件整理の見出しを中心に、業務シナリオ、関係部門、連携・移行、セキュリティ・BCPの確認範囲を結んだ図。
機能要件に加え、関係者や移行後の運用まで確認範囲に含めます。

要件に漏れがあると、稼働後に手作業が増え、請求の精度や職員の負担に直結します。そこで要件は、機能名ではなく、患者受付から請求・入金・分析までの業務シナリオと例外処理で書き出します。

医事課に加えて、診療部門や看護部門の参加も必要です。経理、情報システム、経営層も含めます。そのうえで、判断者と承認ルートも決めておきます。

診療報酬・公費・入院業務の確認事項

外来診療では、保険資格と公費、自賠責、自費を確認します。加えて、返金、未収金、患者負担の上限も見ておきます。

入院業務では、入退院や定期請求の扱いに加え、食事・室料、DPC、包括・出来高の区分を確認します。さらに、病棟や診療科から実施情報を取り込めるかも確かめます。

また、訪問診療やリハビリなど施設固有の算定と例外を、サンプルデータで再現します。あわせて、計算結果の根拠を確認できる画面と履歴も評価します。

連携とデータ移行で決める要件

連携と移行は、対象と仕様、範囲、照合方法をセットで要件に含めます。

  • 連携対象:電子カルテ、オーダリング、検査、薬剤、給食、自動精算機、キャッシュレス決済、オンライン資格確認・請求、財務会計
  • 連携仕様:送受信項目、頻度、エラー時の再送、マスター管理者、APIや標準規格の利用可否
  • 移行範囲:患者基本情報、保険・公費、未収金、返戻・査定、過去請求、マスター。移行しないデータの保管方法も決める
  • 移行検証:テスト移行と本番移行を分け、件数と金額の照合結果を記録する

セキュリティとBCPの要件

安全性は、環境の種類だけでなく、次の対策と運用をRFPで確認して判断します。

  • アクセス管理:利用者ごとの権限、認証方式、多要素認証、操作ログ
  • 情報保護:保存・通信時の暗号化、脆弱性対応
  • 保守・復旧:バックアップ世代、復元テスト、委託先のリモート保守
  • 緊急時の継続:回線断やランサムウェア時の受付・診療・会計・請求の代替手順、インシデント連絡体制

厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン第7.0版」を公表しています。同じ月には、医療機関・薬局向けのサイバーセキュリティ対策チェックリストも公表されています。この基準を提案の確認にも使うと、抜け漏れを減らせます(出典:厚生労働省、2026年)。

契約形態と責任分界の決め方

請負契約の「完成と検収」と準委任契約の「専門家による業務遂行」を左右に並べた比較図。
成果物の完成を求める工程か、専門業務の遂行を求める工程かで整理できます。

要件定義・開発、設定、データ移行、教育、運用保守では、作業の性質が異なります。そのため、向く契約の形も工程ごとに変わります。

発注側は、すべてを一つの契約にまとめるより、成果物と責任を定めやすい工程と、協議しながら進める工程を分けるほうが、変更時のトラブルを抑えられます。

契約名よりも、条項の中身で確かめます。成果物と検収の決め方から、変更の扱い、追加費用、障害対応までが対象です。

請負契約が向く工程

請負契約は、合意仕様に基づくシステム、設定、移行ツールなどの完成と検収を目的とする工程に向いています。

まず、納品物と受入条件、検収期限を明確にします。次に、瑕疵対応と遅延時の扱い、仕様変更の手続きを決めておくと、契約が機能します。

要件が変わりやすい初期段階や、稼働後の改善を固定の成果物で縛ると、変更のたびに追加の見積が発生しがちです。

準委任契約が向く工程

準委任契約は、専門家が業務を遂行する工程に向いています。要件整理や業務設計、プロジェクト管理などが該当します。調査や運用支援も、この形の対象になります。

担当者の役割と稼働時間、工数の上限を明確にし、報告方法や意思決定の期限、再委託の条件も決めます。この契約は、成果物の完成を保証することを目的としていません。

医療機関側も、レビューや承認を遅らせない体制を用意します。ベンダー任せで要件が決まる状態を避けるためです。

契約書での責任分界の明記

医事会計本体からオンライン請求まで、提供と保守の担当者を図にして示します。対象には、電子カルテや部門システムに加え、ネットワークや端末、自動精算機も含みます。

診療報酬改定や公費マスター更新の責任者、障害の一次受付、復旧目標も確認します。さらに、データの所有権と返却形式を定め、ログの保管や脆弱性情報の通知、終了時の移行支援も決めます。

再委託先が患者情報にアクセスする場合は、その範囲と監査の方法も契約に含めます。

ポイント

成果物の完成を求める工程は請負契約、専門業務の遂行を求める工程は準委任契約と、工程ごとに分けて考えます。契約名ではなく、条項の中身で判断すると迷いにくくなります。

医療機関向け医事会計システムの費用相場と見積の読み方

費用は、施設の条件と、移行、連携本数、カスタマイズ、24時間保守の内容によって変わります。施設の条件には、施設規模、端末数、診療科があります。病床、DPC、公費、既存システムも、この条件に含まれます。

平均価格で一つにまとめず、費用は項目ごとに比べます。まず、初期費用、ライセンス・利用料、連携・移行を分けて見ます。加えて、教育、機器・ネットワーク、保守・改定対応も、別の項目として扱います。

次の金額は、公開料金、公的契約事例、一般的な開発費をもとにした目安で、個別案件の定価ではありません。

施設規模別の費用相場

公開料金と契約事例をもとにした推定の目安です。比べるときは、規模と対象範囲をそろえます。

  • 小規模診療所:ソフト周辺の初期費用は40万〜100万円程度、月額は2万〜5万円程度の推定です。リサーチノート上の公開料金・導入事例を基準にしています
  • 追加費用:端末、プリンタ、VPN、導入支援、電子カルテ連携、サポート契約を加えると上振れします
  • 日レセクラウド:基本サービスは1医療機関あたり月額2,200円。VPNルータ型は初期6万6,000円・月額2,200円
  • 中小病院:導入・移行費は1,500万〜5,000万円程度が起点です。電子カルテ・DPC・部門連携、過去データ、複数病棟、24時間保守で高くなります
  • 大規模案件:東京都立病院機構は2025年、医療情報基幹システムの設計・開発・移行等を14病院分44億円(税込)で契約

日レセクラウドの公開料金には、認定サポート事業所の作業費や機器費は含まれません(出典:日本医師会ORCA管理機構、確認日2026年8月)。

東京都立病院機構の契約には、端末・ネットワーク・運用保守は含まれていません。そのため、単一病院や医事会計単体の相場としては使えません(出典:東京都立病院機構、2025年)。

見積書で分けて見る費用項目

見積は、要件定義とプロジェクト管理、ライセンスや利用料を分けて出してもらいます。環境構築や設定・追加開発も、別々に示してもらいます。

インターフェースやデータ移行、テスト、教育も分けます。機器・ネットワーク、稼働立会い、保守、診療報酬改定対応も、別の項目として扱います。特に、「一式」でまとめられると、比較や変更管理が難しくなります。

見積では、端末1台あたり、医療機関1施設あたり、連携1本あたり、移行データ1種類あたりなど、数量と単価の前提も確認します。

月額費用と導入期間の見積もり

月額費用と導入期間は、次の項目を分けて見積もります。

  • 月額に含まれる場合がある費用:利用料、クラウド基盤、VPNや証明書、バックアップ、監視、ヘルプデスク、保守、改定対応、周辺サービス
  • 総保有コスト:5年程度で比較し、更新時の増額条件、解約費、データ返却費も確認
  • 標準クラウド:導入期間は数週間から1〜3か月程度の推定
  • 中小病院:連携・移行を含む導入期間は6〜12か月程度の推定
  • 大病院・複数施設:統合を含む導入期間は1年以上の推定

ORCAの公式案内では、申込からクラウドサービス開始まで3週間程度とされています。ただし、これは一般的な導入作業の目安で、複雑な移行や連携にはそのまま当てはまりません(出典:日本医師会ORCA管理機構、2026年確認)。

ポイント

判断の目安は、金額の大小より、初期費用・月額・連携・移行・保守を同じ範囲にそろえて比べられるかどうかです。前提や除外項目が書かれた見積同士で比べると、判断しやすくなります。

委託先選定と見積比較のポイント

委託先は、知名度や総額だけでなく、次の観点で比べます。医療事務への理解、改定対応、連携・移行の実績、保守体制、契約終了時の出口です。

大手病院向けベンダーと、診療所向けのクラウド・レセコン事業者とでは、得意領域が異なります。

選定では、同じランキングで優劣をつけるより、条件に合う2〜4社程度に、同じRFPと評価表で提案を求めるのが現実的です。

医療分野の実績の確認方法

実績の件数に加えて、導入事例を確かめます。確認したいのは、自院に似た病床規模や診療科、DPC、公費、電子カルテ、拠点数の事例です。

可能であれば、導入責任者や医事課の利用者に、切替時の負担や請求開始までの支援、障害対応、改定時の検証方法を尋ねます。

製品会社と、導入や保守を担う地域パートナーが異なる場合は、問い合わせ窓口やエスカレーションの流れ、担当者が継続して関われるかを確認します。

相見積もりを同じ条件で比べる方法

同じ条件にそろえるため、各社に同じ患者・診療・公費・返戻・移行データのサンプルを渡します。さらに、稼働希望日や端末数、連携対象もそろえます。

見積は、初期費用、月額、保守、税、オプションを項目ごとに分けてもらいます。追加開発、移行、教育、機器も、別々に示してもらいます。標準機能か個別開発か、前提条件と除外項目も明記してもらいます。

価格差が大きいときは、安い提案の抜け漏れと、高い提案の過剰な内容を確かめます。総額のみで比べることは避けます。

価格以外の評価項目

評価表には、業務適合性から改定対応、セキュリティまでを入れます。導入体制や保守、教育、TCO、データ可搬性も、評価の項目に加えます。

医事課が重視する請求精度や例外処理に高い配点を置きます。一方で、価格は一定条件を満たす提案同士で比べます。

デモでは、受付から会計、返戻修正、再請求、未収金確認までを一つのシナリオで操作してもらいます。使いやすさに加え、操作ログと監査性も確認します。

ポイント

委託先は、総額よりも、医療事務への理解や改定対応、保守体制、契約終了時の扱いで判断すると迷いにくくなります。条件に合う2〜4社に同じRFPと評価表で提案を求めると、比べやすくなります。

移行・運用・診療報酬改定への備え

発注がうまくいくかどうかは、稼働後も正確な請求を続けられるかで決まります。そのため、移行や教育、問い合わせ、障害、改定への対応を、契約の前から設計します。

医療機関側も、検証結果を自分たちで判断できる状態にしておきます。また、現場の例外処理と制度変更は、継続的な改善の対象にします。

データ移行と現場教育の進め方

移行の検証項目と職員教育を計画に組み込み、部門ごとの準備を進めます。

  • 移行計画:データ項目、変換ルール、欠損時の扱い、照合方法、実施者、承認者の決定
  • 照合対象:患者数や請求件数に加え、保険・公費、未収金、返戻・査定、診療行為、マスターの照合
  • 教育内容:役割別の演習、エラー対応、請求月の実務、障害時の紙運用を組み込み、集合研修だけに頼らない
  • 部門内の支援:各部門にスーパーユーザーを置き、現場への定着を支える

2026年の共通算定モジュールの確認事項

共通算定モジュールは、レセコンからの要求に基づいて診療報酬点数と患者負担金を計算する統一プログラムです。

  • 運用開始:2026年6月から医科・DPC向けに開始
  • 目的と利用:改定時のプログラム改修を一つにまとめ、負担軽減を目指すが、利用は義務ではない
  • 費用と確認事項:請求支援機能の費用扱いは段階的に整理。接続方式、マスター更新、計算結果の検証責任を確認する
  • 未対応時:改定作業費も確認する(出典:厚生労働省「共通算定モジュールについて」、2026年)

稼働後の保守と改善の契約

保守契約には、問い合わせの受付時間や、重大度別の初動・復旧目標を含めます。そのほか、リモート保守の承認、改定対応、マスター更新も入れておきます。

あわせて、バックアップと復元、障害報告、月次レビューも定めます。追加要望は、法令や請求に必須の変更、業務改善、好みの変更に分類し、優先順位と費用を管理します。

導入後3か月や請求サイクルを一巡した時点で、レビューします。そのとき、手戻りや未収金、返戻、会計時間などの指標で効果を確かめます。

よくある質問(FAQ)

発注前には、費用や開発期間、既存システムとの関係、契約責任について疑問が出がちです。検討の初期に判断しやすいよう、よくある質問を並べます。

医療機関向け医事会計システムはスクラッチ開発すべきですか?

まず標準パッケージやクラウドの適合性を確かめ、標準機能で満たせない事業継続上の要件だけを追加開発する方法が現実的です。

スクラッチ開発は独自業務に合わせやすい一方、改定やマスター更新、保守要員、将来の連携に継続的な負担が生じます。差分費用だけでなく、将来の運用まで比べます。

医事会計システムの見積は何社から取るべきですか?

自院の要件に対応できる2〜4社程度に絞り、同じRFP、サンプルデータ、希望時期で相見積もりを取ります。

社数が多すぎると提案評価の負担が増え、少なすぎると価格や受け持ち範囲を比べにくくなります。標準機能、移行・連携、改定対応、保守から終了時のデータ返却まで、同じ評価表で比べます。

クラウド型なら障害やサイバー攻撃の心配はありませんか?

クラウド型でも、障害やサイバー攻撃のリスクは残ります。そのため、認証や権限、操作ログのほか、バックアップと復元テスト、回線の冗長化、代替端末を確認します。

障害時の連絡と紙運用を決め、医療機関とサービス提供者の役割を契約で分けます。保守の経路やインシデント対応については、厚生労働省の第7.0版ガイドラインとチェックリストを基準に質問します。

まとめ

発注では、製品名や初期価格で決めるのではなく、医事会計の対象範囲や施設規模、標準機能と追加開発の境界を見極めます。電子カルテや部門システムとの連携、データ移行、保守、改定対応、BCPも、要件に含めます。

RFPではMUSTとWANTを分け、見積は初期費用・連携・移行・教育・保守に分けて見ます。加えて、同じ条件の提案を比べます。

発注前に作る資料

現行業務とシステムの一覧、連携図、移行対象のほか、必須要件や希望時期、予算の考え方を、企画書にまとめます。

最初から完璧な仕様書を作る必要はありません。そのかわり、医事課や経理、情報システム、経営層が、同じ前提で話せる状態にしておきます。

委託先を決める基準

委託先の選定では、次の点を判断基準にします。

  • 総保有コスト:最安値ではなく、請求を続けられる業務適合性と、改定・障害・担当者交代に耐える運用体制を含めて判断します
  • 自院の条件:条件をRFPに書き込み、標準化する業務と譲れない差分を見極めます
  • 責任分界:委託先と合意できれば、追加費用と現場の混乱を抑えやすくなります

▼全体ガイドの記事
・医療機関向け医事会計システム開発の完全ガイド

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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