第3章 病院IT担当者の視点
3.1 病院の情報セキュリティ責任
病院が守るべきもの
病院のIT部門は、以下の情報資産を保護する責任を負っている。
| 情報資産 | 具体例 | 機密レベル |
|---|---|---|
| 患者情報 | 氏名、生年月日、病歴、検査結果 | 最高 |
| 診療情報 | 診断内容、処方情報、手術記録 | 最高 |
| 医療機器データ | 検査画像、分析結果、装置ログ | 高 |
| 業務情報 | 職員情報、経営データ、契約情報 | 中〜高 |
情報セキュリティの三原則（CIA）
病院のセキュリティポリシーは、情報セキュリティの三原則に基づいて設計されている。
| 原則 | 意味 | 病院での具体例 |
|---|---|---|
| 機密性 (Confidentiality) | 許可された者だけがアクセスできる | 患者データを部外者が閲覧できない |
| 完全性 (Integrity) | 情報が改ざんされない | 検査結果が送信途中で変更されない |
| 可用性 (Availability) | 必要なときに利用できる | 緊急検査時にシステムが停止していない |
責任の所在
病院の情報セキュリティに関する最終責任は病院の管理者にある。外部ベンダーが提供するサービスであっても、それを導入し院内ネットワークに接続を許可した責任は病院側にある。
この点を理解することで、病院IT担当者がなぜ慎重な姿勢を取るのかが理解できる。
3.2 院内ネットワークはなぜ閉じているか
閉域ネットワークの原則
多くの病院では、院内ネットワークはインターネットから隔離された閉域ネットワークとして設計されている。
閉域にする理由
| 理由 | 説明 |
|---|---|
| ランサムウェア対策 | 外部からの攻撃経路を物理的に遮断する |
| 情報漏洩防止 | 患者データが外部に流出する経路を作らない |
| 規制準拠 | 医療情報セキュリティに関する規制・ガイドライン（日本: 3省2ガイドライン、米国: HIPAA Security Rule、EU: GDPR/NIS2指令）が外部接続に厳格な要件を課している |
HIPAA（米国）
GDPR / NIS2指令（EU）
3省2ガイドライン（日本）
エンジニアへの示唆
Smart Assistは、この閉域ネットワークから外部（AWS）への通信経路を開ける必要があるサービスである。つまり、病院のセキュリティ原則に対して「例外」を申請する立場にある。
この事実を正面から理解し、「なぜ安全なのか」を技術的根拠をもって説明できなければならない。
3.3 外部接続が最大の関心事になる理由
病院IT担当者の心理
病院IT担当者にとって、外部接続の許可は最もリスクの高い意思決定のひとつである。
多くの場合、「許可しない」方がリスクが低いと判断される。これが、外部接続の提案がしばしば拒否される構造的な理由である。
過去のインシデントの影響
近年、医療機関を標的としたサイバー攻撃が複数報告されている。これらの事例は病院IT部門の危機意識を高めており、外部接続に対する警戒感はますます強まっている。
エンジニアとしては、この警戒感を「過剰な心配」と捉えるのではなく、正当な懸念として尊重する姿勢が必要である。
3.4 ベンダー提案に対する典型的な懸念
病院IT担当者が抱く懸念
Smart Assistのようなクラウド連携サービスの提案を受けた際、病院IT担当者は以下のような懸念を抱く。
| 懸念カテゴリ | 具体的な質問・不安 |
|---|---|
| データの行き先 | 「患者データがどこに送られるのか？」 |
| データの内容 | 「送信データに患者を特定できる情報は含まれないか？」 |
| 通信の安全性 | 「通信は暗号化されているか？」 |
| 侵入リスク | 「外部から院内ネットワークに入られる可能性はないか？」 |
| 障害時の影響 | 「クラウドが停止した場合、検査業務は止まるか？」 |
| 責任の所在 | 「データ漏洩が起きた場合、責任はどちらにあるか？」 |
| 規制準拠 | 「ガイドラインに準拠しているか？」 |
ベンダーがやりがちな失敗
| 失敗パターン | 問題点 |
|---|---|
| 「クラウドなので安全です」 | 根拠がない。クラウドであること自体は安全性の証明にならない |
| 「暗号化しています」 | 何をどのように暗号化しているか具体的に説明していない |
| 「他の病院でも使っています」 | その病院のセキュリティポリシーが同じとは限らない |
| 技術用語を並べて煙に巻く | 理解されなければ信頼は得られない |
正しいアプローチ
- 具体的な通信フローを図示して説明する
- 送信データの一覧を明示する（含まれるもの・含まれないもの）
- 通信方向がOutbound Onlyであることを技術的に説明する
- 想定される質問に対する回答を事前に準備する
3.5 セキュリティレビューで必ず聞かれること
典型的な質問と回答の方向性
病院のセキュリティレビューでは、以下の質問がほぼ必ず提示される。各質問に対して、エンジニアは技術的根拠を持って回答できなければならない。
Q1: 通信の方向は？
質問: 「この通信は院内から外部への一方向か、双方向か？」
回答の方向性: 通信の起点は常に院内PC側である。クラウドからの結果返却は、院内PCが開始したHTTPSセッションに対するレスポンスであり、クラウドから院内への新規接続は発生しない。（第2章 2.6参照）
Q2: 送信データの内容は？
質問: 「患者を特定できる情報は送信されるか？」
回答の方向性: 日本等での運用では、送信されるのは匿名化された検体IDと顕微鏡画像のみであり、患者氏名・生年月日等の個人識別情報は含まれない。
ただし、米国ではCLIA（Clinical Laboratory Improvement Amendments）要件を満たすため、検体ID（バーコードID）・生年月日・性別のPHI（Protected Health Information）が送信データに含まれる設定となっている。このため、米国の医療機関ではより厳格なセキュリティ審査が求められる。（第2章 2.2参照）
Q3: 通信の暗号化は？
質問: 「通信経路は暗号化されているか？」
回答の方向性: HTTPS（TLS 1.2以上）で暗号化されている。通信内容は経路上で盗聴・改ざんされない。（第6章で詳述）
Q4: 接続先は？
質問: 「どこに接続するのか？IPアドレスまたはFQDNは？」
回答の方向性: 接続先はAWS上の特定のFQDNであり、ファイアウォールでの許可対象を明示できる。（第7章で詳述）
Q5: 障害時の影響は？
質問: 「クラウドが停止した場合、検査業務全体が止まるか？」
回答の方向性: Smart Assistが停止しても、AUTION EYEの自動分類による確定分はLISに送信され続ける。影響を受けるのは未確定データの判定のみである。
Q6: 規制への準拠は？
質問: 「医療情報に関するガイドライン・規制に準拠しているか？」
回答の方向性: 導入先の地域で適用される規制に対する準拠状況を文書で説明する。（第9章で詳述）
| 地域 | 想定される質問 | 準拠の根拠 |
|---|---|---|
| 日本 | 「3省2ガイドラインに準拠しているか？」 | ガイドライン要件への対応状況一覧 |
| 米国 | 「HIPAA Security Ruleに準拠しているか？」 | BAA（Business Associate Agreement）の締結、Security Risk Assessment |
| EU | 「GDPRに準拠しているか？」 | DPIA（Data Protection Impact Assessment）の実施、DPA（Data Processing Agreement）の締結 |
3.6 資料の読み方：IT/Security説明資料
注: 本節で解説する「IT/Security説明資料」は、Smart Assist米国版に固有の資料である。米国ではPHI（Protected Health Information）を扱うため、病院IT/ISO部門向けに専用のセキュリティ説明資料が用意されている。
資料の概要
Smart Assistの導入検討時に、病院IT/ISO部門へ提出する主要資料が 「Smart Assist (US) IT/Security Explanatory Materials」 である。この資料は、病院側が導入可否を判断するために必要な技術・セキュリティ情報を網羅したテンプレートとして作成されている。
対応するファイル:
SmartAssist_US_IT_Security Draft-en
資料の構成と各セクションの読み方
| セクション | 内容 | 担当者が説明できるべきこと |
|---|---|---|
| 1. System Overview | Smart Assistの役割、AUTION EYEとの関係、PHI取扱い根拠、IT/セキュリティ設計前提、第三者認証の位置づけ | サービスの範囲（診断行為は行わない）、PHIを扱う理由（CLIA要件） |
| 2. Data Flow Diagram | PHIの流れ、PHIと非PHIの区別、保存・保持ポリシー | どのデータがPHIに該当し、どこに保存されるか |
| 3. Shared Responsibility Model | 病院・ARKRAY/UHW・AWSの責任範囲、PHI責任モデル、障害時対応 | 誰が何に責任を持つか（病院＝最終判断、ARKRAY＝アプリ運用、AWS＝インフラ） |
| 4. Network Requirements | 通信方向（Outbound Only）、宛先FQDN/ポート、暗号化方式 | FW設定に必要な最低限の情報（443/tcp、FQDN、TLS 1.2以上） |
担当者が押さえるべき重要ポイント
- Smart Assistは診断行為を行わない — 最終的な検査結果の検証・承認は医療機関の責任である
- PHIの範囲は限定的 — 送信されるのは生年月日・性別・検体識別子のみ。診断名・医師メモ・カルテ情報は一切扱わない
- Outbound Onlyの原則 — 病院から外部への通信のみ。病院ネットワークへの外部からの直接接続は不要
- 第三者認証は「絶対的な保証」ではない — HIPAA Risk Assessment、SOC 2、ISO 27001は一定のセキュリティ水準を示すものであり、個別の病院IT規定への自動的な準拠を保証するものではない
想定される質問と回答の方向性
| 質問 | 回答の方向性 |
|---|---|
| 「この資料だけで導入判断できるのか？」 | この資料はテンプレートであり、個別のネットワーク構成に応じた具体的なFW設定案（第7章参照）と合わせて提出する |
| 「CLIA要件とは何か？」 | 米国の臨床検査改善法（Clinical Laboratory Improvement Amendments）で、検査結果のトレーサビリティが求められる。そのためにPHIの一部を送信する必要がある |
| 「第三者認証の有効期限は？」 | ISO 27001は3年（最新: 2027年9月まで）、HIPAA Risk Assessmentは年次実施、SOC 2 Type IIは報告対象期間が明示されている |
3.7 セキュリティレビューで提出する資料一覧
病院のセキュリティレビューに対して、Smart Assistチームが提出できる資料の全体像を以下に示す。
| 資料 | 内容 | 発行元 | 対応する学習章 |
|---|---|---|---|
| IT/Security説明資料 | システム概要・PHIフロー・共有責任・NW要件 | ARKRAY | 本節（3.6） |
| HIPAA Risk Assessment Report | Security Rule / Privacy Rule全項目の監査結果 | ecfirst（第三者） | 第9章（9.6） |
| SOC 2 Type II Report | AWSインフラの統制評価報告書 | Ernst & Young（AWS監査） | 第8章（8.8） |
| ISO/IEC 27001認証書 | UHWの情報セキュリティ管理体制の認証 | MSA | 第9章（9.7） |
| ネットワーク説明資料 | クラウド構成図・FW設定・接続オプション | ARKRAY | 第6章（6.8）/ 第7章（7.7） |
これらの資料の詳細な読み方は各対応章で学習する。担当者はセキュリティレビューの場で、これらの資料を組み合わせて説明できるようになることが目標である。
次章では、病院ネットワークの具体的な構造を理解し、Smart Assistの通信経路がどのセグメントを通過するかを把握する。