医療業界のシステム開発のPoC・プロトタイプ・モックアップ開発について

医療機関向けの総合基幹システムでは、モックアップ・プロトタイプ・PoCが確かめる対象は異なります。画面、現場の操作、技術と規制の順に段階を踏むと、手戻りや予算超過を抑えやすくなります。

期間と費用、医療機関特有の確認点、失敗の型も扱います。全体像は完全ガイドもご覧ください。

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

医療機関向け総合型基幹システムにおけるモックアップ・プロトタイプ・PoCの違い

モックアップ、プロトタイプ、PoCの検証対象を3枚のパネルで示した図解です。
確認する対象が、画面から操作、技術と現場課題へ広がります。

モックアップ・プロトタイプ・PoCは、目的の異なる検証手法です。「とりあえず動くものを作る」という考えのまま違いを理解せずに進めると、確認点を逃して本開発に入り、手戻りが生じるおそれがあります。

モックアップ・プロトタイプ・PoCという3段階の位置づけ

モックアップは、画面デザインやレイアウト、画面遷移を確かめる「見た目」の検証です。なお、実際に動作するシステムではありません。

  • モックアップ:画面イメージの視覚的な合意
  • プロトタイプ:一部の機能だけ動く試作品を、想定ユーザーが操作して確かめる
  • PoC(概念実証):本開発の前に、技術面の実現性と現場課題への効果を実証

たとえば、モックアップでは表示する内容や、どこを押すと次のどの画面へ移るかを、発注側と開発側で具体的に確かめます。

プロトタイプでは、医師・看護師・受付事務スタッフが実際に操作し、多忙な現場の業務を妨げない導線かどうかを確かめます。

一方でPoCは、特定の技術課題を解決できるか、現場課題を解決して投資対効果を生むかを検証する段階です。たとえば、既存の電子カルテやレセコンとの連携や、診療報酬計算に耐える精度を、実データに近い環境で実証します。

総合基幹システムでPoCまで踏み込む理由

電子カルテや予約システムの単体であれば、プロトタイプによるUX検証までで十分な場合もあります。

  • 画面と操作性:モックアップ・プロトタイプで固める
  • 連携と規制:PoCで技術的な可能性と対応範囲を確かめる

統合する業務領域が増えるほど、単体では動くものでも、組み合わせると不具合が起きやすくなります。そのため、予約・診察・会計・院内物流を横断する総合基幹システムでは、こうした問題を確かめるのにPoCが役立ちます。

電子カルテやレセコンは、メーカーごとに仕様が異なるため、デモ環境では見えない不整合が、実データに近い検証で判明する場合があります。

段階を踏んで検証することが、医療業界のシステム開発で手戻りを防ぐ基本方針になります。

ポイント

本開発に入る前に、画面の合意、現場の操作、技術と規制のどれを確かめたいのかを決めます。目的が決まれば、モックアップ、プロトタイプ、PoCのどれで検証するかも選びやすくなります。

PoCが重要視される理由と期間・費用の目安

医療業界では、予算超過や現場での形骸化を避けるための手段として、PoCが重視されています。その理由と、実施期間・費用の目安を続けて扱います。

PoCが防ぐ「規制対応の手戻り」と「現場の形骸化」

PoCが重要な理由は二つあります。

第一に、契約後のカスタマイズ膨張と規制対応の手戻りを防ぐことです。

  • 予算超過の抑制:自院の業務との適合度や法規制上の該当性を洗い出す
  • 現場受容性の確認:機能検証に加えて、スタッフが使い続けられるかを確かめる

デモ画面だけでは分からない点を契約前に押さえておけば、想定外のカスタマイズや規制対応を減らせます。

第二に、使いにくさで入力が滞ると、データが蓄積されず形骸化するおそれがあります。そのため、PoCでは機能の実現可能性と現場受容性の両方を、本開発の前に検証します。

モックアップ・プロトタイプ・PoCの期間・費用目安

モックアップやプロトタイプは、画面設計とUI/UXデザインが中心になります。費用と期間は、手法や対象範囲によって異なります。

  • モックアップ・プロトタイプ:約50万〜80万円、期間は数週間程度
  • PoC・MVP検証:コア機能に絞る場合、初期投資は100万〜300万円程度
  • 全業務のフル機能開発:1,500万〜4,000万円以上、期間は10ヶ月以上

PoCやMVPでは、全業務を一度に統合せず、最小限の機能から市場や現場で検証します。

AI駆動開発や既存テンプレートで共通機能の開発を省けば、数週間でプロトタイプやMVPを構築する手法も広がっています。そうして得た現場のフィードバックをもとに、本開発の前に改善点を確かめられます。

ポイント

PoCを行うかは、契約後の想定外のカスタマイズや規制対応のおそれと、現場が使い続けられるかの両面で判断します。両方を見ておけば、予算超過と形骸化の両方に備えられます。

医療機関特有の検証ポイント(現場受容性とシステム連携)

現場受容性を確かめる操作場面と、既存システムとの連携項目をハブ図で示しています。
現場の例外操作と接続先ごとのデータ処理を確認項目に含めます。

PoC・プロトタイプでは、現場受容性と既存システムとの連携技術という二つの点を、必ず検証します。

現場受容性(医師・看護師・事務スタッフのUX検証)

医療現場では、使いにくさがそのまま業務の遅れや患者対応の質の低下につながります。そのため、通常の操作に加えて、例外時の動きも確かめます。

  • 入力ミス時:エラー表示が適切に伝わるか
  • 同時ログイン時:複数の医師・看護師・事務スタッフの同時操作への対応
  • 限られた時間:必要な情報へ直感的にたどり着き、現実的な時間で入力できるか

