医療ワークフロープラットフォームの要件定義：スコープ策定・ブリーフィング・RFP送付前に決めるべきこと

このガイドは、ワークフロープラットフォームの構築または刷新を決定し、ベンダーが正確に見積もれる要件セットへとその決定を落とし込む必要があるCIO、クリニック管理者、病院オペレーションマネージャー、デジタルヘルスのプロダクトオーナーを対象としています。「なぜ必要か」という問いはすでに解決済みという前提で進めます。業界全体の状況については医療分野のデジタルトランスフォーメーションを、構築済みプラットフォームが通常含む内容については医療オペレーションプラットフォームソリューションを、Netbase JSC が業界プログラムをシーケンスする方法については業界デジタルプラットフォームプレイブックの柱とデジタルトランスフォーメーションコンサルティングをご参照ください。

このガイドの内容

• クリニックや病院がワークフロープラットフォームをスコープ策定する前に定義すべき要件とは何ですか？
• ワークフローと役割の要件
• データと相互運用性の要件
• コンプライアンスとデータ取り扱いの要件
• 非機能要件
• 誰が何を決めるか：オーナーシップテーブル
• 要件レビューのシーケンス：ステップごとのガイド
• 要件定義段階でのAIの位置づけ
• どのような実績があり、何がないのか？
• 代替案：単機能ツール対フルワークフロープラットフォーム
• 省略されやすい要件とその省略コスト
• このガイドの限界とは何ですか？
• よくある質問
• 次のステップ

クリニックや病院がワークフロープラットフォームをスコープ策定する前に定義すべき要件とは何ですか？

要件とは機能要望リストではなく、すでに下された意思決定であり、ベンダーから「なぜ？」と問われたときに説明できるものです。次の4カテゴリで、ほぼすべての医療ワークフロープラットフォームの要件ブリーフをカバーできます。

これらのいずれかを省略しても要件がなくなるわけではありません。発見のコストをブリーフから契約へ、または契約からロールアウトへと先送りするだけです。

ワークフローと役割の要件

まず、ソフトウェアのカテゴリではなく、プラットフォームが変えるべきワークフローを明確にしてください。「スケジューリング」はカテゴリですが、「紹介状がスキャンされたPDFとして届き、受付担当者が三つのシステムに手動で再入力している」というのが要件です。各ステップについて、現状誰が関与しているか、何を決定するか、その決定に何が必要かを記録してください。医療オペレーションプラットフォームソリューションには、スケジューリング・患者フロー・文書受付など、構築済みプラットフォームが通常カバーするモジュールが一覧されています。これを候補ワークフローのチェックリストとして活用してください。ただし、実際のボトルネックがその中の1つだけに存在する可能性があるため、一覧そのものを要件と見なさないでください。ワークフロー要件は、トリガー・決定内容・関係者・終了条件を明記したときに完成します。「患者がオンラインで予約する」がトリガー、「当日中にスケジューラーが承認または再調整する」がベンダーの開発・テスト対象となる決定内容です。

データと相互運用性の要件

プラットフォーム自体に何をさせるかを説明する前に、プラットフォームが読み書きすべきすべてのシステムをリストアップしてください。電子健康記録（EHR）、検査・画像システム、請求・保険ツール、メッセージングサービスが一般的なセットです。各接続について、データフローの方向、連携が必要なフィールド、相手システムが求めるフォーマットを記載してください。HL7 FHIRは医療データ交換で広く採用されている標準規格です。接続先システムがすでにFHIRをサポートしている場合、カスタムインターフェースよりもFHIRを要件とする方が通常コストを抑えられます。まだインターフェースが存在しない場合は、それ自体を要件として明記してください。コストとスケジュールに影響するためです。また、システムが利用不可または不完全なデータを返した場合のフォールバック（例：検査結果の遅延）も記載してください。

コンプライアンスとデータ取り扱いの要件

このセクションは一般的な情報であり、法的アドバイスではありません。設計が法律に適合しているかどうかは、管轄区域ごとに医療機関が自身の法務アドバイザーとともに判断するものであり、Netbase JSC はいかなるコンプライアンス保証も提供しません。

• 米国。HHSのHIPAAプライバシーおよびセキュリティ規則は、対象事業者とそのビジネスアソシエイトによる保護された医療情報の使用・開示・保護を規定しており、HHSの公民権局（OCR）が執行します。
• 欧州連合。GDPR第9条は健康データを特別カテゴリとして扱い、第6条の一般的な適法根拠に加え、例外が適用されない限り処理を禁じています。欧州健康データ空間規則（EHDS）は、2027年から段階的に追加の義務を課します。
• 臨床上の境界。プラットフォームが臨床的な決定（診断・トリアージ・処方）を行ってはならないことを要件セットに明記してください。これらは臨床医とその認定システムが担います。

Netbase JSC のアプローチ。Netbase JSC は、HIPAAに準拠した方法論と欧州におけるGDPRデータプライバシーへの整合を遵守し、ロールベースのアクセス制御・転送中および保管中の暗号化・ペネトレーションテストなどのセキュリティ対策を適用し、自社オペレーションについてISO 27001およびSOC 2 Type IIに準拠しています。これらはNetbase JSC 社として適用されるものであり、クライアントのプラットフォームを認定するものではありません。より詳しい規制背景は医療分野のデジタルトランスフォーメーションをご覧ください。本ガイドは要件の記述に範囲を絞り、規制表の再掲は行いません。

