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

医療機関向け問診システムの発注・外注は、問診票を電子化する製品を選ぶだけでなく、患者の入力から受付、診療前確認、電子カルテ登録までの業務全体を設計して委託先と責任範囲を決めることが重要です。

この記事では、既製クラウド、クラウドへの個別設定、オンプレミス・閉域網、スクラッチ開発の選び方を整理し、RFPに入れる要件、契約形態、費用相場、見積比較、委託先選定、導入後の運用までを発注担当者の視点で解説します。院長や事務長だけでなく、看護部、医療情報部門、情報システム担当が社内で合意形成するときにも使える判断軸をまとめています。

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

医療機関向け問診システムを発注・外注する全体像

医療機関向け問診システムの発注では、「紙の問診票をWebフォームに置き換える」という範囲で考えると、導入後に手入力や確認作業が残りやすくなります。患者が来院前または受付で回答し、受付・看護師・医師が必要な情報を確認し、電子カルテや予約システムへ正確に引き継ぐ一連の流れを、発注するシステムの対象として定義することが出発点です。

最初に整理するのは製品名ではなく、現場の困りごとです。たとえば、初診患者の問診記入に数十分かかる、同じ内容を複数診療科で繰り返し聞いている、看護師が紙の回答を電子カルテへ転記している、記入漏れを受付で確認している、といった事実を洗い出します。そのうえで、来院前回答率を高めたいのか、受付から診察までの滞在時間を短くしたいのか、転記時間を減らしたいのか、診療科をまたいで情報共有したいのかを優先順位付けします。

厚生労働省の「これからはじめる 看護DX事例紹介」（2025年3月）では、電子予診の狙いとして、記入漏れの確認、患者の待ち時間、カルテへの転記、診療科間の情報共有を改善する考え方が紹介されています。システム導入を目的にせず、現状課題と導入後の効果測定指標を先に決めるという点は、クリニックの外注でも病院の調達でも共通です。

発注者側には、決裁者だけでなく、実際に問診を確認する医師・看護師・受付担当、電子カルテやネットワークを管理する医療情報部門、個人情報や契約を確認する事務・法務担当を含めます。院長や事務長だけで仕様を決めると、患者への声かけ、代理入力、問診票の変更、障害時の紙運用などが抜けることがあります。反対に現場だけで決めると、予算、契約、セキュリティ、既存システム連携の判断が後回しになります。

キックオフ時には、業務フローの責任者を一人置き、週または隔週の定例会議、課題一覧、意思決定期限を決めます。病院の場合は診療科ごとに意見が分かれやすいため、全診療科の要望をそのまま機能化するのではなく、共通質問、診療科固有質問、将来拡張に分けて整理することが大切です。

発注形態は既製クラウド・個別設定・スクラッチから選びます

発注形態の選択は、予算だけでなく、問診の独自性、電子カルテ連携の深さ、院内ネットワークの制約、導入後に自院で設定を変更したい範囲で決まります。価格の安さだけでSaaSに寄せたり、最初からスクラッチ開発にしたりせず、業務上譲れない要件と許容できる運用変更を分けて比較します。

診療所で1〜数診療科の問診を始めたい、短期間で稼働したい、サーバーやアップデートの運用を外部に任せたい場合は、既製クラウド型が候補になります。来院前URL、質問の分岐、未回答の確認、権限管理、帳票出力などを標準機能で使えるため、要件定義と開発の工数を抑えやすい形態です。

ただし、「電子カルテ連携可能」という表記だけでは十分ではありません。連携がAPIなのか、標準規格なのか、患者IDを使った画面連携なのか、CSVやPDFを介した受け渡しなのかを確認します。連携後の入力が自動反映されるのか、医療者が確認して登録するのか、エラー時にどの画面で再処理するのかまでが、実運用の使いやすさを左右します。

診療科ごとの質問分岐、独自の帳票、予約システムとの連携、電子カルテへの受け渡し、職種ごとの確認画面など、標準機能だけでは足りない場合は、クラウド基盤に個別設定や追加開発を組み合わせます。SaaSの保守性を活かしつつ、業務に必要な部分だけ調整できるため、複数診療科のある医療機関では現実的な選択になりやすいです。

この形態では、標準機能と個別開発部分の境界を見積書と設計書に明記します。標準機能のアップデートで個別設定が壊れた場合の対応費、問診票を自院で変更できる範囲、ベンダーへ依頼した場合の納期、クラウド上のデータ保存地域やバックアップ方式も確認します。見えない運用費が後から増えないようにすることが重要です。

