遠隔医療システム開発の発注/外注/依頼/委託方法について

遠隔医療システムの発注・外注では、ビデオ通話機能だけでなく、診療モデル、医療情報の安全管理、既存システム連携、障害時の対面診療への切り替えまでを一体で要件化することが成功のポイントです。

遠隔医療システムを導入したい医療機関や自治体が迷いやすいのは、SaaSを契約すべきか、個別開発を依頼すべきか、どのようなRFPを作ればよいか、見積書の金額をどう比較すべきかという点です。本記事では、DtoP（医師と患者）、DtoP with N（看護師などが患者のそばにいる形）、DtoD（医師同士）、遠隔モニタリングなどの違いを踏まえ、発注形態の選択から委託先決定、契約、費用、検収までを実務の順番で解説します。

▼全体ガイドの記事
・遠隔医療システム開発の完全ガイド

遠隔医療システムの発注・外注で最初に決めること

遠隔医療システムは、オンライン診療用のサービスだけを指すとは限りません。医療機関同士をつなぐDtoD、看護師や介護職が患者のそばで支援するDtoP with N、家庭で測定したバイタルを医療者が確認する遠隔モニタリングまで含む広い概念です。発注前に「誰が、どこで、誰に対して、どの判断をするための情報を扱うのか」を決めると、不要な機能を減らし、必要な安全要件を漏らしにくくなります。

クリニックで再診患者の診療をオンライン化するのか、自治体がへき地の住民と専門医をつなぐのか、在宅医療で訪問看護師と主治医が情報を共有するのかによって、発注するシステムの姿は大きく変わります。たとえばDtoP中心なら、予約、本人確認、同意、問診、ビデオ通話、決済、処方箋の案内が基本になります。一方でDtoDでは、高解像度映像、医用画像の共有、複数人会議、現地スタッフへの指示、通信断時の代替連絡が重要です。

また、オンラインで対応しない患者・症状・時間帯を先に決めることも大切です。急変時にどこへ連絡し、誰が対面診療や救急搬送へ切り替えるのかが曖昧なままでは、便利な画面を作っても現場で使い続けられません。RFPには対象患者、診療科、対応地域、対応時間、対面への切替条件を明記してください。

経営層が「遠隔医療を導入したい」と考えていても、目的が通院負担の軽減なのか、専門医不足の補完なのか、医師の移動時間削減なのかで優先順位は異なります。目的を一つに絞れない場合は、最初のPoCで検証する成果を三つ程度に限定します。候補には、オンライン診療の予約件数、診療完了率、患者の離脱率、対面切替率、医師の移動時間、職員の入力工数、急変時の連絡完了時間などがあります。

「使えるシステムを納品する」だけを成果にすると、導入後に利用されないリスクがあります。月次で確認するKPI、測定方法、導入前の基準値、目標値、誰がデータを確認するかまでを発注書やプロジェクト計画に含めます。患者側のアプリ登録率だけでなく、職員の運用負担や対面診療への適切な切り替えも評価対象にすると、医療の安全と業務効率を両立しやすくなります。

遠隔医療システムの発注形態はどれを選ぶべきですか？

結論からいうと、早期導入と標準的な診療フローを重視するならSaaS、既存業務や複数システムとの連携を重視するなら個別開発、両方の利点を取りたいならハイブリッド方式が適しています。最初からスクラッチ開発を前提にせず、標準機能で解決できる範囲と、自院固有の業務として作る範囲を分けて考えることが発注の出発点です。

SaaSは、予約、問診、ビデオ通話、決済、処方箋案内などがあらかじめ用意され、短期間で始めやすい方式です。厚生労働省の令和6年度入院・外来医療等の実態調査では、オンライン診療を利用する医療機関のシステム導入時初期費用の中央値は27.5万円、月額維持費用の中央値は1万円でした（出典: 厚生労働省「令和6年度調査結果（速報）」、2025年公表）。これは既成サービスの導入実態に近い数字であり、独自システムの開発費と混同しないことが重要です。

