オンライン診療システムの発注は、業務を整理し、発注形態を選び、同じ条件で提案を比べてから、契約と受入テストへ進めると、安全な運用につながります。
発注形態から契約、要件、費用、委託先の選び方まで、発注側の担当者の目線で順に見ていきます。
▼全体ガイドの記事
・オンライン診療システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
オンライン診療システムの発注で最初に決める事項
機能一覧を作る前に、発注側が対象の患者と診療内容を決めます。
発注側は、誰が何分短縮したいのかも、あわせて明確にします。
目的が曖昧なまま相談すると、各社の見積書を比べられません。
患者向けサービスと医療機関の業務システムでは、契約や連携、責任分界が異なるため、どちらを対象にするかも早い段階で定めておく必要があります。
発注前に決める事業目的と対象業務の一文
事業目的は、対象の患者や診療と、関係者ごとの業務に分けて書きます。
整理するときは、次の5つの観点を使います。
- 対象の例：通院が難しい慢性疾患患者の再診を、1院の2診療科でオンライン化
- 複数拠点の例：予約、問診、診療記録、決済を一つの患者導線につなぐ
- 患者と診療：再診中心か初診を含むかで、本人確認や同意取得の優先度が変わる
- 利用者：医師、看護師、事務スタッフの利用範囲に応じ、診療計画や対面移行機能を決める
- 前後の業務：患者・医療者・薬局・配送事業者ごとに、診療前後の作業を洗い出す
診療後の処方箋送付、患者の支払い、未受診や通信断時の連絡方法も、あわせて確認します。先に決めておけば、後から業務を足して費用が膨らむのを抑えられます。
ビデオ通話だけに頼らない要件
患者側の業務は、予約から処方や配送状況の確認までを一続きでつなぐ必要があります。整理する範囲は、次の3つです。
- 診療前：本人確認、保険資格確認、問診、同意、待合室
- 診療後：通知、決済、領収書、処方箋、薬の配送状況の確認
- 医療者側：予約枠や患者一覧から、診療記録、処方、請求、権限管理、監査ログまで
通話のデモが滑らかでも、別画面への二重入力が残れば、患者の取り違えにつながります。
電子カルテやレセコンに「連携可能」と書かれていても、どこまで連携するのかは分かりません。そのため、API自動連携、CSVの入出力、画面参照のどれで連携するのかを確かめます。
データ項目や連携時期、エラー時の再送、手入力の残る項目も、提案書に書いてもらいます。
SaaS・カスタマイズ・スクラッチの発注形態
発注形態は、初期費用だけでなく、業務を標準化できる範囲を見て選びます。
独自の患者体験やデータ連携の必要性も、判断材料になります。
標準サービスで検証してから差分だけを開発すれば、不要な機能への投資を抑えやすくなります。
短期導入に向く医療向けSaaS
導入規模と運用条件に照らし、次の5点を確認します。
- 導入対象：1院・少数診療科で始めるなら、予約・問診・診察・決済を備えたSaaS
- 運用開始：提供会社がインフラ更新と基本的なセキュリティ対応を担い、短期導入がしやすい
- 拡張：利用実績を見ながら、対象診療科を広げられる
- 契約・連携：データ返却と出力形式、外部連携、サポート時間、障害時の連絡手段
- 業務適合：電子カルテ自動連携や、独自問診・請求ロジックの変更可否
独自の問診や請求ロジックを変えられない場合は、価格の安さだけで決めないようにします。
既存連携や独自画面が必要な場合のクラウド拡張
標準機能を活かしながら個別連携や画面を足す場合は、境界と方式を決めます。整理は、次の3点で行います。
- 追加候補：電子カルテ連携、独自患者ポータル、薬局・配送とのAPI連携
- 機能の境界：標準機能と個別機能を分け、更新への影響範囲を契約書・設計書に残す
- 画面方式：追加画面の独立、標準画面の改修、APIによる疎結合を比較する
標準機能を変えると、将来の更新で使えなくなる可能性があります。そのため、要件を分けて整理できる会社なら、機能追加やベンダー変更の影響を限定できます。
独自サービスを事業の核にするスクラッチ開発
独自性を事業の核にするなら、開発範囲と長期運用の両方を確認します。
- 適するケース：多院展開、独自の診療体験、地域連携、蓄積データを使うサービス
- 患者・医療者機能：Web・アプリ、医療者画面、認証・権限、ビデオ通信
- 基盤機能：データベース、決済・通知API、監査ログ
- 運用責任：障害対応、バックアップ、脆弱性管理、監視、データ移行、再委託先管理
保守運用と制度変更への対応は、発注者が長期にわたって担います。開発会社に任せきりにせず、医療機関側も運用責任を果たす体制が必要です。
オンライン診療システムの発注・外注の進め方
見積を受け取った時点は、まだ発注の途中です。発注は、現場業務の整理と方式比較から始めます。次に、RFP配布と提案評価を行い、契約へ進みます。その後、設計、受入テスト、運用開始の順に進みます。各段階で発注者が判断する場面はあらかじめ区切っておき、その中身を段階ごとに説明します。
現状業務と制約の洗い出し
発注側は、最初の1〜2週間で業務を観察し、運用と制度上の制約を整理します。
- 現状把握：予約から請求・処方までの流れを見て、電子カルテ、レセコン、予約台帳、決済、薬局、配送の関係を図にまとめる
- 手作業の確認：ヒアリングに加え、1件の診療で画面を行き来する回数を調べる
- 診療条件：初診か再診か、処方箋の送付先、本人確認の担当者を決める
- 例外・制度：対面診療への切替条件を決め、不明な制度事項は医療側責任者や専門家に確認
業務を実際に観察すると、仕様書には書かれにくい手作業が見つかります。また、制度の解釈は開発会社に委ねず、医療側の責任者や専門家と確かめます。
RFPによる同条件の提案依頼
各社の提案条件をそろえるため、RFPには次の情報を書きます。
- 背景・対象：目的、対象拠点・診療科、想定患者数、診療フロー
- 要件：必須・将来機能、既存システム、連携データ、セキュリティ
- 提案条件：スケジュール、予算の考え方、提出形式、共通質問への回答
- 連携範囲：「電子カルテ連携」を、患者情報、予約、問診、診療記録のどこまで自動化するかに分けて書く
- 費用内訳：構築、追加開発、連携、移行、テスト、教育、保守、従量課金、決済、障害対応
提案の前提条件が違えば、見積の安さが実際の安さとは限りません。
医療者参加の受入テストによる本番運用の判断
受入テストでは、医療者と現場スタッフが参加し、診療の始まりから例外処理までを確かめます。
- 患者・予約：患者登録、本人確認失敗、予約変更、問診未回答、診察開始
- 障害・決済：通信断、患者取り違え防止、決済失敗、返金
- 診療後：処方箋の薬局連絡、対面診療への切替、監査ログ
- 利用者：医師、看護師、受付、会計担当が操作し、処理時間や案内の分かりやすさを記録
画質や音声の確認だけでなく、実際のシナリオを試し、例外処理の手間も記録しておきます。スタッフが参加しない場合は、運用を始めてから入力項目や権限の不足が見つかります。また、合格条件、修正期限、再テストの手順を、契約またはプロジェクト計画に含めます。
開発範囲と責任分界で選ぶ契約形態
オンライン診療では、仕様の不確実さに加えて、個人情報、診療の継続、障害対応の責任が関わります。そのため、契約は準委任か請負かという名称だけで決めず、成果物、納期、確認者、障害・制度変更への対応を、契約書と別紙で明確にします。
要件が固まっている部分の請負契約
成果物と完成条件を明確にできる範囲は、請負契約で発注できます。
- 確定する範囲：画面、機能、連携、性能、テスト条件
- 契約条件：納品物、検収、契約不適合時の修正、納期変更、知的財産権
- 納品資料：セキュリティ設計、運用、バックアップ、復旧の各手順書
制度の解釈や現場の要望が変わる段階で、未確定の範囲まで固定価格・固定納期にすると、変更のたびに追加契約が生じやすくなります。そのため、要件定義を別工程として契約し、その成果をもとに開発契約へ進む方法が現実的です。
要件整理や継続改善に向く準委任契約
作業内容を協議しながら進める場合は、準委任契約が適することがあります。
- 対象業務：現状整理、アーキテクチャ検討、試作、アジャイル開発、運用改善
- 進め方：専門家、期間、会議体、報告物、優先順位、成果評価を明記
- 責任分界：SaaS利用と導入支援を分け、サービス・設定・連携・通信・決済の障害責任を区分
- 障害対応：問い合わせ窓口と復旧目標を決める
2026年4月改訂の厚生労働省「オンライン診療の適切な実施に関する指針」は、事業者と医療機関の責任分界を示しています。
作業時間が積み上がっていても課題が残ることがあるため、進捗の見方を決めておきます。
契約書に入れるデータ・セキュリティ・終了条件
患者データの扱い、終了時の処理、具体的な安全対策を、契約に定めます。
- データ管理：所有権、利用目的、再委託先、海外クラウド、アクセス権限
- 保護と事故：ログ保存期間、バックアップ、事故報告期限、脆弱性対応、返却形式
- 終了時：削除証跡を確認し、バックアップやテスト環境のデータも対象にする
- 通信暗号化：厚生労働省の2026年改訂指針はTLS1.3以上を基本とし、やむを得ずTLS1.2を使う場合は十分な強度を求める
- 実装方式：通信・保存・鍵管理、多要素認証、監査ログの方式を提案書で確認する
RFPと要件整理で漏れを防ぐポイント
RFPは、複数社から同じ条件の提案を受けるための比較基準です。必須要件と希望要件を分けたうえで、業務やデータの要件から、非機能、運用、契約までを書き込みます。
業務シナリオで書く機能要件
機能名だけでなく、患者と医療者の操作を順に追えるシナリオで書きます。
- 予約：患者が診療科・医師・時間を選び、問診と同意を済ませて確定する
- 受付：未回答の問診を確認し、診療前に差し戻す
- 画面要件：利用者、入力項目、エラー処理、通知時期、履歴を定める
- 診療後：診療録、処方箋・薬局連携、キャンセル、未受診、返金、対面移行を定義
- 例外：通信不可や本人確認失敗時に中止するか、別連絡へ切り替えるか決める
医療者側の患者一覧や、診療の開始・終了の操作も、シナリオに含めます。
数字と責任者で定める非機能要件
完成後の検収で判定できるよう、数値と担当を要件に書き込みます。
- 性能・復旧：同時接続数、応答時間、稼働時間、バックアップ頻度、復旧目標時間・時点
- 運用基準：ログ保存期間、端末・ブラウザ、脆弱性診断、障害通知期限
- データ環境：診療情報の保存国・環境と、開発・検証環境での実データ利用
- 権限管理：運用担当者の閲覧範囲を定め、多院では医師・スタッフ・拠点・診療科ごとに分離
- 退職時：退職者のアカウントを停止する手順を定める
「安定稼働」や「十分なセキュリティ」と書かれていても、検収では判断できません。
データ項目と方式まで確定する連携要件
連携するシステム、データ項目、方式と運用責任を、具体的に決めます。
- 連携先：電子カルテ、レセコン、予約、電子処方箋、資格確認、薬局、配送、検査、ウェアラブル、PHR
- データ：患者ID、氏名、生年月日、予約日時、問診、診療記録、処方情報
- 連携条件：送受信方向、頻度、エラー時の扱い、再送方法
- 方式：API、CSV、ファイル連携、画面参照、手入力を比較する
- 責任・費用：仕様変更の検知・改修、試験環境の準備、連携先費用の担当を決める
条件が曖昧なままだと、終盤になって連携できない項目が見つかります。
オンライン診療システムの費用相場と内訳
費用は、SaaS利用料、導入支援費、個別開発費などに分けて考えます。外部サービス費や保守運用費も含めて確認します。
SaaSの公開価格や医療機関の実態調査は、個別開発の見積相場とは別の数字です。そのため、機能と責任範囲をそろえて読み比べます。
SaaS導入の初期費用0〜80万円・月額0〜5万円程度の目安
調査値と公開料金の例は、対象のサービスを区別して読みます。
- 初期費用の調査値：中央値27.5万円、四分位範囲3.65万〜47.5万円
- 月額維持費用の調査値：中央値1万円、四分位範囲5,000円〜2万4,250円
- YaDoc：導入0円、月額3万3,000円（税込）
- YaDoc Quick：導入0円、月額1万1,000円（税込、出典：株式会社インテグリティ・ヘルスケア、医療機関向け料金ページ、2026年確認）
調査値は、オンライン診療を利用する医療機関の値です（出典：厚生労働省「令和6年度入院・外来医療等における実態調査（速報）」、2025年）。既存サービスを使う医療機関に近い実勢値として、初期予算の検討に使えます。ただし、各サービスの対象規模や機能は異なるため、そのまま相場とは断定できません。
SaaSの費用では、決済、SMS、配送、追加連携、サポート、患者向け利用料などの別費用も確認します。
個別開発の要件別の計画推定額
オンライン診療だけを切り出した全国一律の公的統計は確認できません。そのため、ここに示す金額は計画上の推定です。
- MVP（Minimum Viable Product）：予約、問診、診察、決済、最低限の管理画面で1,000万〜3,000万円
- 連携を含む開発：カルテ、レセコン、電子処方箋、薬局、配送、多院管理、監査ログで3,000万〜8,000万円程度
- 大規模基盤：病院グループや医療事業者向けでは8,000万円〜2億円超のケース
計画の幅は、医療連携からセキュリティ審査、移行、運用監視までの要件をもとに算出します。
特定の金額を保証するものではありません。金額は、診療科数や拠点数、同時接続数によって変わります。
アプリの有無や既存仕様、第三者試験、移行データの品質によっても、幅が生じます。見積では、画面数だけでなく、連携本数、データ項目、テストケース、運用設計の工数も確認します。
ランニング費用と予備費の見積もり
初期開発費とは分けて、継続費用と予備費を次の観点で見積もります。
- 利用料：クラウド、ビデオ通信、SMS・メール、決済手数料、配送
- 運用費：監視、ヘルプデスク、脆弱性対応、OS・ライブラリ更新、追加開発
- 従量費：患者数や診療件数に応じた課金がある場合、少ない月と繁忙月を試算する
- 予備費：制度改定、連携先変更、障害調査、データ移行のやり直しに備える
個別開発では、初期費用だけで予算を使い切らないよう注意します。また、保守の対象範囲と、機能追加や夜間・休日対応の追加料金は、開発会社に明記してもらいます。
委託先の選定と見積比較で見るべきポイント
委託先には、医療向けSaaS会社、医療に詳しいSIer、クラウド開発会社、既存システムの保守会社があります。
発注側は、知名度や価格だけでなく、診療フロー、法令・ガイドライン、連携、運用を提案に反映できるかを見ます。
医療ドメインと類似規模の実績の確認
医療分野の実績は、開発経験の有無だけでなく、担当内容と運用まで含めて評価します。
- 実績の範囲：診療科、施設規模、患者数、利用者の役割、連携先、導入後の運用
- 事例資料：公開が難しい場合は、匿名化した業務フロー、担当範囲、障害対応、検収後の保守を確認
- 医療業務理解：本人確認、予約、処方、薬局、対面移行、データ保護を一連で扱えるか見る
- 安全な変更：AWSのMICIN事例を判断材料にする
AWSのMICIN事例では、セキュリティ体制の継続的な改善、アクセス制御、ログ監視が紹介されています。さらに、処方箋FAX送付機能を2日でリリースしたことも紹介されています（出典：AWS「導入事例：株式会社MICIN」、2026年確認）。
短期開発の実績では、変更管理と安全性をどう両立させたかも確認します。
総額ではなく前提・工数・除外項目で比べる見積
共通のRFPを使って、各社の見積の範囲と不足項目を照らし合わせます。
- 見積項目：要件定義、UX、画面、サーバー・DB、ビデオ通信、認証、外部連携
- 工程：テスト、移行、教育、プロジェクト管理、保守に抜けがないかを確認
- 差が出る項目：連携試験、セキュリティ・負荷試験、移行、現場教育、リリース後支援
- 除外条件：「別途」「要相談」「発注者支給」から、作業負担と追加費用を洗い出す
必須要件への対応可否と未対応項目は、一覧にして各社に回答してもらいます。
導入後の支援と乗り換えやすさの評価
導入後は、患者やスタッフからの問い合わせが届くため、支援内容を確かめます。
- 問い合わせ・障害：窓口時間、一次切り分け、優先度、復旧目標、利用状況レポート
- 導入後の支援：操作研修、マニュアル更新、制度変更への対応、改善開発の見積方法
- データ移行：患者・診療データの標準形式出力、画像・監査ログの返却
- 終了条件：API利用条件、契約終了後の削除、移行支援料金
現在の委託先の信頼性にかかわらず、乗り換えの要件を、診療を続けるための事業継続策として定めておきます。
よくある質問
発注でよく寄せられる質問を、予算、開発期間、委託先の選び方の順に取り上げます。
制度やサービス料金は更新されるため、最終契約の前に、公式情報と提案書の最新版を確認します。
オンライン診療システムの発注費用はいくらですか？
既存SaaSの導入は、初期費用0〜80万円程度、月額0〜5万円程度を検討の幅とします。厚生労働省の調査では、オンライン診療を利用する医療機関の初期費用の中央値が27.5万円、月額維持費用の中央値が1万円です。
個別開発は、計画推定で1,000万円から2億円超まで幅があります。そのため、RFPで条件をそろえた見積を取る必要があります。
発注してから利用開始まで何か月かかりますか？
導入期間は方式や連携の規模に応じて、次の幅を計画値とします。
- SaaS標準導入：数週間から2か月
- 標準API連携あり：2〜4か月
- MVP個別開発：4〜8か月
- 複数連携・多院展開の本番基盤：9〜18か月程度
期間は、要件の確定、接続試験、セキュリティ審査、データ移行、医療者テストの進み方で変わります。そこで、提案会社には工程ごとの前提を出してもらいます。
オンライン診療システムの委託先はどう選べばよいですか？
実績や安全性、運用体制は、共通の診療シナリオを使って確認します。
- 経験：医療業務と電子カルテ・レセコン・薬局との連携実績
- 運用条件：セキュリティ、責任分界、障害支援、データ返却の説明
- 担当者：責任者、医療ドメイン、開発・運用担当と面談する
- 提案比較：営業担当だけで決めず、同じ診療シナリオを各社に示す
まとめ
発注では、予約から対面移行までの業務を、本人確認や問診、診療記録、決済、処方、薬局連携を含めて整理します。
早く試したい1院・少数診療科ならSaaS、独自の連携が必要ならクラウド拡張、独自サービスが競争力の核ならスクラッチが候補になります。
発注前に業務と要件を整理し、RFPで同じ条件の提案を依頼します。見積は総額だけでなく、連携や移行、テスト、保守などの工程と、除外項目まで比べます。
契約では、成果物と検収に加え、患者データやセキュリティ、再委託、障害時の責任分界、終了時の返却を確認します。
医療者が受入テストを行い、通信断や決済失敗時にも診療を続けられる運用を整えます。
まず、全機能を最初から抱えず、1診療科・1拠点で始めてKPIを確認します。必要な差分だけを加えていく段階導入は、手戻りを抑えながらオンライン診療を定着させる進め方です。
▼全体ガイドの記事
・オンライン診療システム開発の完全ガイド
▼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を創業。