たとえば、診察の合間や外来の隙間時間にスタッフに操作してもらい、入力にかかる時間や導線を確かめます。

「使いにくくても慣れればよい」という考えで導入すると、紙やExcelの運用に戻ってしまうケースがあります。

電子カルテ・レセコン・院内物流との連携技術検証

電子カルテ、レセコン、院内物流システム(SPD)は、メーカーごとに仕様が異なるため、連携の難所になります。

  • データ連携:PoCで接続可能性と同期の遅れが許容範囲かを試す
  • レセプト会計:診療報酬の点数計算に関わるデータを正確に扱えるか
  • 院内物流:薬剤・診療材料の在庫引当と使用実績の記録が正しいか

既存システムとのAPI連携では、別途100万〜300万円の追加費用が発生するケースがあります。

会計金額の誤りは医療機関の信用問題につながるため、実際のデータパターンに近いテストが欠かせません。

ポイント

現場受容性と連携の2点が、PoCやプロトタイプで確かめられているかが目安です。画面が整っていても、例外時の操作や既存システムとの接続が未確認なら、手戻りが起きやすくなります。

規制該当性の見極めと3省2ガイドライン対応の検証

患者の診療情報を中心に、薬機法、3省2ガイドライン、個人情報保護法と情報管理の観点を盾で囲んだ図解です。
制度上の該当性と情報管理の両面から確認します。

規制対応は、早い段階で検証しておく必要があります。薬機法上のプログラム医療機器(SaMD)に該当するかどうかと、3省2ガイドライン・個人情報保護法への対応を確かめます。

薬機法(SaMD)該当性の見極め

検査データを解析して疾患の可能性を通知・支援する機能は、薬機法上のプログラム医療機器(SaMD)に該当する可能性があります。

  • 機能の範囲:該当機能と非該当機能を分けて整理する
  • 専門家への相談:企画段階で、弁護士やRA(レギュラトリーアフェアーズ)コンサルタントに相談

該当する場合は、数ヶ月単位の審査対応と相応のコストが発生します。

総合基幹システムは予約・会計・物流などの非該当機能が中心でも、将来の解析支援機能を構想するなら、早めの確認が重要です。機能要件を決める前に境界を明確にしておかないと、後から仕様変更が必要になり、手戻りを招きます。

3省2ガイドライン・個人情報保護法対応の検証

患者の診療情報を外部クラウドなどに保存する場合は、3省2ガイドライン(第6.0版)に沿って、機密性・完全性・可用性を検証します。

  • アクセスと通信:権限設計と暗号化方式が技術的に実現できるか
  • データ保管:国内サーバー指定の要否を含め実現可能か
  • 患者データ:同意取得の流れと利用目的の明示方法

患者データは、個人情報保護法上の要配慮個人情報にあたります。そのため、画面イメージとあわせて、同意や目的の表示も確かめます。

検証を後回しにすると、院内の倫理委員会やセキュリティ部門の承認が得られず、終盤で頓挫するおそれがあります。

ポイント

自社のシステムが薬機法(SaMD)や3省2ガイドラインの対象かを、企画の早い段階で確かめられているかが目安です。境界が曖昧なまま機能要件を決めると、後の仕様変更で手戻りが生じます。

陥りやすい失敗パターンと対策

PoC・プロトタイプ段階の失敗には、一定の傾向があります。代表的な二つのパターンと、それぞれの対策を取り上げます。

要件定義不十分による認識ズレ・機能の詰め込みすぎ

現場の暗黙のルールや業務フローが開発側に伝わらず、完成間近に「思っていたものと違う」と判明することがあります。

  • 認識のずれ:モックアップやワイヤーフレームで、画面と機能を視覚的に合意
  • 機能過多:MVP(最小限の機能)を決めてリリース

本開発の前に、院内管理者や現場スタッフと画面を一緒に確認し、どこで何ができるかを合意しておきます。

電子カルテ・予約・会計・物流をすべて最初から作ろうとすると、テスト項目が指数関数的に増え、品質低下や納期遅延を招きます。たとえば「まずは予約と電子カルテの連携だけ」のように範囲を絞り、段階的なリリース計画を立てます。

セキュリティ・データ基盤設計の後回し

動くプロトタイプを先に作り、セキュリティを後回しにすると、大幅な改修と手戻りコストが生じることがあります。

医療データは要配慮個人情報にあたるため、セキュリティは設計の早い段階から考える必要があります。

  • 設計初期:通信の暗号化と権限管理を組み込む
  • リリース前:第三者機関による脆弱性診断の実施

脆弱性診断には、ペネトレーションテストなどを含めて、100万〜300万円かかるケースがあります。

PoC・プロトタイプでの視覚的な合意、規制該当性の確認、MVPによる段階開発を徹底すると、数千万円規模の失敗を防ぎやすくなります。

ポイント

要件のずれと機能の詰め込みは、画面の合意とMVPによる範囲の絞り込みで防ぎます。セキュリティは、設計の初期に組み込めているかで判断します。

まとめ

予約・診察・会計・院内物流を統合する医療機関向けシステムについて、検証手法の違い、費用、医療特有の確認点、規制、失敗対策を振り返りました。

モックアップ・プロトタイプは約50万〜80万円、PoC・MVPは100万〜300万円程度が目安です。一方、全業務の開発は1,500万〜4,000万円以上、10ヶ月以上かかります。

現場受容性、電子カルテ・レセコン・院内物流との連携、薬機法(SaMD)該当性、3省2ガイドラインと個人情報保護法を確認します。

失敗の型は、要件の認識ずれ、機能過多、セキュリティ設計の後回しです。防止の柱は、視覚的な合意、MVPでの段階開発、初期の対策になります。

まず、自院が統合したい業務範囲を整理し、開発会社と検証の段取りを計画しましょう。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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