ただし、SaaSでは機能追加の自由度、データの保管場所、APIの公開範囲、電子カルテやレセコンとの連携方法、解約時のデータ返却形式を事前に確認します。病院で利用できるか、複数拠点や複数診療科に対応できるか、患者から徴収する利用料や決済手数料がどう計算されるかも、月額だけでは判断できないポイントです。

個別開発は、院内の独自フロー、自治体の申請・支援業務、電子カルテや薬局とのデータ連携、複数施設の権限管理など、SaaSの標準機能では足りない要件に向いています。患者向け画面だけを独自に作るのではなく、医療者画面、管理者画面、連携API、監査ログ、障害時の代替手段を含めて設計するため、発注者側にも業務責任者、医療者、情報システム、法務の横断チームが必要です。

遠隔手術支援や医療機器接続のように、遅延・ジッター、映像品質、現地側の緊急停止、責任者の所在が結果に影響する案件では、一般的なWebシステム会社だけでなく、通信、機器、医療現場の専門家を含む体制を選びます。2025年にはNTT、NTT東日本、弘前大学病院、つがる総合病院などがIOWN APNで遠隔手術支援を実証しました。これは商用システムの価格を示すものではありませんが、高度な遠隔医療ではネットワークと医療機器を含む共同体制が必要になることを示す事例です。

実務では、ビデオ通話や決済はSaaSを使い、院内ポータル、電子カルテ連携、自治体向けの集計、バイタルデータの分析だけを個別開発するハイブリッド方式が現実的です。標準機能を使えば制度改定やOS更新への対応をサービス側に任せやすく、個別開発の範囲を必要最小限にできます。発注時は、SaaS事業者と開発会社のどちらが障害を切り分けるかを決め、両社を含めた責任分界表を作成してください。

ハイブリッド方式では、データが複数サービスにまたがるため、患者IDの統合、同意の管理、データの正本、連携停止時の再送、解約時の移行手順を先に決めます。APIが利用できない場合にCSV連携を残すとしても、手作業の担当者、二重登録の防止、エラー時の確認方法を設計します。「連携できる」という営業説明だけでなく、項目一覧、頻度、エラー処理、テスト環境の有無を確認することが大切です。

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

RFPは、開発会社に機能一覧を渡すだけの資料ではありません。背景、解決したい業務課題、対象となる患者・医療者、現行業務、希望する導入時期、予算の考え方、評価基準、提案してほしい範囲を揃え、各社が同じ前提で提案できるようにする資料です。要件が曖昧なまま相見積もりを取ると、安い会社と高い会社で含まれる作業が異なり、金額比較ができなくなります。

まず、予約前、診療中、診療後、例外対応の四つに分けて業務を描きます。予約前には対象患者の確認、本人確認、同意、問診、予約変更があります。診療中にはビデオ通話、資料共有、通信再接続、家族や看護師の参加があります。診療後には記録、決済、処方箋や薬局への連携、次回予約があります。通信断、患者の急変、医師の遅刻、処方箋連携エラーなどの例外も、正常系と同じ粒度で記載します。

RFPには、各工程の担当者と、システムが自動化する範囲を明記します。たとえば「処方箋を連携する」だけでは、連携先、送信方式、送信失敗時の通知、再送の権限、患者への案内が不明です。「処方箋情報を確定後に薬局へ送信し、失敗時は医療者画面にエラーを表示し、電話連絡へ切り替える」まで具体化すると、提案や見積の前提を揃えられます。

医療情報を扱う場合、機能要件と同じレベルで非機能要件を定めます。厚生労働省の「医療情報システムの安全管理に関するガイドライン 第6.0版」では、医療情報システムの企画、運用、外部委託、クラウドサービスなどを含む安全管理が整理されています（出典: 厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」）。RFPには、通信時・保存時の暗号化、MFA、権限の最小化、監査ログ、バックアップ、脆弱性対応、端末紛失時の停止、インシデント報告を含めます。

連携要件では、電子カルテ、レセコン、薬局、決済、検査機器、ウェアラブル端末などを列挙し、患者ID、診療情報、予約情報、請求情報のどれをいつ連携するかを整理します。HL7 FHIRやSS-MIX2などの標準規格に対応できるかを確認する場合も、規格名だけでなく対象データ項目と実装範囲を示してください。将来の機能としてAIによる提案や異常値アラートを入れる場合は、最終判断を医療者が行うHuman-in-the-Loop、説明表示、誤判定時の扱いも要件に含めます。

