遠隔医療システムの発注は、診療モデルと対象患者を決めるところから始まります。そのうえで要件と責任を整理し、提案と見積を同じ条件で比べると、安全性と効率を両立しやすくなります。
発注形態は、SaaS、個別開発、両者の組み合わせから選びます。
▼全体ガイドの記事
・遠隔医療システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
遠隔医療システムの発注・外注で最初に決めること
遠隔医療システムと一口に言っても、オンライン診療用のサービスだけを指すとは限りません。DtoD、DtoP with N、遠隔モニタリングも含まれるため、発注前に対象を決めておく必要があります。
発注側が対象を決めないまま依頼すると、開発会社に要件を正しく伝えられません。誰がどこで誰に対応し、どの判断に使う情報を扱うのかは、先に整理しておきます。
診療モデルと対象患者の決め方
診療モデルが変われば、必要な画面や機能も変わります。そのため、発注側は用途ごとに基本要件を分けて整理しておきます。
- DtoP：予約、本人確認、同意、問診、通話、決済、処方箋案内の機能が要ります。
- DtoD：高解像度映像、医用画像共有、複数人会議、現地への指示、通信断時の代替連絡の扱い。
- DtoP with N：看護師などが患者のそばで支援する診療を想定した形。
- 遠隔モニタリング：家庭で測ったバイタルを医療者が確認する形。
たとえば、クリニックの再診、へき地と専門医の接続、訪問看護師と主治医の情報共有では、業務も対象者も異なります。
オンラインで扱わない患者や症状、時間帯を決めておかないと、急変時に現場が判断に迷います。そこで、急変時の連絡先と、対面診療や救急搬送へ切り替える担当を明確にしておきます。
RFPには、対象患者と診療科、地域を書いたうえで、対応時間と対面へ切り替える条件も加えます。
導入目的と成果指標の設定
導入目的が通院負担の軽減なのか、専門医不足の補完なのか、医師の移動時間削減なのかで、優先順位は変わります。
目的を一つに絞れない場合は、最初のPoCで検証する成果を三つ程度に限定します。
- 診療状況：予約件数、診療完了率、患者の離脱率
- 安全性：対面切替率、急変時の連絡完了時間
- 業務負担：医師の移動時間、職員の入力工数
成果指標は月次KPIとして追い、測定方法や導入前の基準値、目標値を発注書や計画に書きます。確認担当も決めておくと、数字を誰が見るのか迷わずに済みます。
アプリ登録率だけを見ると、職員の負担や適切な対面切替が評価から抜けてしまいます。職員負担と対面切替も評価に加えると、安全と効率の両立を確かめられます。
遠隔医療システムの発注形態の選び方
標準的な診療を早く始めたいならSaaSが、独自業務や連携を重視するなら個別開発が候補になります。
両方の利点を求める場合は、機能の範囲を分けて組み合わせます。
SaaS・パッケージの契約方法
SaaSには予約、問診、通話の機能が備わり、決済や処方箋案内も含まれます。そのため、短期間で始めやすいのが特徴です。
厚生労働省の令和6年度入院・外来医療等の実態調査では、オンライン診療を行う医療機関の導入初期費用の中央値が27.5万円で、月額維持費は1万円でした（「令和6年度調査結果（速報）」、2025年公表）。
この数字は既成サービスの導入実態に近いため、独自システムの開発費とは切り分けて見る必要があります。
- 機能と連携：機能を追加できる範囲、APIの公開範囲、電子カルテやレセコンとの連携方法
- データ：保管場所と、解約時にどの形式で返却されるか
- 利用条件：病院や複数拠点、複数診療科で使えるかどうか
- 料金：患者の利用料と決済手数料の計算方法
個別開発の外注方法
独自業務や複数システムの連携が、SaaSの標準機能では足りない場合に、個別開発が候補になります。
- 独自業務：院内フローや、自治体への申請・支援業務の組み込み
- データ連携：電子カルテや薬局との接続、複数施設をまたぐ権限管理の設計
- 運用機能：医療者・管理者画面、API、監査ログ、障害時の代替手段
発注者側には、横断チームが必要です。
横断チームには、業務責任者、医療者、情報システムの担当に加えて、法務も入ります。
遠隔手術支援や医療機器接続では、遅延・ジッターと映像品質が結果に影響します。
遠隔手術支援では、緊急停止の仕組みと、その責任者も関わります。
一般的なWeb会社だけでなく、通信、機器、医療現場の専門家を含む体制を選ぶ必要があります。
2025年には、NTTとNTT東日本、弘前大学病院、つがる総合病院などが、IOWN APNで遠隔手術支援を実証しました。
IOWN APNでの実証は、高度な案件で共同体制が要る事例で、商用の価格を示すものではありません。
SaaSと個別開発の組み合わせ方
通話や決済にはSaaSを使い、院内ポータルやカルテ連携は個別開発にする組み合わせがあります。
自治体集計やバイタル分析も、個別開発の対象になります。
標準機能で済む部分は、制度改定やOS更新への対応をサービス側に任せられます。そのため、独自開発は必要な範囲に抑えられます。
SaaS事業者と開発会社にまたがる構成では、障害時にどちらが切り分けるのかが分かりにくくなります。そこで、障害切り分け担当を決め、両社を含む責任分界表を作ります。
- データ管理：患者IDや同意、データの正本の扱い
- 障害と移行：連携停止時の再送、解約時の移行手順
- APIが使えない場合のCSV連携：手作業の担当、二重登録の防止、エラー確認の方法
- 接続条件：連携する項目と頻度、エラー処理、テスト環境
RFPと要件整理の進め方
RFPは、各社が同じ前提で提案するための資料です。背景と業務課題、対象者をまず書き、現行業務や導入時期、予算もそろえます。評価基準と提案範囲も示すと、提案を同じ条件で比べられます。
要件が曖昧なまま相見積もりを取ると、各社の作業範囲が食い違い、金額を比べられなくなります。
現場の業務フローのRFPへの落とし込み
業務を予約前、診療中、診療後、例外対応の四つに分け、それぞれの担当と自動化の範囲を明確にします。
- 予約前：対象患者の確認、本人確認、同意、問診、予約変更
- 診療中：通話、資料共有、再接続、家族や看護師の参加
- 診療後：記録、決済、処方箋・薬局連携、次回予約
- 例外時：通信断、急変、医師の遅刻、処方箋連携エラーの扱い
例外対応も、正常時と同じ細かさで書きます。たとえば、「処方箋を連携する」とだけ書くと、連携先や送信方式が分からないままになります。
送信に失敗したときの通知や再送の権限、患者への案内も決めておきます。具体的には、確定後に薬局へ送り、失敗時は画面表示後に電話へ切り替える、といった形まで具体化します。
連携・セキュリティ・運用要件の明記
医療情報を扱う以上、非機能要件も機能要件と同じ水準で決める必要があります。その際に参考になるのが、厚生労働省の第6.0版ガイドラインです。企画と運用の安全管理のほか、委託やクラウドも扱っています（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」）。
- 保護：通信時と保存時の暗号化、MFA、最小権限
- 記録と復旧：監査ログ、バックアップ、脆弱性への対応
- 端末と事故：紛失時の停止とインシデント報告
電子カルテやレセコン、薬局を連携先として書き出します。さらに、決済や検査機器、ウェアラブル端末も加えます。そのうえで、患者IDや予約、請求などの情報を、いつ連携するかも決めます。
HL7 FHIRやSS-MIX2を使う場合は、規格名を書くだけでなく、対象データと実装範囲も示します。
将来、AI提案や異常値通知を加えるなら、医療者が最終判断するHuman-in-the-Loopを含めます。
AI提案の説明の表示と、誤判定時の扱いも決めておきます。
提案書と見積書の提出条件の統一
複数社への提出条件をそろえておくと、提案書と見積書を同じ基準で比べられます。
- 提案書：発注形態、標準機能と追加開発の境界、体制、工程
- 提案内容：リスク、保守範囲、類似案件、デモの可否
- 見積書：要件定義、UI設計、開発、連携、セキュリティ設計、テストを工程ごとに分けた内訳
- 導入費用：移行、教育、リリース、保守、クラウド、ライセンスの費用を別々の金額で
「一式」と書かれた見積は避け、工数と単価、数量を示してもらいます。
見積の前提や除外作業、変更時の精算方法も確かめます。
発注者が準備するものも、提案条件に書き込みます。具体的には、端末やネットワーク、データが該当します。テスト協力者と医療者のレビュー時間も明記します。
質問の受付期間を決め、その回答は全社に共有します。そうすれば、どの会社も同じ前提で提案を作れます。
遠隔医療システムの契約形態と責任分界の決め方
責任は、開発会社だけでなく、医療機関、SaaS事業者、通信会社、機器メーカーで分けて考えます。
端末や回線、患者の通信環境、医療者の判断、連携先の障害のどれでも、診療が止まる場合があります。そのため、監視や患者への連絡、対面診療への切替を担当する人を、契約と運用手順の両方に書いておきます。
準委任・請負・SaaS利用契約の使い分け
工程がどこまで確かかや、要件がどれだけ固まっているかで、契約方式と変更管理の決め方が変わります。
- 初期の調査・要件定義：要件が未確定なら、時間と専門性に対価を払う準委任が向くことがあります。
- 開発：成果物と完成条件を明確にできる工程なら、請負の検討対象になります。
- 要件変更：連携先や現場検証で変更が出たときの、費用と納期の管理
全工程を請負にすると、変更費用や納期遅延が生じやすくなります。そのため、工程ごとに契約や変更ルールを分ける方法が現実的です。
SaaSでは、利用規約やサービス契約が中心になります。
確認するのは、利用料や従量課金、最低期間、サービスレベルです。
運用面では、計画停止や障害通知、データの返却・削除を確認します。
さらに、再委託先と監査協力も見ておきます。
開発会社とSaaSを別々に契約する場合は、問い合わせ窓口と一次切り分けの責任を決めておく必要があります。
検収・変更管理・データの権利の取り決め
検収の条件は、画面の動作だけでなく業務シナリオで決めます。画面が動いても、業務が回るとは限らないためです。
- 診療完了：予約、同意、問診、診療、決済まで完了できるか
- 医療者操作：記録の確認と必要な連携を、医療者が実行できるか
- 通信障害：切断後の再接続と電話への切替
受入テストには、医療者や事務職員、看護師、患者役に加わってもらいます。
端末や通信環境の違いも、あわせて確かめます。
追加の要望を口頭だけで進めると、後から費用や納期の食い違いが生じやすくなります。そのため、変更の要求と影響、追加費用、納期、テスト範囲を文書に残します。
ソースコードや設計書、テスト仕様書の所有先を確認します。
操作ログと患者データについては、誰が利用権限を持つのかも決めます。
契約が終わったときの返却形式と、他社へ移行できる条件を決めておくと、長期の外注リスクを下げられます。
遠隔医療システムの費用相場とコストの内訳
既成サービスの導入と個別開発では、費用の桁が違います。なお、初期費用の中央値27.5万円と月額維持費の中央値1万円は、既成サービスの参考値です。
独自画面や電子カルテ・機器連携、監査ログ、複数施設での運用を含めると、開発費は要件と品質条件で変わります。
SaaS導入の費用の目安（初期0〜50万円程度）
SaaSは、初期0〜50万円程度、月額0〜5万円程度を目安に考えます。
そこに、決済手数料や配送費が加わります。
これは公開料金や厚生労働省の調査をもとにした導入の目安です。ただし、どのサービスにも当てはまる固定の相場ではありません。
一例として、株式会社MICINのcuron公式サイトには、2026年3月時点で導入医療機関が7,000件以上と掲載されています。
そのサービスは、初期費用と月額利用料が0円からですが、決済手数料は別途です。また、病院は現在アカウント発行の対象外とされています。
ほかに、インテグリティ・ヘルスケアのYaDocなども、料金はプランや診療規模、オプション、サポート内容によって変わります。
- 導入：初期設定、職員研修、患者サポート、データ移行
- 利用：API連携、追加アカウント、通話やSMSの従量課金
- 終了：契約終了時のデータ出力にかかる費用
個別開発の費用レンジと要件別の見方
機能の範囲ごとに概算を並べると、予算の見当をつけやすくなります。ただし、これは全国一律の公的な相場ではなく、予算検討用の推定です。
- 小規模MVP：予約、本人確認、Web問診、通話、簡易管理画面の範囲で、500万〜1,500万円程度
- 実運用版：決済、処方箋、電子カルテ・レセコン連携、権限、監査ログを含む場合、1,500万〜5,000万円程度
- 複数施設：FHIR等のデータ連携、バイタル機器、分析、24時間監視、BCPを含む場合、3,000万〜8,000万円以上
- 高度な遠隔医療：遠隔操作、医療機器連携、高精細映像、低遅延通信、冗長化、現地支援、安全停止を含む場合、5,000万〜1億円以上になることがあります
この概算は、類似要件や業務システムの参考値、既成サービスの料金、医療の安全・連携・運用要件をもとにした推定です。正式な見積ではありません。医療機器の調達費やネットワークの敷設費、認証・評価費用は、別途かかる場合もあります。
保守・クラウド・通信を含むTCOでの比較
3年または5年の総保有コストを比べる場合は、初期費用だけでなく、継続費と移行費も含めます。
- 日常運用：保守、クラウド、監視、脆弱性への対応、OS更新
- 利用環境：窓口、端末の交換、回線、決済手数料、データの保管
- 導入・終了：追加開発、移行、教育、患者案内、契約終了時の移行費
- 継続準備：セキュリティ評価、障害訓練、従量課金の見積もり
個別開発では、初期開発費の年15〜25％程度を、保守運用費の仮置きとして使えます。ただし、これは契約条件を組み立てるための参考レンジです。実際には、監視時間やSLA、改修枠、機器保守を分けて見積もります。
利用患者数が増えたときの料金表も、事前に確かめておきます。特に、少数患者のPoCと全施設の本番運用では、必要な監視やサポートが異なります。
委託先選定と見積比較のポイント
委託先は、知名度や金額だけでなく、診療現場の理解、安全管理、連携経験、運用体制で比べます。
得意分野は会社によって異なり、完成品に強い会社もあれば、地域医療・DtoD連携、医療データ基盤、機器・映像連携に強い会社もあります。そのため、自社の課題と委託先の強みが合うかを確かめます。
医療分野の実績と運用体制の確認
委託先の実績は、どの場面で積んできたかで、得意な範囲が変わります。
- 導入実績：診療モデル、施設数、利用期間
- 証跡：匿名化された画面、障害対応の事例、改善履歴、現場教育の資料
- 担当者：営業だけでなく、責任者や保守担当者
- 支援体制：平日日中と夜間休日の対応、一次受付から復旧までの目標、委託先一覧と責任分界
たとえば、DtoPの予約や通話、DtoDの画像共有、遠隔モニタリングのバイタル連携では、必要な設計が違います。
障害が起きたときは、復旧に加えて、医療者や患者への連絡、記録、報告、再発防止も欠かせません。
同じ条件での見積書の比較
価格を比べるのは、RFPへの適合を確かめた後です。評価表では、要件への適合度や医療・セキュリティの知識、連携方式、導入実績を採点します。さらに、体制や工程、運用費、移行性、提案の明確さも評価します。
機能数の多さだけで選ぶと、使い切れない機能や保守できない独自技術を抱えかねません。そこで、そうした機能や技術がないかも確認します。
価格差が大きいときは、工数の違いだけでなく、どの工程が含まれているかの差も調べます。
- 安い見積：要件定義、セキュリティ設計、受入テスト、移行、研修、リリース後のサポートが含まれるかどうか
- 高い見積：重複機能、過剰なカスタマイズ、不要な端末、固定保守が入っていないか
提案審査でのデモと質問による確認
最終候補には、実際の業務シナリオを使ったデモを依頼します。予約、本人確認、同意、問診の流れを見せてもらいます。さらに、通信断や再接続失敗時の電話切替、決済、処方箋案内の場面も示してもらいます。
管理者が監査ログを確認し、権限を止め、障害の状況を把握できるかも確かめます。
- 変更対応：制度やOS更新の責任者、再委託先を変えるときの通知
- 障害・移行：患者への連絡方法と、他サービスへのデータ移行
- AI利用：医療者がAI提案を拒否・修正した記録の有無
回答を契約書や仕様書、SLA、運用手順に反映できる会社を選ぶと、発注後のトラブルを減らせます。
遠隔医療システムの発注・外注でよくある質問
発注前の準備、形態の選び方、医療情報の扱い、導入後の運用について、よくある疑問を取り上げます。
遠隔医療システムの開発費用はいくらですか？
SaaSなどの既成サービスは、調査上の初期費用の中央値が27.5万円、月額維持費の中央値が1万円です（出典：厚生労働省、2025年公表）。
個別開発は、MVPで500万〜1,500万円程度、実運用版で1,500万〜5,000万円程度が目安です。
高度な複数施設や機器連携の場合は、3,000万〜1億円以上の概算を、要件ごとに考えます。
RFPは自社だけで作成できますか？
自社でも作成できます。ただし、医療現場、情報システム、法務、経営の視点で、業務と非機能要件を確かめる必要があります。
開発会社と要件定義を進める場合は、発注前に準委任契約を結びます。その際、相談内容や成果物、開発契約へ進む条件を決めておきます。
複数社に提案を求めるなら、質問への回答は全社で同じ内容にそろえます。
汎用のビデオ会議ツールで代用できますか？
打ち合わせだけの場合と、記録、本人確認、同意、処方、決済、機器データを扱う場合では、必要な管理が異なります。
汎用ツールでも、医療情報の保存とアクセス制御、ログ、端末管理は評価の対象です。委託先や障害時の連絡も見ておきます。医療機関側の運用がガイドラインや院内規程に合うかを確かめ、業務とデータのリスクを整理したうえで判断します。
委託先は何社に見積依頼すべきですか？
RFPの内容と社内の審査負担を踏まえて、候補は段階的に絞ります。
- 初期依頼：3〜5社程度への情報提供の依頼
- 詳細提案：要件適合度と実績から2〜3社に絞ったうえでの、提案とデモの依頼
- 選択肢：社数に正解はなく、SaaS、個別開発、医療データ連携などの形態で比べます。
- 評価：最安値だけでなく、総費用や体制、安全性、移行性、運用継続性を同じ評価表で採点します。
まとめ
発注前には、DtoP、DtoP with N、DtoD、遠隔モニタリングなどの診療モデルと対象患者を決めておきます。オンラインで扱わないケースや急変時の連絡先、対面診療への切替条件、現場の担当は、業務フローに落とし込みます。
発注形態はSaaS、個別開発、ハイブリッドから選びます。調査上の初期27.5万円、月額1万円は既成サービスの参考値です。
個別開発の推定レンジとは切り分けて説明します。比べるときは、保守やクラウド、通信、決済、機器に加えて、教育や訓練、移行まで含むTCOで見ます。
RFPには、機能と連携、暗号化とMFA、権限とログを含めます。さらに、バックアップや脆弱性、事故報告も盛り込みます。また、SLA、データ返却、再委託先、検収条件まで書きます。
見積は、作業範囲や工数、前提、除外作業、変更時の扱いをそろえて比べます。
医療現場の実績と運用体制は、デモや質問で確かめます。そのうえで、責任分界を契約書や運用手順に反映できる委託先を選びます。
▼全体ガイドの記事
・遠隔医療システム開発の完全ガイド
▼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を創業。