第2章 Smart Assistの業務構造理解
2.1 自動分析と未確定判定
AUTION EYEの自動分類プロセス
AUTION EYEは尿検体を撮影し、画像中の有形成分を自動で分類する。自動分類の結果、装置が分類に十分な確信を持てたものは「確定」、持てなかったものは「未確定」として処理される。
確定と未確定の判定基準
| 判定 | 意味 | その後のフロー |
|---|---|---|
| 確定 | 装置が自動分類に十分な確信を持てた | 従来通りLISへ結果送信される |
| 未確定 | 装置が自動分類に十分な確信を持てなかった | Smart Assistを経由して遠隔技師が判定 |
未確定が発生する典型的なケース
- 成分の重なり: 複数の有形成分が重なり合い、個別の識別が困難
- 異型細胞: 通常の分類カテゴリに当てはまらない形態の細胞
- 背景ノイズ: 検体の状態により画像品質が低下している場合
- 稀少成分: 学習データが少ない成分が出現した場合
エンジニアとして重要なのは、未確定データの発生は正常な動作であるという点である。未確定が発生すること自体は障害ではない。
2.2 未確定データの外部送信
送信されるデータの内容
未確定と判定された画像データは、Smart Assistクライアントを通じてAWSクラウドへ送信される。
送信データに含まれるもの:
| データ項目 | 内容 |
|---|---|
| 撮影画像 | 未確定と判定された有形成分の顕微鏡画像 |
| 検体識別情報 | 検体を一意に識別するためのID ※検体を送信する際にクラウドサーバー側で発行されるグローバルシーケンスID |
| 自動分類結果 | AUTION EYEによる一次分類の候補 |
| タイムスタンプ | 撮影日時、送信日時 |
送信データに含まれないもの（日本の場合）:
- 患者氏名
- 生年月日
- 病院名
- その他の個人を特定できる情報
米国での運用：PHIの送信
米国では、クラウド（Smart Assistサーバ）上で作業する遠隔検査技師のラボがCLIA（Clinical Laboratory Improvement Amendments）要件を満たす必要がある。このため、米国向けの設定では以下のPHI（Protected Health Information：保護対象医療情報）が送信データに含まれる。
| データ項目 | 内容 |
|---|---|
| 検体ID | バーコードID |
| 患者の生年月日 | CLIA要件として必要 |
| 患者の性別 | CLIA要件として必要 |
PHIを送信する設計のため、米国の医療機関のIT部門によるセキュリティ審査は日本よりも厳しくなる。本テキストで解説する通信設計やセキュリティ対策の知識は、こうした厳格な審査に対応するうえでも不可欠である。
送信の技術的な仕組み
2.3 遠隔検査技師による分類
遠隔技師の役割
AWSクラウド上のSmart Assistサーバに届いた未確定画像は、遠隔地にいる臨床検査技師が確認・分類する。遠隔技師が使用する画面は、AUTION EYE装置本体の手動分類画面と同じものを遠隔検査技師モードで表示したものであり、装置の前にいる技師と同等の操作環境が提供される。
分類作業の流れ
| ステップ | 内容 |
|---|---|
| 1. 画像表示 | 未確定画像が遠隔検査技師モードの分類画面に表示される |
| 2. 一次分類参照 | AUTION EYEの自動分類候補を参照 |
| 3. 技師判定 | 技師が自らの専門知識に基づき最終分類を決定 |
| 4. 結果入力 | 確定した分類結果をシステムに入力。判定不能の場合は顕微鏡検査フラグを付与 |
| 5. 結果確定 | 入力結果がSmart Assistサーバに保存される |
判定不能の場合
遠隔技師でも画像だけでは分類を確定できない場合がある。その場合は顕微鏡検査フラグがAUTION EYEに返される。このフラグを受けた検査室では、別途顕微鏡検査（検査技師が目視で分類）を実施し、その結果をLISに登録する。
エンジニアが理解すべきポイント
- 遠隔技師はAUTION EYE本体と同じ分類画面を遠隔検査技師モードで使用して作業する
- 技師の作業環境と病院の院内ネットワークは直接接続されていない
- 技師の判定結果はクラウド上に保存され、院内PCからの次回通信時に取得される
- 判定不能時の顕微鏡検査フラグは、Smart Assistの通信経路で返される（追加の通信経路は不要）
2.4 結果の返却フロー
結果はどのように院内に戻るのか
遠隔技師が確定した分類結果は、Smart Assistクライアント（院内PC）がクラウドに問い合わせることで取得される。
重要な設計原則
ここで最も重要なのは、結果の返却もクラウドからの「プッシュ」ではないという点である。
- 院内PCが定期的にクラウドへ問い合わせる（ポーリング）
- クラウドは問い合わせに対して結果を返す（レスポンス）
- 通信の開始は常に院内PC側
この設計により、クラウドから院内ネットワークへの直接的なアクセスは一切発生しない。
2.5 LISへ確定結果が送られる流れ
クラウドから取得した結果のLISへの連携
Smart Assistクライアントがクラウドから取得した確定結果は、院内ネットワーク内でLISへ送信される。
フロー全体の整理
| ステップ | 通信区間 | 通信方式 | 方向 |
|---|---|---|---|
| 1. 未確定画像送信 | 院内PC → AWS | HTTPS (インターネット) | Outbound |
| 2. 遠隔検査技師が分類 | AWS内部 | ― | ― |
| 3. 結果問い合わせ | 院内PC → AWS | HTTPS (インターネット) | Outbound |
| 4. 結果レスポンス | AWS → 院内PC | HTTPS (同一セッション) | レスポンス |
| 5. LISへ結果送信 | 院内PC → LIS | 院内プロトコル | 院内通信 |
| 6. 電子カルテへ報告 | LIS → 電子カルテ | 院内プロトコル | 院内通信 |
ステップ1〜4がSmart Assist固有の通信であり、ステップ5〜6は従来の院内フローと同じである。
2.6 双方向通信の正確な理解（セッション応答とは何か）
よくある誤解
Smart Assistの通信を説明する際、「クラウドから結果が返ってくる」という表現から、以下のような誤解が生じることがある。
誤解: 「クラウドから院内ネットワークへ接続して結果を送り込んでいる」
これは完全に誤りである。
正しい理解：セッション応答
HTTPSの通信は「リクエストとレスポンス」のペアで成り立っている。
病院IT担当者への説明での使い方
病院のセキュリティレビューでは、「外部からの通信が院内に入ってこないか」が最大の関心事となる。この質問に対して、以下のように正確に回答できることが重要である。
「Smart Assistの通信はすべて院内PCからの HTTPS Outbound通信です。クラウドからの結果返却は、院内PCが開始したHTTPSセッションに対するレスポンスであり、クラウド側から院内ネットワークへの新規接続は一切発生しません。」
この説明ができるかどうかが、病院IT担当者からの信頼を得られるかの分岐点になる。
次章では、病院IT担当者がどのような視点でSmart Assistを評価するかを理解し、セキュリティレビューに備えるための知識を身につける。