複数社へRFPを送るときは、提出物の形式を統一します。提案書には、想定する発注形態、標準機能と追加開発の境界、導入体制、工程、リスク、保守範囲、類似案件の経験、デモの可否を求めます。見積書には、要件定義、UI設計、開発、連携、セキュリティ設計、テスト、移行、教育、リリース、保守、クラウド費、ライセンス費を分けて記載してもらいます。

「一式」とだけ書かれた見積は比較しにくいため、工数、単価、数量、前提条件、含まれない作業、変更時の精算方法を確認します。発注者側で準備する端末、ネットワーク、データ、テスト協力者、医療者のレビュー時間も明記してください。RFPの質問受付期間と回答を全社に共有すれば、提案条件の公平性も保ちやすくなります。

遠隔医療システムの契約形態と責任分界はどう決めますか？

契約では、開発会社が作る範囲だけでなく、医療機関、SaaS事業者、通信会社、機器メーカーの責任を分けて記載します。遠隔医療では、システムが稼働していても、端末、回線、患者の通信環境、医療者の判断、連携先の障害が原因で診療を継続できないことがあります。誰が何を監視し、誰が患者へ連絡し、誰が対面診療へ切り替えるかを契約と運用手順の両方に落としてください。

要件が固まっていない初期の調査や要件定義は、作業時間と専門性に対して対価を払う準委任契約が適することがあります。成果物と完成条件を明確にしやすい開発工程は請負契約を検討できますが、連携先の仕様変更や医療現場の検証で要件が変わる場合は、すべてを請負にすると変更費用や納期遅延が発生しやすくなります。工程ごとに契約方式を分ける、または変更管理のルールを契約に入れる方法が現実的です。

SaaSを使う場合は、開発契約ではなく利用規約やサービス契約が中心になります。利用料、従量課金、最低利用期間、サービスレベル、計画停止、障害時の通知、データ返却、契約終了後の削除、再委託先、監査への協力を確認します。個別開発会社とSaaSを別々に契約する場合は、片方の障害をもう片方へ押し付けないよう、問い合わせ窓口と一次切り分けの責任を決めます。

検収条件は「画面が動く」ではなく、業務シナリオで定めます。患者が予約、同意、問診、診療、決済まで完了できるか、医療者が記録を確認して必要な連携を実行できるか、通信を意図的に切断したときに再接続や電話切替が機能するかをテストします。受入テストでは、実際の医療者、事務職員、看護師、患者役の協力者を含め、端末や通信環境の違いも確認してください。

開発中に「この機能も必要」と分かった場合は、口頭合意で進めず、変更要求、影響範囲、追加費用、納期、テスト範囲を記録します。ソースコード、設計書、テスト仕様書、操作ログ、患者データの所有・利用権限も確認し、契約終了時にどの形式で返却できるかを明確にします。医療機関が将来別の事業者へ移行できる条件を確保することは、長期の外注リスクを下げるうえで重要です。

遠隔医療システムの費用相場とコストの内訳

遠隔医療システムの費用は、既成サービスの導入と個別開発で桁が変わります。公開調査で確認できるオンライン診療の初期費用中央値27.5万円、月額維持費用中央値1万円は、既成サービスの導入費用を考える材料です。一方、独自の患者・医療者画面、電子カルテ連携、機器連携、監査ログ、複数施設運用を含む開発は、要件と品質条件によって大きく変動するため、同じ数字で比較できません。

SaaSの入口は、初期費用0〜50万円程度、月額0〜5万円程度に加えて、決済手数料や患者への配送費などが発生する形を目安にします。ただし、これは公開料金や厚労省調査を基にした導入の目安であり、すべてのサービスに当てはまる固定相場ではありません。株式会社MICINのcuronは公式サイトで、2026年3月時点の導入医療機関7,000件以上、初期費用・月額利用料0円からの料金を掲載していますが、決済手数料は別途で、病院は現在アカウント発行の対象外とされています。