複数施設で共通の問診を使う、特殊な診療フローがある、既存システムと深く連携する、閉域網や自院の認証基盤を前提にする、といった要件では、スクラッチ開発や個別システムの発注が候補になります。機能を自由に決めやすい反面、要件定義、画面設計、分岐ロジック、連携、監査ログ、障害対応、脆弱性対策、教育までを自院と開発会社で持つ必要があります。

スクラッチを選ぶ場合も、最初から病院全体を完成させるのではなく、1診療科・1拠点のMVPを作り、入力完了率や転記時間を確認してから広げる進め方が安全です。要件が固まる前に全機能を作り込むと、診療科ごとの例外が増えて費用と納期が膨らみやすいためです。

RFPと要件整理で発注条件をそろえます

相見積もりを比較できるRFPは、製品名や機能一覧だけではなく、現場の前提条件と受入基準を記載した発注依頼書です。同じ条件で各社に提案してもらうことで、A社は月額だけ、B社は連携費込み、C社は端末費を別計上という比較しにくい状態を防げます。

RFPには、施設数、病床数や1日あたりの患者数、対象診療科、初診・再診・健診の区分、来院前入力と院内端末入力の割合、対応端末、利用者の職種、現在使っている電子カルテ・予約・受付・レセコンの製品名を記載します。患者が自分のスマートフォンを使えない場合の代理入力、高齢者や外国人への支援、緊急受診時の紙への切り替えも対象業務に含めます。

現状把握では、問診開始から診察前確認までの手順を図にし、どこで患者IDを確定するか、誰が回答を確認するか、どの情報をカルテに登録するかを明らかにします。電子カルテの画面コピーを想定した連携でも、誤った患者への紐付けを防ぐ照合手順を要件に入れます。単に「連携希望」と書くのではなく、受け渡す項目、タイミング、エラー時の担当者を指定することがポイントです。

機能要件には、診療科・症状別の問診票、回答による分岐、入力漏れの検知、来院前URL、予約情報との紐付け、受付・看護師・医師ごとの権限、PDF・CSV出力、電子カルテ連携、問診票の版管理を含めます。AI問診を使う場合は、回答からの追加質問やカルテ下書きの生成だけでなく、医療者が原文を確認して修正できる画面、生成内容の履歴、診断や治療判断をAIに委ねない運用を明記します。

非機能要件には、可用性、応答時間、同時アクセス数、バックアップ、復旧目標、監査ログ、暗号化、アクセス制御、脆弱性診断、保守時間、障害通知、データの保存場所、解約時の返却・削除を記載します。医療情報システムでは、機能が多いことよりも、障害や誤登録が起きたときに安全に業務を継続できることが大切です。

受入試験では、通常の患者だけでなく、未回答、途中離脱、同じ患者の複数予約、代理入力、通信断、電子カルテ連携エラー、権限のない職員による閲覧、問診票の改訂をシナリオ化します。たとえば「入力完了した患者の回答が、指定した患者IDで医療者画面に表示される」「連携に失敗した場合は受付担当者が再処理できる」「紙に切り替えても診察前確認が止まらない」といった状態を合格条件にします。

効果測定の指標は、導入前の数値を測ってから設定します。来院前入力率、入力完了率、受付から診療開始までの時間、看護師の確認時間、カルテ転記時間、患者からの問い合わせ件数、問診票の変更に要する日数などを、診療科別に比較できるようにします。効果が曖昧なままでは、導入後の改善投資や契約更新の判断ができません。

契約形態と責任分界を発注前に決めます

医療機関向け問診システムでは、開発の契約だけでなく、クラウド利用、保守、個人情報の取扱い、電子カルテ連携、端末・ネットワークの調達が関係します。契約書に書かれた作業範囲と、実際に医療機関が期待する結果がずれていると、追加費用や責任の押し付け合いが起こりやすいため、契約形態を工程ごとに使い分けます。

要件整理や伴走支援のように、発注者と委託先が相談しながら成果を作る工程は、稼働時間や役割を定める準委任契約が使われることがあります。完成する画面や連携機能、試験項目を成果物として合意し、納品・検収を行う開発工程は、請負契約が候補になります。既製クラウドは、利用規約やサービス契約に基づく月額・年額の継続利用が一般的です。

実際には、要件定義を準委任、開発を請負、稼働後を保守・SaaS利用に分ける構成もあります。契約名称だけで判断せず、仕様変更の扱い、納期遅延、瑕疵対応、検収条件、再委託、知的財産権、データ返却、解約時の移行支援を確認します。医療機関側が用意する担当者、端末、ネットワーク、電子カルテ側の作業も役割分担表に書きます。

