🧭 やさしい解説シリーズ（技術編） 病院IT・情報システム担当・ベンダーの方へ。電子カルテ更改の「入口」にあたる要件定義とRFPを、つまずきどころから逆算して整理します。
ベンダーを選ぶ前に、勝負はついている
電子カルテの更改（こうかい）というと、「どのベンダーを選ぶか」が最大の関心事になりがちです。しかし実務では、選定にたどり着く前の段階で、成否の大部分が決まっています。
その段階とは、要件定義と、それをまとめた RFP（提案依頼書）です。
理由は単純です。何をしてほしいかが書かれていない仕様書に対しては、各社が「それぞれの想像」で見積りを出します。 A社は移行を含めて計算し、B社は含めずに計算する。C社は現場端末の入れ替えを前提にし、D社は据え置きを前提にする。この状態で並んだ金額は、そもそも比較できません。安く見えた提案が、稼働直前に追加費用として膨らむのは、たいていここが原因です。
RFPに書くべき7つのこと
完璧な文書を目指す必要はありません。ただし、次の7つが欠けると比較が成立しなくなります。
① 背景と目的
なぜ更改するのか。保守期限が来るからなのか、業務の課題を解決したいのか。ここが曖昧だと、以降のすべての判断に軸がなくなります。「何を良くしたいのか」を、できれば一文で。
② 現行システムの棚卸し
いま何が動いているのか。電子カルテ本体だけでなく、部門システム（検査・画像・調剤・給食など）、レセコン、予約、外部接続まで含めた一覧と、それぞれの接続関係。ここが書けていないと、ベンダーは接続の手間を見積れません。
棚卸しは、更改のためだけの作業ではありません。院として何を持っているかを把握すること自体が資産になります。
③ 業務要件 ― 誰が、何をするか
「〇〇機能があること」ではなく、「外来の看護師が、次回予約を診察中にその場で登録できること」のように、主語と場面を伴った書き方にします。機能名で書くと、ベンダーごとの製品名に引きずられ、実現方法を縛ってしまいます。
④ 非機能要件 ― 速さ・止まらなさ・守り
見落とされやすい領域です。
- 性能：画面の応答時間、同時に使う端末数、ピーク時間帯（外来受付の朝など）
- 可用性：止まってよい時間、計画停止の頻度、障害時の復旧目標
- セキュリティ：認証方式、アクセス権限の設計、アクセス記録の保存
- バックアップ：取得間隔、保管場所、復元テストを誰がいつ行うか
「速いこと」「安全なこと」では要件になりません。数字か、判断できる条件で書くのが原則です。
⑤ データ移行要件
更改で最も揉める部分です。どの範囲を、どの形式で、いつ移すのか。ここを書かずに「現行データを移行のこと」とだけ記すと、範囲の解釈がベンダーごとに割れます。
移行は単独で大きなテーマなので、電子カルテの更改・データ移行で失敗しないために で詳しく扱っています。RFPには最低限、移行対象の期間・種別（構造化データ／文書／画像）・移行後の検証方法を書いてください。
⑥ 保守・サポートの範囲
稼働してからのほうが、付き合いは長くなります。問い合わせ窓口の時間帯、障害時の駆けつけ条件、リモート保守の方式、バージョンアップの費用負担。ここを書かないと、稼働後に「それは保守範囲外です」が始まります。
保守にあたって外部から院内システムへ接続する経路の設計は、それ自体が安全管理上の論点です。あわせて外部との通信・保守回線 もご覧ください。
⑦ 提案様式と評価方法
同じ様式で出してもらうこと。項目の並びが揃っていないと比較に膨大な手間がかかります。あわせて、何を重視して評価するか（価格・機能適合・移行実績・保守体制など）を先に示しておくと、提案の質が上がります。
現場ヒアリングは「不満」から入る
要件は会議室では出てきません。現場に行き、実際の操作を見せてもらうのが最短です。
有効なのは、機能の希望を聞くより先に「いま、いちばん面倒なことは何ですか」と尋ねること。人は欲しい機能をうまく言葉にできませんが、日々の不便は具体的に語れます。「この画面を毎回3回開き直している」「紙に書いてから入力し直している」——こうした声が、そのまま業務要件の材料になります。
ヒアリングでは、声の大きい部署だけに偏らないことにも注意します。外来・病棟・医事・検査・薬剤・放射線——それぞれ見ている画面が違います。
典型的な失敗パターン
- 「現行と同じで」の丸投げ：現行の不便まで引き継ぎます。しかも「同じ」の定義が人によって違います。
- 移行範囲を決めないまま選定に進む：最後に費用と工期が跳ね上がります。
- 非機能要件を書かない：稼働後に「遅い」「よく止まる」と言っても、契約上の根拠がありません。
- 現場を見ずに書く：使われない機能に費用を払い、必要な機能が抜けます。
- 運用・保守条件を後回しにする：導入費用だけで比較し、数年間の総額で損をします。
「決まっていない」と書いてよい
要件定義を前に進められなくなる最大の理由は、完璧に書こうとすることです。しかし更改の検討段階では、決まっていないことが必ず残ります。
そのときは、「現時点では未定。〇月までに決定する」と明記するほうが健全です。空欄のまま出すと各社が勝手に前提を置きますが、未定と書けば、前提条件つきの見積りという形で揃います。後から差分を確認することもできます。
まとめ
- 電子カルテ更改の成否は、ベンダー選定より前のRFPでほぼ決まる。要件が書けていないと見積りの比較そのものが成立しない。
- RFPに要るのは ①背景と目的 ②現行の棚卸し ③業務要件 ④非機能要件 ⑤移行要件 ⑥保守範囲 ⑦提案様式と評価方法。
- 業務要件は機能名ではなく、主語と場面を伴った書き方で。非機能要件は数字か判断できる条件で。
- 現場ヒアリングは「欲しい機能」より「いま面倒なこと」から入ると具体化しやすい。
- 未確定事項は空欄にせず、「未定」と明記して前提つきで提案を揃える。
学びを深める
📎 あわせて読みたい
- 電子カルテの更改・データ移行で失敗しないために ― RFPの⑤移行要件を掘り下げた記事
- オンプレミス か クラウド か ― ④非機能要件の前提となる置き場所の判断
- 外部との通信・保守回線 ― ⑥保守範囲と安全設計
- 言葉の確認は 医療DX 用語集
要件定義・RFP策定は、業務の言葉とシステムの言葉を往復できるかが要になります。MEDICT は大学病院・県立病院での電子カルテ統括と構築の経験をもとに、医療機関のシステム調達・更改をご支援しています。