インテグリティ・ヘルスケアのYaDocや、ほかのオンライン診療サービスでも、プラン、診療規模、オプション、サポート内容によって料金が変わります。見積比較では、月額の安さだけでなく、初期設定、職員研修、患者サポート、データ移行、API連携、追加アカウント、通話やSMSの従量課金、契約終了時のデータ出力まで合計してください。

個別開発の費用は全国一律の公的相場が公開されているわけではありません。以下は、一般的な個別業務システムの参考値、既成サービスの料金、医療情報のセキュリティ・連携・運用要件を組み合わせた概算レンジです。正式な見積ではなく、RFPの予算検討用として扱ってください。小規模MVPで予約、本人確認、Web問診、ビデオ通話、簡易管理画面までなら500万〜1,500万円程度、医療機関向け実運用版で決済、処方箋、電子カルテ・レセコン連携、権限、監査ログまで含めると1,500万〜5,000万円程度が目安です。

複数施設、FHIRなどのデータ連携、バイタル機器、分析、24時間監視、BCPまで含む場合は3,000万〜8,000万円以上、遠隔操作や医療機器連携、高精細映像、低遅延通信、冗長化、現地支援、安全停止まで含む場合は5,000万〜1億円以上になる可能性があります。これらは類似要件からの推定であり、医療機器の調達費、ネットワーク敷設費、認証や評価費用が別途になる場合もあります。

初期開発費が安くても、保守、クラウド、監視、脆弱性対応、OS更新、サポート窓口、端末交換、通信回線、決済手数料、データ保管が高いと、数年後の負担は大きくなります。個別開発では、初期開発費の年15〜25％程度を保守運用費として仮置きする方法がありますが、これは契約条件を作るための参考レンジであり、実際には監視時間、SLA、改修枠、機器保守を分けて見積もる必要があります。

3年または5年の総保有コストを計算するときは、初期費用に、月額、従量課金、追加開発、データ移行、職員教育、患者向け案内、定期的なセキュリティ評価、障害訓練、契約終了時の移行費を加えます。利用患者数が増えたときの料金テーブルも確認してください。利用件数が少ないPoCと、本番で全施設へ展開した状態では、必要な監視やサポートも変わります。

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

委託先は、知名度や提示額だけでなく、診療現場の理解、医療情報の安全管理、連携経験、導入後の運用体制を比較します。完成品を導入する会社、地域医療やDtoDの連携に強い会社、医療データや大規模基盤に強いSI、機器・映像連携を含む個別開発会社では、得意な案件が異なります。自社の課題と委託先の強みが一致しているかを確認してください。

実績を見るときは、単に「医療案件がある」と聞くのではなく、どの診療モデルで、何施設が、どの期間使い続けているかを確認します。DtoPの予約・通話と、DtoDの医用画像共有、遠隔モニタリングのバイタル連携では必要な設計が異なります。可能であれば、匿名化された画面、障害対応の事例、導入後の改善履歴、現場教育の資料を見せてもらい、営業担当だけでなくプロジェクト責任者や保守担当者とも話します。

運用体制では、平日日中だけのサポートか、夜間・休日の監視があるか、障害の一次受付から復旧までの目標時間はどれくらいかを確認します。再委託先、クラウド事業者、データセンター、通信事業者がいる場合は、委託先の一覧と責任分界を提出してもらいます。医療情報のインシデントでは、技術的な復旧だけでなく、医療者・患者への連絡、記録、報告、再発防止まで必要になるためです。

見積比較では、まずRFPの要件を満たしているかを確認し、その後に価格を比べます。評価表は、要件適合度、医療・セキュリティ知識、連携方式、導入実績、体制、スケジュール、運用費、移行性、提案の明確さに分けます。機能が多い提案が最良とは限らず、現場が使い切れない機能や、保守できない独自技術が含まれていないかも確認します。

価格差が大きいときは、開発工数の差だけでなく、含まれる工程の差を疑います。安い見積に要件定義、セキュリティ設計、受入テスト、データ移行、操作研修、リリース後のサポートが含まれていない場合、後から追加費用になりやすいからです。反対に高い見積では、標準機能と重複する開発、過剰なカスタマイズ、不要な専用端末、長期間の固定保守が含まれていないかを質問します。