問診の回答には、病歴、診療情報、服薬、アレルギー、健康診断結果などが含まれる可能性があります。個人情報保護委員会の医療・介護関係事業者向けガイダンスでは、病歴や診療・調剤情報などは要配慮個人情報に該当し得ると整理されています。そのため、サービス提供会社を単なるIT業者として扱わず、委託先としての安全管理、アクセス権限、ログ、再委託先、事故時の報告、保存期間、削除方法を確認します。

契約前には、データの管理主体、利用目的、AI学習や品質改善への利用有無、第三者提供の有無、保存地域、バックアップの所在、サポート担当者の閲覧範囲を確認します。患者への説明・同意の方法も、医療機関のプライバシーポリシーとサービス側の案内を突き合わせます。契約終了後にCSVやPDFで全データを返却できるか、返却後にサービス側のデータを削除した証跡を受け取れるかも重要です。

厚生労働省は2026年6月に「医療情報システムの安全管理に関するガイドライン」第7.0版と、医療機関・薬局向けのサイバーセキュリティ対策チェックリストを公開しています。発注時は、委託先に準拠を宣言してもらうだけでなく、自院と事業者のどちらがバックアップ、パッチ適用、脆弱性対応、監視、インシデント報告を担うのかを確認します。記事公開後に版が更新される可能性もあるため、稟議や契約時点の最新版を照合します。

サイバー攻撃やクラウド障害で問診システムが使えない場合は、紙問診、院内端末の代替回線、後からのデータ登録、患者ID照合の方法を決めておきます。障害時に紙へ切り替えるだけでは、復旧後の二重入力や未登録が発生するため、誰が何を記録し、いつ電子カルテへ反映し、どの時点で通常運用へ戻すかまで訓練します。

発注から稼働までの進め方を段階化します

医療機関向け問診システムは、契約してから短期間で全院展開するより、現場の合意形成、要件定義、試験導入、効果確認、段階展開を分けた方がリスクを抑えられます。小規模クリニックでも、問診票を作って終わりにせず、患者への案内と職員研修を工程に含めます。

企画段階では、現行業務を観察し、問診票の種類、質問の重複、患者の入力場所、転記先、1日の件数、例外対応を整理します。RFPを配布したら、提案書だけで決めず、同じ診療科・同じ電子カルテ・同程度の規模での導入事例を確認します。事例が公開できない場合は、匿名化した範囲でも、課題、導入範囲、期間、支援体制、導入後のKPIを説明できるかを尋ねます。

候補を絞る前に、問診票のサンプルを渡して、分岐の設定、患者画面、医療者画面、電子カルテへの受け渡し、管理者による変更を実演してもらいます。営業資料の機能一覧よりも、実際の操作で「誰が、何回クリックし、どこで確認するか」を見る方が、導入後の負担を予測しやすいです。

試験導入は、初診が多い1診療科や1拠点から始めます。患者側では、案内文を読んで入力を開始できるか、スマートフォンで操作できるか、途中保存や再入力ができるか、外国語や読み上げなどの支援が必要かを確認します。職員側では、未回答の確認、問診内容の修正、患者IDの照合、医師への申し送り、紙運用への切り替えを試します。

試験期間中は、入力完了率だけで成功と判断しません。来院前入力が増えても、看護師が回答を読み直す時間が増えたり、医師がカルテへ再入力したりすれば、業務全体は改善しないためです。厚生労働省の事例のように、患者の待ち時間、記入漏れ、転記、情報共有の複数指標を見て、改善点を問診票と運用の両面から修正します。

本稼働前に、患者向けの案内文、受付での声かけ、院内端末の設置、代理入力のルール、職員向けの操作手順、障害時の連絡先を用意します。交代制勤務の病院では、研修を一度開催するだけでは周知が行き届かないため、短い動画や手順書、問い合わせ窓口を組み合わせます。導入直後は、プロジェクトチームが現場の声を集め、問診票の修正を素早く判断できる体制を保ちます。

クラウド型のサービスを選んだ場合でも、院内の運用改善は自動では進みません。問診票を増やし過ぎると患者の離脱や職員の確認負担につながるため、回答率や診療への有用性を見ながら質問を整理します。月次または四半期ごとにKPIと障害・問い合わせを振り返り、契約更新や追加開発の前に、実際の効果を確認します。

医療機関向け問診システムの費用相場と見積内訳

