医療情報システム安全管理ガイドラインとPM。セキュリティ要件定義の仕事

「セキュリティ要件は情報システム部の管轄なので、PMは進行管理だけしていただければ」と、ある病院の情報システム部長に言われたことがあります。その場では「承知しました」と答えましたが、心の中では「それは無理だと思います」とつぶやいていました。

結論から書きます。医療情報システムの安全管理ガイドラインへの対応は、情報システム部やセキュリティ担当者だけで完結する仕事ではなく、要件定義・ベンダー選定・運用設計のすべてにまたがるプロジェクトマネジメントの仕事だと僕は考えています。ガイドラインは「守るべき基準」を示しますが、それを個々のシステムの要件に翻訳し、開発スケジュールや予算に落とし込むのはPMの役割です。この記事では、医療情報システムの安全管理ガイドラインの基本構造、PMが具体的にどこで手を動かすのか、そして僕が現場で見てきたよくある失敗と対処を、段階ごとに整理していきます。

1. 医療情報システムの安全管理ガイドラインとは何か

医療情報システムの安全管理に関するガイドラインは、厚生労働省が医療機関向けに策定してきた指針です。電子カルテやオーダリングシステムなど、患者の医療情報を扱うシステムに対して、アクセス制御・認証・記録の保存期間・外部保存・クラウド利用時の考え方などを定めています。個人的には「システムを作るときの建築基準法」に近いイメージで捉えています。建物を建てる際に耐震基準や防火基準を満たす必要があるのと同じように、医療情報システムを作るときには、このガイドラインが示す基準を満たす必要があるという理解です。

ガイドラインは版を重ねるたびに対象範囲が広がってきました。もともとは厚生労働省単独の指針でしたが、クラウドサービスの普及に伴い、経済産業省・総務省がそれぞれ事業者向けの指針を示すようになり、直近の版では3省の考え方を整理・統合する方向に進んでいます。この経緯を知っているかどうかで、PMが要件定義の場でどこまで踏み込んで発言できるかが変わってくると僕は考えています。ガイドラインの本文は数百ページに及ぶ分量があり、全てを読み込むのは正直に言って骨が折れる作業です。ですが、章立ての構成――経営管理編・企画管理編・システム運用編・システム管理編といった区分――を把握しておくだけでも、要件定義の会議で「それは企画管理編の話ですね」と切り分けができるようになり、議論が早く進みます。

2. PMが担う役割：要件定義から運用まで

PMがこのガイドラインに関わる場面は、大きく3つの段階に分かれると僕は整理しています。

要件定義段階では、ガイドラインが求める基準を、個別システムの要件書に翻訳する作業が発生します。「アクセスログを一定期間保存する」という抽象的な要求を、「ログサーバーの保存容量は目安として何か月分を確保するか」「保存先を院内に置くかクラウドに置くか」という具体的な設計判断に落とし込むのはPMの仕事です。

ベンダー選定段階では、提案書に書かれたセキュリティ対応が、実際にガイドラインの要求水準を満たしているかを確認する必要があります。ここで僕がよく感じるのは、ベンダーの提案書には「準拠しています」という一文だけが書かれていて、具体的にどの章のどの要求にどう対応しているかが書かれていないケースが少なくないということです。この確認を怠ると、契約後に不足が発覚し、追加開発の交渉をする羽目になります。

運用段階では、システムを導入した後も、インシデント対応体制や定期的な見直しの仕組みを運用ルールとして定着させる必要があります。ガイドラインは「作って終わり」ではなく「運用し続ける」ことを前提にしているため、PMの仕事も納品で終わりません。

3. ガイドライン改定にどう追随するか

改定への追随は、医療PMにとって地味だけれど避けられない仕事です。ガイドラインは数年ごとに版が更新され、版が変わるたびに求められる対応レベルが変わります。個人的な体感値で言うと、大きな改定のタイミングでは、既存システムの設計を丸ごと見直す必要が出てくることもあり、プロジェクトのスコープに直接影響します。

以下は、僕が現場でPMとして版の変化に向き合ってきた中で整理した、確認観点の目安です。あくまで独自の整理であり、実際の対応要否は個別の版の記載内容とシステムの構成によって判断してください。