最終候補には、実際の業務シナリオでデモを依頼します。患者がスマートフォンから予約し、本人確認と同意を行い、問診を入力し、診療中に通信が途切れ、再接続できなかった場合に電話へ切り替え、診療後に決済と処方箋案内を行う流れを見せてもらいます。管理者が監査ログを確認し、権限を停止し、障害状況を把握できるかも確認します。

質問には「導入後に制度やOSが変わった場合の更新責任は誰にあるか」「データを別サービスへ移行できるか」「障害時に患者へどう連絡するか」「再委託先を変更する場合の通知はあるか」「AIの提案を医療者が拒否・修正した記録を残せるか」などを含めます。回答を営業資料だけでなく、契約書、仕様書、SLA、運用手順に反映できる会社を選ぶことが、発注後のトラブルを減らします。

遠隔医療システムの発注・外注でよくある質問

ここでは、遠隔医療システムを発注するときに多く寄せられる疑問へ回答します。費用だけでなく、発注前の準備、SaaSと個別開発の選択、医療情報の扱い、導入後の運用まで確認してください。

SaaSや既成サービスの導入なら、公開調査では初期費用の中央値27.5万円、月額維持費用の中央値1万円という実態があります（出典: 厚生労働省、2025年公表）。個別開発は、MVPで500万〜1,500万円程度、実運用版で1,500万〜5,000万円程度、高度な複数施設・機器連携では3,000万〜1億円以上のレンジを、要件別の概算として考えます。

自社で作成できますが、医療現場、情報システム、法務、経営の視点を入れて業務フローと非機能要件を確認することが大切です。開発会社へ相談しながら要件定義を行う場合は、発注前の準委任工程として契約し、相談内容や成果物、次の開発契約へ進む条件を明確にします。複数社へ同じ条件で提案を求めるなら、質問への回答を共通化してください。

単なる打ち合わせに使う場合と、診療記録、本人確認、同意、処方、決済、医療機器データを扱う場合では、必要な管理が異なります。汎用ツールを採用する場合も、医療情報の保存、アクセス制御、ログ、端末管理、委託先、障害時の連絡を評価し、医療機関側の運用がガイドラインや院内規程に適合するかを確認します。機能が足りないからすぐ個別開発するのではなく、業務とデータのリスクを整理して判断してください。

RFPの内容と社内の審査負担を考えると、最初に3〜5社程度へ情報提供依頼を行い、要件適合度と実績で2〜3社に絞って詳細提案とデモを依頼する進め方が現実的です。社数に正解があるわけではなく、SaaS、個別開発、医療データ連携など異なる選択肢を含めて比較することが重要です。最安値ではなく、総費用、導入体制、セキュリティ、移行性、運用の継続性を同じ評価表で採点してください。

まとめ

遠隔医療システムを発注・外注するときは、最初にDtoP、DtoP with N、DtoD、遠隔モニタリングなどの診療モデルと対象患者を決めます。そのうえで、オンラインで扱わないケース、急変時の連絡先、対面診療への切替条件、現場の担当者を業務フローに落とし込みます。

発注形態は、標準機能を早く使うSaaS、独自業務と連携を作り込む個別開発、両者を組み合わせるハイブリッドから選びます。厚労省調査の初期費用中央値27.5万円・月額維持費用中央値1万円は既成サービス導入の参考値であり、個別開発の推定レンジとは分けて説明してください。費用は初期開発だけでなく、保守、クラウド、通信、決済、機器、教育、障害訓練、将来の移行まで含むTCOで比較します。

RFPには、機能要件、連携項目、暗号化、MFA、権限、監査ログ、バックアップ、脆弱性対応、インシデント報告、SLA、データ返却、再委託先、検収条件を盛り込みます。見積書は一式の金額だけで判断せず、作業範囲、工数、前提、含まれない作業、変更時の扱いを揃えて比較します。最後に、医療現場の実績と導入後の運用体制をデモと質問で確認し、契約書と運用手順に責任分界点を反映できる委託先を選ぶことが大切です。

▼全体ガイドの記事
・遠隔医療システム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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