医療機関向け問診システムの費用は、既製クラウドか独自開発か、診療科数、患者数、電子カルテ連携、端末・Wi-Fi、閉域網、セキュリティ要件、導入支援の範囲で大きく変わります。以下は公開料金と公的事例、医療業務システムの要件規模から整理した検討用のレンジであり、すべての医療機関に適用される定価ではありません。

小規模クリニックが標準的な問診票をクラウドで導入する場合、検討用の予算目安は初期費用0〜30万円程度、月額0.5〜5万円程度です。端末の購入・レンタル、問診票の初期設定、電子カルテ連携、導入研修、追加診療科の設定は別費用になることがあります。診療科や端末数が少なく、標準機能で運用できるほど下限に近づき、個別分岐や連携を増やすほど上がります。

公開価格の例として、中部テレコミュニケーションのWeb問診パックは、2026年8月確認時点で、税抜の月額18,700円以上、初期費用290,200円以上です。メルプWEB問診、SIM入りiPad、導入支援などを含む条件ですが、要件により価格が変動します。これは市場全体の平均ではなく、公開価格を比較するときの一例です。見積依頼では、端末台数、連携費、設定変更費、サポート費を同じ条件で分けて提示してもらいます。

病院で複数診療科、複数端末、電子カルテ連携、ネットワーク整備、研修まで含める場合は、初年度500万〜1,200万円程度を検討の起点にし、要件に応じて上振れする前提で予算化します。複数拠点、閉域網、冗長化、高度なカスタマイズや分析機能まで含めると、1,000万〜3,000万円程度のレンジになる可能性があります。ライセンスだけでなく、端末、通信、Wi-Fi、連携、設定、教育、保守を合算して比較します。

根拠の一つとして、厚生労働省の「これからはじめる 看護DX事例紹介」（2025年3月）に掲載された国立病院機構甲府病院の電子予診事例では、270床の病院について、1年分のサービスライセンス、電子カルテ・施設特化型問診設定、閉域網クラウド接続・連携、タブレット、Wi-Fi工事、通信費などの項目が別々に示されています。掲載項目を単純に組み合わせると約850万〜1,140万円となる構成例ですが、これは当該施設の概算であり、他院の見積を保証する金額ではありません。

問診専用のスクラッチ開発には、公開された統一価格がほとんどありません。医療業務システムの要件規模からの推定では、1診療科のMVPが300万〜800万円、複数診療科で予約・電子カルテ連携、権限、監査ログまで含むと800万〜2,000万円、病院グループや多拠点、閉域網、冗長化、分析・AIまで含むと2,000万〜5,000万円以上が検討レンジになります。いずれも要件、既存システム、セキュリティ、試験範囲で変わるため、特定金額の断定ではありません。

見積書では、要件定義、UX・画面設計、問診分岐、開発、電子カルテ連携、セキュリティレビュー、テスト、データ移行、教育、稼働立会い、保守を分けて確認します。初期開発費が安くても、問診票の変更や障害対応が都度課金になると、数年後の総額が高くなる場合があります。初年度だけでなく、3年程度の総保有コストで比較すると判断しやすいです。

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

委託先は、知名度や導入社数だけでなく、自院と似た現場で成果を出せるか、導入後に誰が問診票を保守するか、電子カルテ連携を実装・調整できるかで選びます。完成品ベンダー、医療ITに強い開発会社、クラウド・ネットワーク事業者、業務整理を支援するコンサルティング会社では、得意な範囲が異なります。必要に応じて複数社の役割を分けるか、責任を一社にまとめるかも検討します。

実績を聞くときは、「医療機関への導入実績があります」という説明で終わらせません。自院と同じ診療科、同じ電子カルテ、同じ患者数、同じネットワーク制約での事例があるか、導入期間、利用者研修、連携方式、導入後のKPIを確認します。クリニック向けのSaaSと、270床級病院の閉域網・端末・電子カルテ連携を含む構築では、必要な能力が異なります。

AI問診を提案された場合は、AIが回答を整理する範囲と、医師・看護師が確認する範囲をデモで見ます。Ubieの公式説明では、患者の回答に応じた質問分岐、カルテ下書き、電子カルテ連携、クラウド運用などが示され、導入開始は医療機関の規模やネットワークによって申込みから1〜2か月が目安とされています。これは一社の例であり、自院の連携方式や審査期間を含めた日程を別途確認する必要があります。

見積比較では、初期導入費、月額または年額、問診票の設計・設定費、電子カルテや予約システムの連携費、端末費、通信費、Wi-Fi・ネットワーク工事、データ移行、研修、稼働立会い、保守、セキュリティ診断を項目別にそろえます。税込・税抜、端末の購入・レンタル期間、最低利用期間、ユーザー数・患者数の課金単位も統一して読みます。

