医療システムの要件定義では、診療フローを把握し、制度要件と安全性を機能に落とし込み、その内容をRFP（提案依頼書）にまとめます。
現場ヒアリングとToBe設計、医療制度と安全要件、RFPと見積りの確認方法を、順に説明します。全体像は医療業界のシステムの完全ガイドもご覧ください。
▼全体ガイドの記事
・医療業界のシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
診療フローのヒアリングとToBeモデル
医療システムの要件定義は、現場の診療・ケアの流れを把握するところから始めます。機能の一覧を作る前に、まず現場に話を聞き、流れを書き出して可視化することが出発点になります。診療科ごとの運用や患者対応の例外処理を無視すると、実態に合わないシステムになりかねません。
AsIsの診療・ケアフローを把握するヒアリング
まずは現状（AsIs）の業務フローを書き出すため、医療・介護の関係者に聞き取ります。
- 受付から会計まで：患者・利用者が受付から会計まで通る経路
- 記録と転記：記録場所と、そこから転記する先
- 保険請求：請求を作る手順
- 外部連携：他の医療機関や薬局とのやり取り
医師や看護師、薬剤師に加え、医療事務にも聞き取ります。
介護分野では、介護職員やケアマネジャーにも話を聞きます。
マニュアルに書かれた手順と、現場で実際に行われている運用の両方を押さえます。属人的な例外処理も、ここで拾っておきます。
ベテラン看護師が処置を手書きで管理したり、急患を通常と別の流れで処理したりする例があります。これを見落とすと、移行後に現場が回らなくなります。
介護ICTを「知らない」職員の割合が74%という調査結果もあります。現場のリテラシーは、研修や定着計画の内容に関わります。
AsIsの把握は地道な作業ですが、実態を正確につかむことで要件の漏れを防げます。
現場で使われるシステムを生む土台にもなります。
ToBeモデルによる「あるべき診療業務の姿」の設計
AsIsを把握したら、システム導入後のあるべき業務を示すToBeモデルを設計します。
- 記録の一元管理：紙カルテの記録をシステム上で扱える形にすること
- 転記の自動化：記録どうしの受け渡しを人手に頼らない形
- 請求との連携：保険請求まで一続きで流れる業務
新しい業務フローを具体的に描き、そこから必要な機能を逆算します。
要件定義の出発点をToBeに置くことが、現場の混乱を避けるための最大の防衛策です。
電子カルテを一斉に切り替えた例では、操作研修が機能説明に偏り、診療フローに沿った移行計画も不足していました。その結果、移行初日には外来の待ち時間が平均で3倍に膨らみました。現場が操作に追われたことが、失敗の本質です。
診療フローに沿った実地訓練と段階移行を要件に含めた医療機関では、混乱を最小限に抑えています。
医療特有の制度要件の機能要件への落とし込み
ToBeモデルの次に、医療特有の制度要件を具体的な機能要件へ落とし込みます。
保険請求や診療報酬改定、補助金の制度要件は、機能に反映させます。
個人情報保護についても、要件として機能に組み込みます。
制度は複雑で改定も頻繁なため、この反映は要件定義でもっとも難しく重要な工程です。曖昧な要件のままだと、手戻りや法令違反のリスクが生じます。
保険請求・診療報酬改定・補助金の要件化
保険請求の要件は、算定実態の把握から点数マスタの更新体制までを押さえておきます。
- 算定実態：自院の診療報酬点数と取得加算の洗い出し
- レセプト機能：自院の算定実態に合った作成・チェック機能
- 改定対応：制度の変更に合わせて点数マスタを更新する体制
令和8年度改定では、電子的診療情報連携体制整備加算が設定されます。加算1は15点、加算2は9点、加算3は4点です。
電子処方箋の導入では、国の補助が最大194,000円あり、さらに自治体の上乗せが最大29.1万円あります。
介護ICT導入支援では、職員数に応じて最低100万円相当が用意されています。
制度ごとに、対象となるシステムの要件と申請の手続きが決まっています。
補助対象となる仕様は要件に組み込み、要件定義の段階で適用可否を確かめます。この確認が、投資計画の精度を左右します。
マルチベンダー連携とデータ移行・過渡期の要件化
医療システムでは、電子カルテやレセコン、検査機器、薬局システムなど、複数ベンダーの製品が連携する場合があります。そのため、連携と移行では、責任の所在とデータの扱いを具体的に決め、要件として揃えておきます。
- システム連携：連携先の製品ごとに、データの流れる方向とタイミング
- 責任分界：障害時に原因を切り分ける担当ベンダー
- データ移行：旧システムから移す患者データの範囲
- 過渡期の連携：移行期間中の新旧の正と、その受け渡し方法
責任の境目が曖昧だと、トラブルのたびに医療機関がベンダー間で板挟みになり、原因の切り分けを強いられます。
旧システムから患者データを移す際、データの整備が不十分だと、誤った情報が表示される事故につながります。
既存システムと連携できない製品を安さを優先して選んだ結果、二重入力や入れ替えの費用、移行の負担が重なり、投資が全損した例もあります。
機能要件と非機能要件（個人情報保護）の整理
要件定義書には、機能要件と非機能要件の両方を盛り込みます。前者は「何ができるか」を示し、後者は品質や安全性を定めるものです。
医療システムは患者の生命や機微な個人情報を扱うため、セキュリティと可用性をおろそかにできません。
機能要件の必須・優先・将来による分類
機能要件は一覧にしたうえで、導入時の必要度ごとに分けます。
- 必須：診療記録、レセプト、処方、権限管理など、診療・請求に欠かせない機能
- 優先：予約、チャットボット、データ分析など、効果は大きいが初期導入は後回しにできるもの
- 将来：初期導入のあとに、追加で入れてよい機能
オーダーメイド開発は、小規模でも数百万円から、大規模では数千万円以上に膨らみます。そのため、優先度付けは予算管理に関わります。
見積りが予算を超えた場合にも、初期リリースから外す機能を判断できます。一方で、すべてを必須にしていると、予算超過時に削れず頓挫しかねません。
必須機能からリリースし、効果を見ながら優先機能を加えていく段階的な計画も立てられます。
機能の具体的な内容は、関連記事もあわせてご覧ください。
非機能要件（セキュリティ・可用性・BCP）
非機能要件では、セキュリティや可用性、BCP（事業継続）を定めます。医療情報を扱うため、セキュリティは最優先になります。
- アクセス管理：職種ごとに分けた権限の設定
- 通信と監査：データの経路の暗号化と、アクセス記録のチェック
- 不正アクセス対策：厚生労働省のガイドラインなどを参照した要件
設定ミスによって患者情報が外部から閲覧できる状態になった事故もあります。このため、設定を担当する人とレビューの方法も決めておきます。
システムが止まれば診療と患者の安全に直結するため、稼働率の目標と障害時の復旧時間、バックアップ体制を決めておきます。
障害やサイバー攻撃で使えなくなる場合に備えて、紙で診療を続ける運用フローも文書にしておきます。
停電や通信障害時の紙運用への切り替え手順は、定期訓練を要件に含めて確かめておきます。最悪の事態でも患者を守るためです。
非機能要件を機能要件と同じくらい丁寧に詰めることが、医療システムの安全性を支えます。
RFPに盛り込む項目と見積り妥当性の判断
要件定義書をもとにRFP（提案依頼書）を作り、複数のベンダーに提案を依頼します。
RFPが曖昧だと、返ってくる見積りも曖昧になり、横並びでの比較が難しくなります。医療システムは費用の幅が大きく、補助金や診療報酬の回収ロジックも絡みます。そのため、RFPで条件を揃えておくことが、見積りの妥当性を判断する前提になります。
RFPに必ず盛り込むべき項目
RFPでは、目的や現状から開発・運用の体制まで、提案の条件を具体的に示します。
- 目的と業務：記録時間削減や待ち時間短縮などのKPI、AsIs・ToBeフロー
- 要件：優先度付き機能要件、セキュリティ・可用性・BCP
- 連携と移行：既存システム連携、責任分界、データ移行方針
- 実施条件：予算、スケジュール、開発・運用・保守の体制
保険請求、診療報酬改定対応、補助金要件は、医療特有の中核項目として具体的に記載します。
導入後の運用や定着の支援も、RFPに盛り込みます。納品後に現場が使いこなして初めて、システムの効果が出ます。
たとえば、実地訓練や移行初日のサポート、稼働後の利用ログ分析や設定改善などの伴走を求めます。
納品時に支援が終わってしまうと利用率が下がり、投資が無駄になる悪循環を招きます。このため、オンボーディングと継続的な伴走を体制要求に含めることが、防衛策です。
見積りの妥当性を判断する観点
見積りを判断するには、まずシステム種別ごとの相場観をつかんでおきます。
- クラウド型電子カルテ：初期約10万〜数十万円、月額1万〜数万円
- オンプレミス型：初期200万〜500万円、月額2万〜4万円
- 介護ソフト：カイポケは月額5,000円〜で、SaaSとして始められる
独自要件をフルカスタマイズすると、費用は大きく膨らみます。相場との差が大きい見積りは、その理由を確かめます。
安すぎる見積りには、連携やセキュリティの要件漏れが隠れていることがあります。高すぎる場合は、不要な要件が含まれている可能性があります。
次に、データ移行費や並行稼働費、保守費の内訳を確かめます。見積りが一式と書かれている場合は、明細の開示を求めます。
データ移行や移行期の並行稼働は、見積りから漏れやすいコストです。これを見落とすと、計画が破綻する場合があります。
機能や工程ごとに工数と単価が示されていれば、費用がどこで生じるかを確かめられます。あわせて、追加要件の単価ルールも事前に決めておきます。
riplaは、フルスクラッチ受託と国内開発の立場から、要件の整理と見積り内訳の明示を重視しています。
要件定義の精度は、見積りを妥当と判断できるかどうかにも関わります。
体制図と実開発チームの要件による確認
提案時のプレゼンの出来より、RFPで実開発体制を確かめることが、稼働後のトラブルを防ぎます。
- 体制図：PM、実装担当者、保守担当者を明記した資料の提出
- 実開発責任者：可能であれば提案段階での面談
- 要件理解：診療フローとセキュリティ要件への理解の度合い
提案時の担当者と実開発チームが異なり、経験の浅いチームが開発を担うと、稼働後に障害が頻発する場合があります。患者の安全に関わる医療システムでは、こうした体制の食い違いが、経営や信頼にとどまらない影響を及ぼします。
機能や費用に加えて、「誰が作るか」という体制の透明性まで確保して初めて、要件定義は完成します。
まとめ
医療システムの要件定義は、現場に聞き取ってAsIsを把握し、ToBeを描くところから始まります。
保険請求や診療報酬改定、補助金、個人情報保護といった医療特有の制度要件は機能に反映させ、機能は必須・優先・将来に分けます。セキュリティや可用性、BCP（紙運用を含む）も詰めます。
RFPには、マルチベンダーの連携と移行の要件を責任分界まで含めて明記し、運用伴走の体制要求も書き込みます。提案を横並びで比べ、相場に照らして見積りの妥当性を判断できます。
電子カルテの一斉移行で外来が麻痺した例のように、要件定義の質は現場の混乱と深く関わります。現場の診療の実態を反映した要件が、現場で使われるシステムにつながります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、ヒアリングからToBeモデル作成、制度要件の整理を経て、RFP作成まで医療機関を支援します。
全体像を改めて確かめたい場合は、完全ガイドをご活用ください。
▼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を創業。