医療機関向け問診システムの発注は、業務課題の整理、RFPの作成と担当範囲の合意、試験導入の順に進めると、現場に合う運用につながります。
発注形態から委託先選定まで、流れに沿って説明します。全体像は医療機関向け問診システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・医療機関向け問診システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
医療機関向け問診システムを発注・外注する全体像
問診システムは、紙の問診票をWebフォームに置き換えるだけでは、手入力や確認作業が残りやすくなります。そこで、患者の回答が受付、診療前の確認、電子カルテや予約システムへの引き継ぎまで届く範囲を対象に考えます。
患者は来院前か受付で回答し、受付・看護師・医師がその内容を確認して、次の担当者へ引き継ぎます。途中で情報が抜けないよう、この流れを発注前に決めておきます。
発注前に決める改善の対象と指標
製品を比べる前に、現場で困っていることを洗い出します。改善の対象が決まらないと、必要な機能を選べないためです。
- 問診記入：初診患者の記入に数十分かかる
- 質問の重複：複数の診療科で同じ内容を聞く
- 転記：看護師が紙の回答を電子カルテへ移す作業
- 記入漏れ：受付での確認に手間がかかる
次に、改善したい指標に優先順位をつけます。何を一番改善するかで、評価の項目と試験の見方が変わります。
- 来院前回答率：来院前に回答する患者を増やす
- 滞在時間：受付から診察までの時間
- 転記時間：回答をカルテへ移すのにかかる時間
- 情報共有：診療科をまたいで情報を共有する
厚生労働省の「これからはじめる 看護DX事例紹介」（2025年3月）では、電子予診の狙いが紹介されています。導入そのものを目的にせず、課題と効果を測る指標を先に決める点は、クリニックと病院に共通します。
医療現場と情報システム部門で組む発注チーム
発注チームには、決裁者に加えて、問診を確認する医師・看護師・受付担当、医療情報部門、事務・法務担当を入れます。院長や事務長だけで決めると現場の運用が抜けやすく、現場だけでは予算や契約、セキュリティの判断が遅れます。
キックオフの時点で、業務フローの責任者を一人決めておきます。そのうえで、週または隔週の会議、課題一覧、意思決定の期限も決めます。
病院では、診療科から出た要望をそのまま機能にすると、範囲が膨らみがちです。このため、共通質問、診療科固有の質問、将来の拡張に分けて扱います。
既製クラウド・個別設定・スクラッチから選ぶ発注形態
形態は、予算だけでなく、問診の独自性や電子カルテ連携によって決まります。院内ネットワークや、自院で設定を変えたい範囲も判断材料になります。そのうえで、譲れない要件と、受け入れられる運用の変更を分けて比べます。
標準的な問診に向く既製クラウド
次のような希望がある診療所では、既製クラウドが候補になります。
- 対象範囲：1〜数診療科の問診を始めたい
- 稼働時期：短期間で稼働させたい
- 運用：サーバーや更新を外部に任せたい
既製クラウドは標準機能を使える分、要件定義や開発の工数を抑えやすい形態です。ただし、標準機能と連携方式が自院の要件に合うかは、導入前に確かめる必要があります。
- 標準機能：来院前URL、質問分岐、未回答確認、権限管理、帳票出力
- 連携方式：API、標準規格、患者IDでの画面連携、CSV・PDF受け渡し
- 連携後の運用：自動で反映するか医療者が登録するか、エラー時の再処理画面
クラウドの個別設定による柔軟性と費用のバランス
標準機能だけでは足りない場合は、クラウドに個別設定や追加開発を組み合わせます。対象になるのは、診療科別の分岐、独自帳票、予約・電子カルテ連携、職種別画面などです。
SaaSの保守性を残したまま、必要な部分だけを調整できるのが利点です。複数診療科のある医療機関では、現実的な選択になりやすい形態です。
標準機能と個別開発の境界は、見積書と設計書に書き分けておきます。更新で設定が壊れた場合の対応費や、自院で変更できる範囲も確認します。依頼時の納期、データの保存地域、バックアップの方式も、あわせて確かめます。
独自業務や深い連携に向くスクラッチ開発
次のような要件があるなら、スクラッチ開発が候補になります。
- 複数施設：共通の問診を使う
- 独自業務：特殊な診療フローがある
- 連携・環境：深い連携、閉域網、自院の認証基盤が必要
機能を自由に決めやすい一方で、次の対応を自院と開発会社で分けて担う必要があります。
- 設計：要件定義、画面設計、分岐ロジック
- システム：連携、監査ログ
- 安全と運用：障害対応、脆弱性対策、教育
スクラッチ開発では、導入範囲を区切って検証します。
- 試作：1診療科・1拠点のMVPを作る
- 効果確認：入力完了率や転記時間を確認する
- 展開：確認後に対象を広げる
要件が固まる前に全機能を作ろうとすると、診療科ごとの例外が増えて、費用と納期が膨らみやすくなります。
RFPと要件整理による発注条件のそろえ方
RFPは、現場の前提と受入基準を書き込む発注依頼書です。同じ条件で提案を求めれば、月額だけの見積もりと連携費を含む見積もりが混在するのを防げます。
たとえば、A社は月額だけ、B社は連携費込み、C社は端末費を別計上にしている、といった差を、RFPの段階で避けられます。
RFPに書く現状の業務フローと対象範囲
RFPに書く施設条件は、各社の提案の前提をそろえるために必要です。
- 施設と患者：施設数、病床数、1日あたりの患者数、診療科、初診・再診・健診
- 入力環境：来院前・院内入力の割合、端末、職種、代理入力
- 既存システム：電子カルテ、予約、受付、レセコンの製品名
- 例外対応：スマホ不可時の代理入力、高齢者・外国人支援、緊急時の紙切替
問診の開始から診察前の確認までを図にして、患者IDを確定する人、回答を確認する人、カルテへの登録項目を決めます。画面コピーで連携する場合も、患者を照合する手順が欠かせません。
受け渡す項目とタイミング、エラーが起きたときの担当者を指定しておきます。「連携したい」とだけ書くと、各社が見積もる連携の範囲がばらつきます。
機能要件と非機能要件の分け方
必要な機能は、問診の作成から連携まで漏れがないように整理します。
- 問診票：診療科・症状別の質問、回答分岐、版管理
- 患者入力：来院前URL、予約情報との紐付け、漏れ検知
- 医療者利用：職種別権限、PDF・CSV出力、電子カルテ連携
- AI問診：追加質問、原文確認・修正、生成履歴、診療判断を委ねない運用
非機能要件には、可用性、応答時間、同時アクセス数といった性能の条件を含めます。保護の条件では、バックアップと復旧目標を決めます。さらに、監査ログ、暗号化、アクセス制御も含めます。
脆弱性診断、保守時間、障害通知の方法も決めます。保存場所や、解約時の返却・削除も、あわせて決めておきます。障害や誤登録が起きても業務を安全に続けられるよう、設計の段階で備えます。
受入条件の数値と操作シナリオ
受入試験では、現場で起きる例外も含めて、合格の状態を先に合意しておきます。
- 入力例外：未回答、途中離脱、同じ患者の複数予約、代理入力
- 連携障害：通信断、電子カルテ連携エラー、再処理
- 安全性：権限外閲覧の防止、問診票改訂、紙への切替
たとえば、回答が指定した患者IDで表示されることや、連携エラーを受付担当者が再処理できることを、合格条件にします。さらに、紙に切り替えたときも診察前の確認が止まらないことを、受入条件に含めます。
導入前の数値を測ったうえで、目標を決めます。来院前入力率や完了率に加えて、診療開始までの時間と看護師の確認時間も指標にします。
カルテ転記時間、問い合わせ件数、問診票の変更日数は、診療科別に比べます。効果が曖昧なままでは、改善への投資や契約の更新を判断できないためです。
発注前の契約形態と責任分界
問診システムの発注では、開発のほかに、クラウド利用や保守が関係します。個人情報、電子カルテ連携、端末やネットワークの調達も、あわせてかかわります。作業範囲と期待する結果がずれると、追加費用がかかったり、責任の所在があいまいになったりします。
工程ごとの準委任・請負・SaaS利用
工程ごとに契約形態を分けると、役割と成果物がはっきりします。
- 準委任：要件整理など、相談しながら成果を作る工程で使われることがある
- 請負：画面・連携機能・試験項目を合意し、納品・検収する開発の候補
- SaaS利用：利用規約やサービス契約に基づく月額・年額の継続利用が一般的
要件定義を準委任、開発を請負、稼働後を保守やSaaS利用に分ける構成もあります。契約では、仕様変更、納期遅延、瑕疵対応の扱いを確認します。検収、再委託、知的財産権も押さえます。
データの返却や解約時の移行支援も、契約に含めます。医療機関側の担当者と端末、ネットワークは、役割分担表に書きます。電子カルテ側の作業も、同じ表に入れておきます。
個人情報の委託先管理とデータの扱い
問診には、病歴や診療情報が含まれる可能性があります。服薬やアレルギー、健診結果も含まれることがあります。
個人情報保護委員会の医療・介護関係事業者向けガイダンスでは、病歴や診療・調剤情報などが要配慮個人情報に該当し得るとされています。
契約では、次の項目をあらかじめ決めておきます。
- 委託先管理：安全管理と事故報告、アクセス権限とログ、再委託先、保存期間と削除方法
- データ利用：管理主体と利用目的、AI学習と品質改善、第三者提供、保存地域
- 保管・閲覧：バックアップの保管場所と、サポート担当者の閲覧範囲
- 患者への説明：院内ポリシーとサービス案内を照合し、説明と同意の方法を決める
- 契約終了時：CSV・PDFでの返却が可能か、削除証跡を受け取れるか
最新版の安全管理ガイドラインとBCP
厚生労働省は2026年6月に、「医療情報システムの安全管理に関するガイドライン」第7.0版を公開しました。医療機関・薬局向けのサイバーセキュリティ対策チェックリストも、あわせて公開しています。
記事の公開後にも版が更新される可能性があるため、稟議や契約の時点で最新版を照合します。
- 担当の分担：バックアップ、パッチ適用、脆弱性対応、監視、事故報告
- 障害時の準備：紙問診、院内端末の代替回線、復旧後の登録、患者ID照合
- 復旧手順：記録担当、カルテ反映の時期、通常運用へ戻す時点
紙に切り替えたあと、復旧後の登録で二重入力や未登録が起きやすくなります。そのため、切り替えから復旧までの手順も訓練します。
発注から稼働までの進め方
現場の合意から段階的な展開までを工程に分けると、全院展開のリスクを抑えられます。工程には要件定義、試験導入、効果確認を含め、患者案内と職員研修も組み込みます。
企画と委託先選定の前提づくり
企画では、現行の業務を実際に観察したうえで、RFPの前提をそろえます。
- 問診票：種類、重複質問
- 業務フロー：患者の入力場所、転記先
- 運用条件：1日の件数、例外対応
導入事例は、自院に近い条件かどうかと、実績の中身を確かめます。
- 比較条件：同じ診療科、電子カルテ、同程度の規模
- 事例の内容：課題、導入範囲、期間、支援体制、導入後KPI
- 非公開事例：匿名化した範囲で説明できるか
候補企業には、同じ問診票のサンプルを使って、操作を実演してもらいます。
- 設定：分岐設定
- 画面：患者画面、医療者画面
- 連携：電子カルテへの受け渡し
- 変更：管理者による問診票の変更
実演では、誰が何回操作し、どこで確認するかを見ておくと、導入後の負担を予測できます。
試験導入での患者と職員の評価
試験は、初診が多い1診療科や1拠点から始めます。そのうえで、患者と職員それぞれの操作を確認します。
- 患者側：案内、スマートフォン操作、途中保存、再入力
- 支援ニーズ：外国語、読み上げ、入力補助の必要性
- 職員側：未回答確認、修正、患者ID照合、申し送り
- 例外運用：紙への切替と復旧後の登録
入力完了率だけを見て成功とはしません。看護師の確認時間や医師の再入力が増えれば、業務全体は改善しないからです。
待ち時間、記入漏れ、転記を評価します。情報共有も評価の対象に入れます。厚生労働省の事例を参考に、問診票と運用の両面を見直します。
本稼働の研修・案内・改善窓口
本稼働の前に、患者と職員が使う案内や支援を整えておきます。
- 患者案内：案内文、受付での声かけ
- 院内準備：端末、代理入力ルール、職員向け手順
- 障害対応：連絡先を用意する
- 交代制の病院：動画や手順書、問い合わせ窓口も組み合わせる
導入直後は現場の声を集めて、問診票を修正するかどうかを判断できる体制を保ちます。質問を増やしすぎると、患者の離脱や職員の負担につながります。
ただし、クラウド型を選んでも、院内の運用改善は自動では進みません。
運用に入ってからは、次の指標と状況を振り返ります。
- 問診票：回答率と診療への有用性を見て質問を整理する
- 定期確認：月次または四半期ごとにKPI、障害、問い合わせを振り返る
- 更新・追加開発前：実際の効果を確認する
医療機関向け問診システムの費用相場と見積内訳
費用は、形態と診療科数、患者数で変わります。電子カルテ連携や端末・Wi-Fi、閉域網も、費用を左右します。セキュリティと導入支援も、費用に影響します。
ここで示すのは、公開料金や公的事例、要件の規模から見た検討用の幅です。全施設に当てはまる定価ではありません。
クリニックのクラウド導入、初期0〜30万円・月額0.5〜5万円の目安
小規模クリニックで標準的な問診を導入する場合は、次の価格と追加費用を目安にします。
- 基本料金：初期0〜30万円程度、月額0.5〜5万円程度
- 別費用の場合：端末購入・レンタル、初期設定、連携、研修、追加診療科
- 公開価格例：税抜月額18,700円以上、初期費用290,200円以上
- 見積条件：端末台数、連携、設定変更、サポート費をそろえる
診療科や端末が少なく、標準機能で運用できる場合は下限に近づきます。個別の分岐や連携が増えると、費用は上がります。
価格例は、中部テレコミュニケーションのWeb問診パックです。2026年8月の確認時点の価格で、メルプWEB問診、SIM入りiPad、導入支援などを含みます。要件によって変動するため、市場平均の値ではありません。
病院の初年度費用、500万〜1,200万円程度からの比較
病院の予算は、構成ごとの目安と公的事例を照らし合わせて検討します。
初年度費用は、要件によって上振れすることを前提に予算を組みます。
- 初年度の目安：複数診療科、連携、端末、研修込みで500万〜1,200万円程度
- 拡張時：複数拠点、閉域網、冗長化、分析を含め1,000万〜3,000万円程度
- 事例の施設：国立病院機構甲府病院。270床、サービスライセンスは1年分
- 設定・連携：電子カルテ、施設特化型問診、閉域網クラウド接続・連携
- 事例の概算：端末や設備などの掲載項目を単純合算し、約850万〜1,140万円
甲府病院の事例は、厚生労働省の「これからはじめる 看護DX事例紹介」（2025年3月）に掲載されています。ただし、掲載された項目が他院の見積額を保証するものではありません。
タブレットとWi-Fi工事、通信費は合算して比べます。教育と保守も、同じように合算します。
独自開発の費用の幅と要件による違い
問診専用の統一価格は、ほとんどありません。次に示すのは、要件の規模から見た推定で、既存システムや試験の範囲によっても変わります。
- 1診療科のMVP：300万〜800万円
- 複数診療科：連携、権限、監査ログなどを含み800万〜2,000万円
- 病院グループ・多拠点：閉域網、冗長化、分析・AIを含み2,000万〜5,000万円以上
金額は、要件や既存システムによって動きます。セキュリティや試験範囲によっても差が出ます。そのため、いずれも断定額ではありません。
見積書では、要件定義と画面設計、分岐を分けて書きます。開発と連携、セキュリティレビューとテストも、別々の項目にします。移行と教育、稼働立会い、保守も、項目ごとに分けます。
変更や障害対応が都度課金になっている場合、数年後の総額が高くなることがあります。そこで、初年度だけでなく、3年程度の総保有コストで比べます。問診票の変更費も含めれば、運用後の負担を判断しやすくなります。
委託先選定と見積比較で確認すべきポイント
委託先は、知名度よりも、類似現場での成果、問診票の保守、電子カルテ連携の対応力で選びます。完成品ベンダーや医療IT開発会社、クラウド事業者、業務コンサルは、得意分野がそれぞれ異なります。
複数社で役割を分けるか、一社に責任をまとめるかも検討します。どちらの場合でも、契約後の運用責任を選定の時点で明確にしておきます。
同じ診療科・電子カルテの導入実績
「導入実績あり」という答えで済ませず、自院に近い条件と実績の中身を質問します。
- 施設条件：診療科、電子カルテ、患者数、ネットワーク
- 導入内容：期間、利用者研修、連携方式、導入後KPI
クリニック向けのSaaSと、270床級の病院で閉域網や端末、連携を構築する場合とでは、必要な能力が異なります。
AI問診では、AIが整理する範囲と医療者が確認する範囲を、デモで見ておきます。
Ubieの公式説明では、回答に応じた質問分岐やカルテ下書きが示されています。加えて、電子カルテ連携とクラウド運用も挙げられています。
導入開始までの期間は、規模やネットワークによって違いますが、申込みから1〜2か月が目安です。ただし、これは一社の例にすぎないため、自院の連携方式や審査期間を含めた日程は、別途確認します。
初期費用・月額・追加費用を分けた見積比較
費用項目をそろえておくと、見積の抜けや条件の違いに気づきやすくなります。
- 導入：初期費、問診票設定、データ移行、研修、稼働立会い
- 継続：月額・年額、保守、通信、セキュリティ診断
- 連携・設備：電子カルテ、予約、端末、Wi-Fi、ネットワーク工事
- 課金条件：税込・税抜、最低期間、端末期間、人数単位
問診票や診療科の追加・変更、帳票や連携先の追加・変更にかかる費用を確認します。データの抽出、現地対応、解約時の返却費も、あわせて確かめます。
「別途協議」や「発注者対応」と書かれた項目は、追加費用や院内の工数につながる可能性があります。
比較表には、金額に加えて、未確定の事項と前提を書き込みます。除外項目と担当者も記録します。
税込か税抜か、課金の単位もそろえて読みます。
サポート体制と乗り換えやすさ
稼働後のサポートと契約終了時の扱いは、次の項目で確認します。
- 問診票の変更：自院で変更できる範囲、依頼時の納期と費用
- 問い合わせ・障害対応：受付時間、一次切り分け、復旧目標
- 病院の時間外対応：夜間・休日の連絡手段、紙運用の支援
- データ取出し：問診票の構造、画像・添付ファイルを取り出せるか
- 退出条件：移行支援、契約期間、更新、解約予告、削除証明、再委託先の変更通知を価格表で比べ、契約時に決める
医療機関向け問診システムの発注でよくある質問
相場や導入期間は、施設の条件によって変わります。ここに挙げる数字は、公開情報や事例から見た目安です。自院の要件で見積もりを取ってください。
医療機関向け問診システムはいつ発注・外注すべきですか？
紙問診の転記や記入漏れが続いて、受付・看護師・医師の業務を圧迫しているなら、まず現状の数値を測り、発注の準備を始めます。
全院展開を急がず、1診療科・1拠点で試して、入力率や待ち時間を確認します。
クリニックでもスクラッチ開発を発注できますか？
発注は可能ですが、標準的な問診であれば、既製クラウドや個別設定のほうが費用・期間・保守の負担を抑えやすくなります。特殊な診療フローや独自連携、複数施設への拡張が必要な場合は、MVPから検討します。
AI問診を外注すると診断も自動化できますか？
AI問診は、回答に応じた質問やカルテ下書きなど、情報の整理を支援するものです。診断や治療方針を自動で決めるものではありません。
AI出力を確認する人、誤りの直し方、原回答と生成結果の保存を、運用に含めておきます。
学習利用やログ、モデル更新について、委託先に確認します。障害時の代替と責任分界も、あわせて確かめます。
導入費用と期間はどのくらいで稟議に出せばよいですか？
稟議では、施設の構成に応じて費用と導入期間を見積もっておきます。
- クリニックの標準クラウド：初期0〜30万円程度、月額0.5〜5万円程度
- 公開料金例：初期29万200円以上、月額1万8,700円以上
- 病院の初年度：連携や端末、研修を含め500万〜1,200万円程度
- 導入期間：クリニックは2週間〜2か月、病院全体は3〜6か月程度
- 稟議に含める条件：複数拠点、閉域網、稟議・調達・連携試験・研修の期間
まとめ
発注では、製品の機能や初期費用だけでなく、患者の入力から診療前の確認、電子カルテ連携まで、一連の業務として見ます。障害時の運用や導入後の改善も含めて判断します。標準的な業務には既製クラウド、独自の要件には個別設定や開発を選びます。
発注前のRFP・契約・受入条件
現状の転記時間や入力漏れを測って、RFPに記します。RFPには、診療科や端末、電子カルテの条件を書きます。ネットワークとセキュリティの条件も盛り込みます。
見積と契約では、費用と責任分界、個人情報の扱いを明確にします。
受入試験には、通信断、患者ID照合、未回答を含めます。紙への切り替えも、受入試験に入れます。通常とは異なる状況でも業務が続くかを、あわせて確認します。
1診療科・1拠点から始める段階的な展開
最初に業務フローと改善指標を一覧にし、医療現場や情報システム、事務・契約、経営層が同じRFPで相見積もりを取ります。その後、1診療科・1拠点で試し、入力率や転記時間、待ち時間を確かめます。職員の負担も、あわせて見ます。
結果を問診票と運用に反映すれば、過剰な開発や手戻りを抑えながら、全院展開を判断できます。
▼全体ガイドの記事
・医療機関向け問診システム開発の完全ガイド
▼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を創業。