第4章 病院ネットワーク構造の実態
4.1 医療機器セグメント
概要
医療機器セグメントは、AUTION EYEをはじめとする各種分析装置が接続されるネットワーク領域である。院内ネットワークの中でも最も物理的に機器が多く接続されるセグメントのひとつである。
特徴
| 特徴 | 説明 |
|---|---|
| 接続機器 | 分析装置、検体搬送システム、バーコードリーダーなど |
| 通信先 | 主にLISサーバ |
| 外部接続 | 原則なし（Smart Assistは例外） |
| IPアドレス体系 | 固定IPが割り当てられていることが多い |
| OSの世代 | Windows 7/10など旧世代のOSが残っている場合がある |
Smart Assistとの関係
Smart Assistクライアントが動作するPCは、このセグメントに配置される。つまり、医療機器セグメントからインターネットへの通信経路を確保する必要がある。
4.2 LISサーバセグメント
概要
LISサーバが配置されるセグメントである。検査部門の中核システムが稼働しており、高い可用性とセキュリティが求められる。
サーバーラックの例（ラックマウント型サーバーとネットワーク機器）
病院のサーバー室にもこのような構成が設置されている
特徴
| 特徴 | 説明 |
|---|---|
| 配置機器 | LISサーバ（メイン/バックアップ）、データベースサーバ |
| 通信先 | 医療機器セグメント、電子カルテセグメント |
| 外部接続 | なし |
| アクセス制御 | 許可された機器・端末からのみアクセス可能 |
Smart Assistとの関係
AUTION EYE（Smart Assistクライアント）は、2つのNIC（LANコネクタ） を持ち、それぞれ異なるネットワークに接続される。
| NIC | 接続先 | 用途 |
|---|---|---|
| LIS側NIC | LISセグメント（院内LAN） | LISとの検査オーダー受信・結果送信のみ |
| インターネット側NIC | インターネットに抜ける回線 | Smart Assistクラウドとの通信専用 |
この2つのNICは物理的に別のLANコネクタであり、接続するネットワークセグメントも異なる。LIS側NICではLIS用の通信のみを行い、Smart Assistのクラウド通信は一切流れない。
インターネット側NICの接続先は、病院が用意するインターネット接続用のLAN回線を使用する。病院側でインターネット回線の用意が難しい場合は、当社がモバイルルーターを用意して接続する場合もある。
用語: NIC（Network Interface Card）とは、PCをネットワークに接続するためのLANコネクタ（LANポート）のこと。AUTION EYE（Smart Assistクライアント）は2つのNICを持つことで、院内ネットワークとインターネットを物理的に分離している。
4.3 業務LAN
概要
業務LANは、医師・看護師・事務職員が日常業務で使用するネットワーク領域である。電子カルテ（EHR）端末、ナースコールシステム、医事会計システム（Revenue Cycle Management）などが接続される。
特徴
| 特徴 | 説明 |
|---|---|
| 接続機器 | 電子カルテ（EHR）端末、プリンタ、ナースコール端末 |
| ユーザー | 医師、看護師、事務職員 |
| インターネット接続 | 施設による（完全に遮断している場合もある） |
| セキュリティ | 端末認証、VLAN分離が一般的 |
Smart Assistとの関係
Smart Assistは業務LANとは直接的な通信を行わない。ただし、病院IT担当者はこのセグメントの管理者であることが多いため、ネットワーク全体の構成を把握している立場にある。
4.4 DMZ
DMZとは
DMZ（DeMilitarized Zone：非武装地帯）は、外部ネットワーク（インターネット）と内部ネットワーク（院内）の間に設置される中間的なネットワーク領域である。
病院におけるDMZの役割
| DMZに配置される機器 | 役割 |
|---|---|
| リバースプロキシ | 外部からの通信を中継・検査する |
| メールゲートウェイ | メールの送受信を中継する |
| Webサーバ | 病院ホームページなどの公開サーバ |
| VPN装置 | 保守用リモートアクセスの終端装置 |
| 踏み台サーバー | リモート保守時の中継サーバー（操作ログを記録） |
Smart Assistとの関係
Smart Assistの通信はOutbound Onlyであるため、DMZにサーバを配置する必要はない。ただし、病院によってはプロキシサーバがDMZに配置されており、Smart Assistの通信がそのプロキシを経由する場合がある。
リモート保守と踏み台サーバー
AUTION EYE（Smart Assistクライアント）のPCをリモートで保守する場合、医療機関がDMZにリモート保守用の踏み台サーバーを用意する場合がある。
大阪大学医学部附属病院の事例：
- 当社（UHW）の保守要員が、DMZ上の踏み台サーバーにログインする
- 踏み台サーバーを介して、AUTION EYE PCにリモートデスクトップで接続する
- 踏み台サーバーには操作ログが記録され、病院側がセキュリティを監査できる仕組みになっている
この構成では、AUTION EYE（Smart Assistクライアント）に3つ目のNICが必要になる。
| NIC | 接続先 | 用途 |
|---|---|---|
| NIC 1（LIS側） | LISセグメント（院内LAN） | LISとの検査オーダー受信・結果送信 |
| NIC 2（インターネット側） | インターネット回線 | Smart Assistクラウドとの通信 |
| NIC 3（リモート保守側） | DMZセグメント | 踏み台サーバー経由のリモートデスクトップ |
各NICは物理的に別のLANコネクタであり、それぞれ異なるネットワークセグメントに接続される。これにより、LIS通信・クラウド通信・リモート保守通信が物理的に分離され、セキュリティが確保される。
4.5 インターネット出口の制御
出口制御の仕組み
病院からインターネットへの通信は、たとえOutbound通信であっても厳格に制御されている。
一般的な制御手段
| 制御手段 | 説明 |
|---|---|
| ファイアウォール | 送信元IP、宛先IP、宛先ポートで通信を許可/拒否 |
| プロキシサーバ | HTTP/HTTPS通信を中継し、URL単位でフィルタリング |
| URLフィルタリング | カテゴリベースまたはホワイトリスト方式で接続先を制御 |
| IDS/IPS | 不正な通信パターンを検知・遮断 |
| SSLインスペクション | HTTPS通信の中身を復号して検査する |
ファイアウォール装置
(Cisco ASA 5510)
L2スイッチ（設置例）
(Cisco Catalyst 2950)
ルーター
(Cisco 2800)
Smart Assistの通信が通過する経路の例
このすべてのポイントで、Smart Assistの通信が許可されている必要がある。1箇所でもブロックされていると通信は失敗する。
上の図を見てわかるように、通信経路は複数のポイントを通過します。「通信できない」とき、全部を一度に見ようとすると混乱します。
コツは手前から1箇所ずつ確認すること。Smart Assist PC → ルーター → プロキシ → FW → インターネット → AWS、の順番で「ここまでは通るか？」を確認していく。最初に失敗したポイントが原因です。
具体的なコマンドと手順は第10章で詳しく解説しますが、この「手前から順番に」という考え方だけは今のうちに覚えておいてください。
4.6 プロキシサーバの存在
なぜプロキシサーバが重要なのか
多くの病院では、インターネットへのHTTP/HTTPS通信はプロキシサーバを経由する構成となっている。Smart Assistの導入において、プロキシサーバの有無と設定は最も頻繁にトラブルの原因となる要素のひとつである。
プロキシサーバの種類
| 種類 | 説明 |
|---|---|
| フォワードプロキシ | 院内端末からインターネットへの通信を中継する |
| 透過型プロキシ | 端末側での設定不要。ネットワーク経路上で自動的に中継する |
| 認証プロキシ | 通信時にユーザーID/パスワードの入力を要求する |
「プロキシ設定を教えてください」と病院IT担当者に聞いたら「自動構成スクリプトを使ってます」と言われることがあります。これがproxy.pac（またはwpad.dat）ファイル。
proxy.pacはURLごとに「プロキシを使う/使わない」を振り分けるJavaScriptファイルです。ブラウザはこれを解釈してくれますが、Smart Assistアプリケーションはpacファイルを解釈できない場合があります。
proxy.pacを使っている環境では、pacファイルの中身を見せてもらって、Smart Assistの宛先がどのプロキシに振り分けられるかを確認しましょう。そのプロキシのアドレス:ポートを直接指定するのが確実です。
プロキシ環境で確認すべきこと
| 確認項目 | 内容 |
|---|---|
| プロキシの有無 | そもそもプロキシサーバが存在するか |
| プロキシのアドレス | IPアドレスまたはホスト名、ポート番号 |
| 認証の有無 | 認証が必要か。必要な場合の認証方式 |
| 除外設定 | 特定の宛先をプロキシ経由から除外できるか |
| SSLインスペクション | プロキシがHTTPS通信を復号・検査しているか |
プロキシが原因で起きる典型的な問題
| 症状 | 原因 |
|---|---|
| 接続タイムアウト | プロキシ設定が未設定で通信が到達しない |
| 403 Forbidden | プロキシのURLフィルタで宛先がブロックされている |
| SSL証明書エラー | SSLインスペクションにより証明書が差し替えられている |
| 認証エラー | 認証プロキシのクレデンシャルが設定されていない |
透過型プロキシ（Transparent Proxy）は端末側で設定が不要なので、病院IT担当者に聞くまで存在に気づけません。「プロキシはありますか？」と聞いて「いいえ」と回答されても、実は透過型プロキシが入っていた...というケースがけっこうあります。
見分け方は curl -v の出力。接続先のIPアドレスが nslookup の結果と違っていたり、証明書の issuer が見慣れない名前だったら、透過型プロキシの存在を疑ってください。
ヒアリング時には「プロキシはありますか？」だけでなく、「URLフィルタリングやSSLインスペクションの製品は導入されていますか？」と聞くのがベスト。この聞き方なら透過型プロキシも拾えます。
これらの問題の切り分け方法は第10章で詳述する。
補足（国際的な文脈）: 本章で示した病院ネットワークの構成は、日本の医療機関における典型的なパターンである。米国では大規模ヘルスシステム（Epic/Oracle Health等を採用）が集中管理型のネットワークアーキテクチャを構築するケースが多い。欧州ではNHS Trust（英国）やKrankenhausグループ（ドイツ）など、国ごとに構成が異なる。いずれの地域でも「医療機器セグメントの分離」「外部接続の制御」という基本思想は共通であるが、実装方法やガバナンス構造が異なる点に留意すること。近年は米国・欧州を中心にSASE（Secure Access Service Edge）やゼロトラスト・アーキテクチャの導入が進みつつある。
Epic Systems
Oracle Health
NHS（英国）
次章では、ネットワーク通信の基礎知識を学び、Smart Assistの通信設計を理解するための土台を作る。