この表からも分かる通り、版が新しくなるほど「作る時点」の基準だけでなく「運用する体制」への要求が増えている傾向があると僕は感じています。PMとしては、改定情報を入手したら、まず自分が担当するシステムのどの部分に影響するかをこの3観点程度でも仕分けしておくと、後の対応がスムーズになります。

4. よくある失敗とその対処

現場でよく見かける失敗のパターンを、3つ挙げてみます。

一つ目は、セキュリティ要件と機能要件を同じ表で管理してしまい、優先順位付けの際にセキュリティ要件が後回しにされるパターンです。以前僕が関わった案件では、リリース直前になってアクセスログの保存要件が未対応だったことが発覚し、リリースを目安として3週間ほど後ろに倒す判断をしたことがあります。セキュリティ要件は独立した管理表を作り、要件定義の初期段階から機能要件と同じ重みで扱うことが対処になると考えています。

二つ目は、ベンダーに「ガイドライン対応はお任せします」と丸投げしてしまうパターンです。ベンダーは自社のサービスの範囲でしか対応できないため、複数ベンダーが関わる構成では、どのベンダーがどの要求に責任を持つのかの境界が曖昧になりがちです。発注側のPMが責任分担表を作り、契約時にレビューする工程を入れることが有効だと僕は考えています。

三つ目は、運用開始後にセキュリティ担当の人員体制が細くなり、インシデント対応の訓練が形だけになってしまうパターンです。導入時は熱心に対応していても、運用フェーズに入ると優先度が下がりやすいというのは、僕が複数の現場で共通して感じてきたことです。運用開始前に、年に一度は訓練を実施するというようなルールを運用計画書に明記しておくことが対処になります。

5. 今日からできる実務チェックリスト

ここまで抽象的な話が多かったので、今日から始められる具体的なアクションを整理しておきます。

1. 自分が担当するシステムに対応するガイドラインの版と、章立てを一度通して目次だけでも確認する。
2. セキュリティ要件だけを抜き出した要件管理表を、機能要件の管理表と別に作成する。
3. ベンダーの提案書やSOWの中で、セキュリティ対応の記載が抽象的な部分に印をつけ、次回の打ち合わせで具体化を求める質問リストを作る。
4. 運用開始後の体制表に、インシデント対応の訓練予定を仮でも記入しておく。
5. 改定情報の入手経路（厚生労働省の公表ページなど）をブックマークし、確認する頻度を決めておく。

この5つは、どれも半日程度で着手できる作業だと思います。個人的には、最初の一歩は「自分の担当システムに関係する版と章立てを確認する」ことだと考えています。ここを飛ばして各論に入ると、後になって全体像とのズレに気づいて手戻りが発生しやすいというのが、僕の体感です。

6. ケース比較：病院システム導入とSaMDベンダーでの違い

医療情報システムの安全管理ガイドラインへの対応は、立場によって重心が変わります。ここでは、病院内のシステム導入PMと、SaMDを開発するベンダー側PMの違いを比較してみます。

病院内のシステム導入PMは、ガイドラインを「守るべき基準」として受け取り、院内の運用ルールや既存システムとの整合性を取ることが主な仕事になります。関係者は情報システム部・診療科・医事課など院内の多職種にまたがり、調整の難易度は人数の多さに比例して上がる傾向があります。

一方、SaMDを開発するベンダー側PMは、ガイドラインへの対応を「納品するシステムの仕様」として組み込む立場になります。加えて、SaMDである場合は薬機法の承認プロセスとも並走するため、安全管理ガイドラインへの対応と薬事申請の資料作成が並行して進むことになり、スケジュール調整の難易度が上がります。安全管理ガイドラインと薬機法は別の制度でありながら、要件定義の場では同じシステムの同じ機能について同時に検討が必要になる場面が多いというのが実務上の実感です。

どちらの立場でも共通しているのは、ガイドラインを「一度読んで終わり」にせず、プロジェクトの節目ごとに立ち戻って確認する姿勢が求められることだと僕は考えています。

0.（結論）

皆さんいかがでしたでしょうか。医療情報システムの安全管理ガイドラインは、情報システム部やセキュリティ担当者だけの仕事ではなく、要件定義からベンダー選定、運用設計まで、PMが手を動かすべき領域が広いというのが、この記事で一番伝えたかったことです。地味に見える確認作業の積み重ねが、結果的にプロジェクト全体の手戻りを減らすことにつながると僕は考えています。では今日もがんばりましょう。