さらに、問診票の追加・変更、診療科の追加、帳票の変更、連携先の追加、データ抽出、障害時の現地対応、解約時のデータ返却にいくらかかるかを確認します。安い見積もりに見えても、重要な作業が「別途協議」や「発注者対応」と書かれている場合は、別の費用と院内工数が発生します。比較表には、金額だけでなく、未確定事項、前提条件、除外項目、担当者を記録します。

問診システムは、稼働後に診療科や質問内容が変わります。自院の管理者が変更できる範囲、ベンダーに依頼する変更の納期と費用、問い合わせの受付時間、障害時の一次切り分け、復旧目標、定期メンテナンスの通知方法を確認します。病院では夜間や休日の診療もあるため、営業時間外の連絡方法と紙運用の支援が実務上の評価項目になります。

ベンダーロックインを避けるには、データを標準的な形式で取り出せるか、問診票の構造や画像・添付ファイルも返却されるか、契約終了後の移行支援があるかを確認します。契約期間、更新、解約予告、データ削除証明、再委託先の変更通知も、価格と同じ比較表に入れます。委託先を信頼することと、退出条件を決めることは両立します。

医療機関向け問診システムの発注でよくある質問

ここでは、医療機関向け問診システムの発注・外注を検討するときに、特に相談の多い疑問へ回答します。相場や導入期間は施設条件で変わるため、回答の数字は公開情報や事例から見た目安として扱い、自院の要件で見積を取り直してください。

紙問診の転記や記入漏れが継続し、受付・看護師・医師の業務時間を圧迫しているなら、現状の数値を測った時点で発注準備を始めます。最初から全院展開を決める必要はなく、1診療科・1拠点で試験導入し、入力率、転記時間、患者の待ち時間を確認してから拡張する方法が適しています。

発注は可能ですが、標準的な問診であれば、既製クラウドやクラウドへの個別設定から比較した方が、費用・期間・保守の負担を抑えやすいです。特殊な診療フロー、独自の予約・会計連携、複数施設への拡張など、既製品では解決できない要件が明確な場合に、MVPからスクラッチ開発を検討します。

AI問診は、患者の回答に応じた質問分岐や、医療者が確認するカルテ下書きなどの情報整理を支援するもので、診断や治療方針の決定を自動化するものではありません。AIの出力を誰が確認し、誤りをどう修正し、原回答と生成結果をどう保存するかを要件と運用に含めます。提案時には、学習利用、ログ、モデル更新、障害時の代替、責任分界を委託先へ確認してください。

クリニックの標準クラウドなら初期0〜30万円程度、月額0.5〜5万円程度を一つの検討目安にし、端末・連携・設定を加えて見積を取ります。公開料金の一例では初期29万200円以上、月額1万8,700円以上のサービスがあります。病院で連携やネットワーク、端末、研修まで含める場合は初年度500万〜1,200万円程度を起点にし、複数拠点や閉域網などの条件を加味します。期間はクリニックの標準導入で2週間〜2か月、病院全体では3〜6か月程度を目安にしますが、稟議、調達、連携試験、研修の期間を別途見込みます。

まとめ

医療機関向け問診システムを発注・外注するときは、製品の機能数や初期費用だけでなく、患者の入力、受付、診療前確認、電子カルテ連携、障害時運用、導入後の改善までを一つの業務として比較することが重要です。標準的な業務には既製クラウド、独自性や深い連携には個別設定・スクラッチというように、要件に合う発注形態を選びます。

発注前には、現状の転記時間や入力漏れを測り、診療科・端末・電子カルテ・ネットワーク・セキュリティの前提をRFPに記載します。見積は初期費用、月額、端末、連携、設定変更、保守、データ返却を分けて比較し、契約では委託先・再委託先・障害時対応・個人情報の扱い・責任分界を明確にします。受入試験には、通常時だけでなく、通信断、患者IDの照合、未回答、紙への切り替えを含めます。

最初の一歩は、候補サービスを決めることではなく、現場の業務フローと改善したい指標を可視化することです。そのうえで、医療現場、情報システム、事務・契約担当、経営層が同じRFPを見て相見積もりを取り、1診療科・1拠点で試します。入力率と転記時間、患者の待ち時間、職員の確認負担を確認しながら問診票と運用を改善すれば、過剰な開発や導入後の手戻りを抑えながら、全院展開の判断につなげられます。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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