電子カルテを入れ替えた半年後に、「このシステムのログはどこまで取れているのか」「サーバは国内にあるのか」「障害時の復旧目標は何時間なのか」を院内で問われて答えられない——医療機関のセキュリティ相談で、最も多く出てくる状況のひとつです。そして問い合わせた結果、「その要件は契約範囲に入っていません」「オプションになります」という回答が返ってくる。
これは事業者が不誠実だから起きるのではありません。仕様書に書かれていない要件は、見積りにも設計にも入らないという、ごく当たり前の構造から起きています。調達においてセキュリティ要件は、契約後に交渉するものではなく、仕様書の段階で確定させるものです。
2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算は、この構造をさらに重くしました。ガイドラインへの準拠や専任の医療情報システム安全管理責任者の配置が算定要件に組み込まれたことで、セキュリティ対策は「余裕があればやること」から「算定できるかどうかを左右すること」に変わっています。調達の巧拙が、そのまま算定可否に効いてくる段階に入りました。
本記事は、医療機関がシステム調達の仕様書にセキュリティ要件を書き込むための実務を整理したものです。何を書くか、どう書くか、そして書いたことをどう確認するかまでを扱います。
免責：本記事は一般的な情報提供です。診療報酬の算定要件は厚生労働省の告示・通知および疑義解釈が正本であり、ガイドラインの要求事項は「医療情報システムの安全管理に関するガイドライン」本文が正本です。実際の調達判断はそれらおよび顧問弁護士・所管当局の確認に基づいて行ってください。
後から要求しても通らない構造
調達を時系列で並べると、セキュリティ要件を入れられる窓がどこにあるかがはっきりします。
| 段階 | セキュリティ要件を入れられるか | 理由 |
|---|---|---|
| 要件定義・仕様書作成 | 入れられる | 見積りの前提になる。事業者は要件を満たす構成で提案する |
| 提案・見積り | 限定的 | 質問回答で確認はできるが、要件の追加は不公平になるため難しい |
| 契約交渉 | 限定的 | 契約書の条項としては入るが、価格・納期の再交渉が必要 |
| 設計・構築 | ほぼ通らない | 仕様変更として追加費用と工期延長が発生する |
| 稼働後 | 通らない | オプション扱い。構成によっては実現不能 |
ポイントは、技術的に不可能になる要件があることです。たとえば「すべての参照操作のログを取得し1年以上保管する」という要件は、ログ機能の設計に依存します。稼働後に追加しようとしても、製品のアーキテクチャがそれを前提にしていなければ実現できません。データの保存先を国内に限定する要件も同様で、稼働後の移設は事実上の再構築になります。
もうひとつ見落とされやすいのが、要件を書かなかったことの責任は発注側に残るという点です。ガイドラインは医療機関に対して、委託先を含めた管理を求めています。事業者が要件を満たしていなかったとしても、それを要件として示していなければ、医療機関側の管理不備として整理される余地が生まれます。責任の所在については 責任分界点の決め方 と SLAと責任分界の書き方 で詳しく扱っています。
仕様書に書くべき要件の骨格
セキュリティ要件を網羅的に書こうとすると膨大になり、かえって焦点がぼやけます。まずは次の8つの塊を押さえてください。この順序で書けば、事業者側も回答しやすくなります。
| # | 要件の塊 | 仕様書に書く内容 | 書かないと起きること |
|---|---|---|---|
| 1 | 準拠基準 | 準拠すべきガイドラインと版、対応範囲 | 「対応しています」の中身が検証できない |
| 2 | データの所在 | 保存先の国・リージョン、バックアップの所在 | 海外保存が判明し、後から移設できない |
| 3 | アクセス制御 | 権限設計、特権ID管理、多要素認証の適用範囲 | 全職員が同一権限という構成で納品される |
| 4 | ログ | 取得対象、保管期間、閲覧・出力の手段 | 事故時に「誰が何を見たか」を再現できない |
| 5 | バックアップ | 方式、世代数、オフライン保管の有無、復旧試験 | 加算の要件を満たせない。同時に暗号化される |
| 6 | インシデント時の対応 | 連絡体制、初動の着手時間、報告内容、復旧目標 | 発生時に連絡先すら特定できない |
| 7 | 委託・再委託 | 再委託の可否、事前承諾、再委託先の管理責任 | 知らない会社が本番データに触れている |
| 8 | 契約終了時 | データの返還形式、消去の証明、移行協力 | 次期更改でデータを人質に取られる |
このうち 5（バックアップ）と 6（インシデント時の対応）は、診療報酬の算定要件と直接つながります。電子的診療情報連携体制整備加算の加算1では、複数方式によるバックアップ（一部はオフライン保管）と、サイバー攻撃等を想定したBCPの策定・訓練が求められます。システム側がこれを支える構成になっていなければ、院内の体制だけでは要件を満たせません。バックアップ方式の具体は 医療機関のバックアップ設計｜3-2-1ルール、BCPは サイバー攻撃を想定したBCP を参照してください。
要件は「機能」ではなく「達成すべき状態」で書く
よくある失敗は、要件を製品機能の名前で書いてしまうことです。「EDRを導入すること」と書くと、その製品を入れれば要件を満たしたことになります。目的は端末で起きた不審な挙動を検知し追跡できることのはずで、それが達成されているかは別の話です。
悪い例: 「操作ログ機能を有すること」
良い例: 「診療録の参照・作成・更新・削除・印刷・外部出力の各操作について、
操作者・日時・対象患者・操作種別を記録し、1年以上保管したうえで、
医療機関の担当者が期間・操作者・患者を条件に検索・出力できること」
後者であれば、提案段階で「参照ログは取得していません」「出力は当社作業となり別途費用です」といった差分が表に出てきます。仕様書の目的は、事業者間の差を見えるようにすることです。
ガイドライン準拠を要件化する書き方
「3省2ガイドラインに準拠していること」とだけ書いた仕様書は珍しくありませんが、これは要件として機能しません。ガイドラインは医療機関向け（厚生労働省「医療情報システムの安全管理に関するガイドライン」第6.0版）と事業者向け（経済産業省・総務省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」）に分かれており、事業者が守るべきなのは後者です。前者への準拠を事業者に求めても、責任の所在が曖昧になります。
書き方としては、次の3層に分けるのが実務的です。
| 層 | 書き方 | 例 |
|---|---|---|
| 遵守の宣言 | どのガイドラインのどの版に準拠するかを明記させる | 「経済産業省・総務省『医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン』に準拠すること」 |
| 分担の明示 | 医療機関側と事業者側の実施事項を対応表で提出させる | 「厚生労働省ガイドライン第6.0版の企画管理編・システム運用編の各要求について、当該システムにおける実施主体（医療機関／事業者／共同）を記載した対応表を提出すること」 |
| 個別要件の明記 | 重要な項目は独立した要件として書き下す | 上表の8項目を個別条文にする |
2層目の対応表の提出を要件にするのが、最も効果があります。「準拠しています」という一行では検証できないものが、要求ごとに誰がやるのかを書かせた瞬間に、空白や「医療機関側で実施」という記載が表面化します。この対応表は、そのまま院内の体制整備の設計図になり、監査対応の資料にもなります。3省2ガイドラインの全体像は 3省2ガイドラインとは、対応の進め方は 3省2ガイドライン対応の実務ステップ をご覧ください。
なお、厚生労働省は2025年5月14日に「医療機関等におけるサイバーセキュリティ対策チェックリスト」および同マニュアルを公表しています。従来より具体的で、クラウド環境・BCP・IoT・BYODへの言及が加わっているため、調達仕様の項目出しに使えます。使い方は 厚労省のチェックリストをどう使うか で扱います。
認証を必須要件にするか、加点にするか
ISMS（ISO/IEC 27001）やISO 27017、Pマークといった第三者認証を調達要件にするかどうかは、毎回議論になる論点です。整理すると次のようになります。
| 扱い | 向くケース | リスク |
|---|---|---|
| 必須要件（ないと失格） | 大規模病院の基幹システム、患者データを事業者環境で保持する案件、公的な調達手続に載せる場合 | 地域の中小ベンダーが参加できず、競争が働かない。保守の地理的近接性を失う |
| 加点項目（評価点に反映） | 部門システム、既存取引先も候補に含める案件、候補が限られる領域 | 点差の付け方によっては形骸化する |
| 要件にしない | 院内完結の小規模システム、認証の有無が実態と無関係な領域 | 体制の確認を個別に行う負担が残る |
判断の軸は、その事業者が患者データにどこまで触れるかです。クラウドで医療情報を預かる、リモート保守で本番環境に入る、データ移行で患者データを持ち出す——このいずれかに該当するなら、体制の第三者証明を求める合理性は高くなります。逆に、院内ネットワークに接続しない機器やスタンドアロンのソフトウェアであれば、認証の有無より個別の確認のほうが有効です。
認証の種類による意味の違いも押さえておいてください。
- ISO/IEC 27001（ISMS） — 情報セキュリティの管理体制全般。事業者側の体制証明として最も汎用的
- ISO/IEC 27017 — クラウドサービス固有の管理策。クラウドで医療情報を預かる場合に意味がある
- プライバシーマーク — 個人情報の取扱い。国内の認知度は高いが、対象は個人情報に限られる
重要なのは、認証は「審査時点で仕組みがあったこと」の証明であって、御院のデータが安全であることの保証ではないという点です。認証を持つ事業者に対しても、適用範囲（どの事業所・どのサービスが範囲か）と、御院の案件がその範囲に入っているかは必ず確認してください。認証書に記載された適用範囲が本社の管理部門だけで、実際の開発拠点が範囲外というケースはあります。適用範囲の読み方は ISMS適用範囲の決め方、認証全体の位置づけは ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド で解説しています。
認証を持たない事業者をどう扱うか
地域で長く保守を担ってきた事業者が認証を持っていない、というのはよくある状況です。ここで一律に失格とすると、調達の選択肢が狭まり、かえって運用リスクが上がることがあります。現実的な設計は次のようなものです。
- 必須要件は「体制の証明ができること」に置く。証明の手段として認証を例示しつつ、同等の説明（チェックシート回答＋根拠資料）でも可とする
- 加点として認証を置く。認証保有に明確な点差を付ける
- 契約後の是正を条件にする。一定期間内に体制整備を行うことを契約条項に入れる
3つ目は、事業者側にISMS取得等の動機を生みます。発注側が要求水準を示すことが、供給側の水準を引き上げる——調達が持っている最も大きな効果はここにあります。
要件が守られたことを確認する仕組み
仕様書に書いただけでは、要件は満たされません。確認の方法まで要件に書いておくことが必要です。
| タイミング | 確認方法 | 仕様書に書く文言の例 |
|---|---|---|
| 提案時 | チェックシート回答、対応表、認証書の写し | 「別紙セキュリティチェックシートに回答のうえ提出すること」 |
| 契約時 | 契約書・覚書への条項化 | 「再委託を行う場合は、事前に書面による承諾を得ること」 |
| 検収時 | 設定内容のエビデンス提出、ログ出力の実演 | 「権限設定一覧およびログ出力サンプルを納品物に含めること」 |
| 運用中 | 年次報告、監査権の行使 | 「年1回、セキュリティ対策の実施状況を書面で報告すること」 |
| 契約終了時 | データ返還と消去証明 | 「契約終了時に、データを指定形式で返還し、消去を証明する書面を提出すること」 |
とくに検収時のエビデンスは効きます。「ログが取れること」を要件にしていても、検収でログの出力サンプルを見なければ、実際には管理者しか出力できない・CSVではなく画面表示のみ、といった実態が稼働後まで分かりません。
監査権については、条項として入れておくことをお勧めします。実際に監査を実施しなくても、監査を受け入れる義務がある状態は、事業者側の管理水準に影響します。ただし現実的な範囲——書面での報告を原則とし、重大な事象が生じた場合に立入を求められる、といった設計——にしておかないと、価格に跳ね返ります。
チェックシートの具体的な項目は ベンダーへのセキュリティチェックシート、提案時に投げる質問の形は 事業者に確認すべき質問リスト にまとめています。クラウド案件固有の選定基準は クラウド事業者の選定基準 を参照してください。
まとめ
医療情報システムの調達にセキュリティ要件を入れるうえで、押さえるべき点は次のとおりです。
- 要件は仕様書の段階でしか入らない。稼働後の追加はオプション扱いになるか、アーキテクチャ上そもそも実現できない
- 要件は8つの塊（準拠基準・データの所在・アクセス制御・ログ・バックアップ・インシデント対応・再委託・契約終了時）で骨格をつくる
- 要件は製品機能名ではなく、達成すべき状態として書く。そうすれば事業者間の差が提案段階で見える
- ガイドライン準拠は「準拠していること」ではなく、要求ごとの実施主体を書いた対応表の提出を求める
- 認証は必須にするか加点にするかを、事業者が患者データにどこまで触れるかで決める。認証があっても適用範囲は必ず確認する
- 書いた要件は、提案・契約・検収・運用・終了の各段階で確認する方法まで仕様書に書いておく
調達要件の設計は、院内の体制整備と表裏一体です。どこまでを事業者に求め、どこからを自院で担うのかが決まらないと、要件は書けません。要件定義の段階で整理がつかない場合や、既存契約の見直しから手を付けたい場合は、お問い合わせ からご相談ください。ポテックは医療情報システムの開発と、ヘルスケア事業者側の ISMS認証取得支援 の双方を手がけており、発注側・受注側の双方の事情を踏まえた整理をお手伝いできます。
参考・出典
- 医療情報システムの安全管理に関するガイドライン｜厚生労働省
- 医療情報システムの安全管理に関するガイドライン 第6.0版（本文PDF）｜厚生労働省
- 令和8年度診療報酬改定について｜厚生労働省
- 情報処理推進機構（IPA）
- 個人情報保護委員会
※ガイドラインの要求事項および診療報酬の算定要件は改定・疑義解釈により変わります。調達仕様への反映にあたっては、最新の公表資料をご確認ください。