非機能要件

非機能要件は暗黙のままにしやすく、後から追加するとコストがかかります。

• アクセス制御。どの役割がどのデータにアクセスできるか、また受付・臨床・請求のビューを分離する必要があるか。
• 監査ログ。何を、どのくらいの期間ログに記録するか、誰がそのログを参照できるか。
• データレジデンシー。データとバックアップを保存すべきリージョン（AIフィーチャーのモデルが稼働するリージョンを含む）。
• パフォーマンスと可用性の期待値。シフト中に応答が遅延した場合のコスト、およびダウンタイムを許容できないワークフローの特定。

誰が何を決めるか：オーナーシップテーブル

担当者の名前がない要件は、誰かが「実は未決定だった」と気づくまで漂流し続けます。ベンダーが見積もりを開始する前に、カテゴリごとに1名のオーナーを決定してください。

小規模なクリニックでは1人が複数の役割を兼ねることもあります。重要なのは、各カテゴリに担当者名が紐づいていることです。そうすることで、ベンダーからのスコープに関する質問に、数週間ではなく数日で回答できます。

どのような実績があり、何がないのか？

Netbase JSC の旧サイトでは医療が対象業界として掲載されており、印刷・包装・小売以外の医療クライアントにもプロジェクトを納品した実績がありますが、これらのクライアント名は公開されていません。匿名の医療オペレーションプラットフォーム事例には、Netbase JSC がコンサルティング・カスタム開発・インテグレーションを通じて構築したオペレーション・ワークフロープラットフォームが記録されており、クライアント名・患者データ・期間・数値は一切公開されていません。要件収集業務に特化したNetbase JSC の公開事例は存在しないため、本ガイドでは要件レビューの所要期間やプロセスに関する主張は一切行いません。

代替案：単機能ツール対フルワークフロープラットフォーム

すべての要件セットがプラットフォームを指し示すわけではありません。ボトルネックが1つのワークフローのみ、または患者数が少ない場合は、単一のスコープが明確なツールが正解となることがあります。スケジューリング・患者フロー・請求など複数の接続されたステージや、複数チームが同じ患者ジャーニーの共有された監査可能なビューを必要とする場合に、プラットフォームはそのコストを正当化します。どちらのルートを選ぶにしても、まず要件セットを作成してください。それにより、選択が推測ではなく意思決定となります。

Netbase JSC のモデルでは、カスタム開発を通じてクライアントのIPはクライアントが保持します。Netbase JSC が再利用する可能性のある製品化コンポーネントはライセンス供与であり、移転ではありません。Netbase JSC のプロジェクトの多くは、要件レビュー後にスコープと価格を合意する請負契約で提供されます。マイルストーンベース・リテーナー・KPIリンク・専任チームの契約形態も提供しています。要件レビューはNetbase JSC のデリバリーライフサイクルにおける発見ステップの中に位置づけられており、チーム編成とアーキテクチャ計画の開始前に行います。

省略されやすい要件とその省略コスト

• 臨床安全上の境界の省略。「プラットフォームは臨床的な判断を下さない」と明記しないと、後でフィーチャークリープを招きます。
• コンプライアンスを後回しにする。ベンダーが見積もりを出した後で管轄区域のデータ規則が判明すると、通常スコープの見直しと再見積もりが必要になります。
• データレジデンシーを暗黙にする。契約後にホスティングリージョンを決定すると、後から発見されたルールとの矛盾により、コストのかかる移行を強いられる可能性があります。
• オーナーを指名しない。担当者のいない要件は、発注側とベンダー側で異なる解釈がなされる可能性が高くなります。
• 要件ではなく機能を記述する。「AIチャットボット」は機能ですが、「患者が臨床医に連絡せずに予約状況を確認できる」はベンダーが開発できる要件です。

このガイドの限界とは何ですか？

本ガイドは要件セットの構造化に関する実務的なガイダンスであり、法的・コンプライアンス・臨床上のアドバイスではありません。設計が適用される規則を満たすかどうかは、医療機関が自身のアドバイザーとともに判断します。要件収集に特化したNetbase JSC の事例は公開されておらず、期間・コスト・成果の数値は一切主張していません。すでに稼働中のプラットフォームの近代化についてはレガシーシステム評価チェックリストをご参照ください。他業界の既存システムへの同じクラスターの適用例については旅行・ホスピタリティ業界の予約プラットフォーム近代化や、異なる業界プラットフォームの統合マップについては不動産プラットフォームのアーキテクチャと統合、異なるセクターでどのワークフローを最初に自動化すべきかのシーケンシングフレームワークについては製造・物流のワークフロー自動化や印刷・包装のデジタル化シーケンシングをご覧ください。

次のステップ

改善したいワークフロー、その周辺システム、関係する管轄区域をご共有いただければ、ベンダーへのブリーフィング前に要件セットをレビューします。または医療オペレーションプラットフォームをご覧いただくか、インサイトを閲覧するか、業界別プラットフォームを比較してください。

関連サービスとソリューション