第11章 導入実務プロセス
Smart Assist導入の対象機器: AUTION EYE AI-4510
11.1 導入前ヒアリング
ヒアリングの目的
Smart Assistの導入にあたり、病院のネットワーク環境を正確に把握することが最初のステップである。ヒアリング不足は、導入時のトラブルやセキュリティレビューでの手戻りに直結する。
ヒアリング項目一覧
| カテゴリ | 確認項目 | 確認理由 |
|---|---|---|
| ネットワーク構成 | 院内ネットワーク構成図の有無 | 全体像の把握 |
| Smart Assist PCの設置セグメント | FWルールの設計に必要 | |
| Smart Assist PCのIPアドレス(固定/DHCP) | 送信元の特定 | |
| デフォルトゲートウェイ | 経路の把握 | |
| DNS | 院内DNSサーバの有無とIPアドレス | DNS解決経路の把握 |
| 外部FQDN解決の可否 | Smart Assist宛先の名前解決 | |
| ファイアウォール | FW機器の種別・メーカー | FQDN許可対応の確認 |
| 現在の外部通信許可ポリシー | 申請方法の把握 | |
| 変更申請の手続きとリードタイム | スケジュール計画 | |
| プロキシ | プロキシサーバの有無 | 通信経路の設計 |
| プロキシのアドレスとポート | PC側の設定 | |
| 認証の有無と方式 | 認証設定の要否 | |
| SSLインスペクションの有無 | 証明書問題の事前把握 | |
| セキュリティ | セキュリティレビューの要否 | 対応準備 |
| レビューのプロセスと所要期間 | スケジュール計画 | |
| 過去の外部接続承認実績 | 承認の可能性の見極め |
ヒアリング項目はたくさんありますが、これだけは絶対に聞き漏らさないでという3つがあります:
- プロキシの有無と認証方式 ― 導入トラブルの原因No.1。「プロキシはありますか?」だけでなく「URLフィルタリング製品は?」とも聞くこと(透過型プロキシ対策)
- SSLインスペクションの有無 ― これを見落とすと、導入当日に「証明書エラーで接続できません」と大騒ぎになる。ヒアリング時に
curl -vで証明書のissuerを確認しておくのがベスト - FW変更申請のリードタイム ― 「申請から反映まで2週間かかります」はザラ。大学病院では1〜2か月かかることも。これを把握していないとスケジュールが崩壊する
ヒアリングシート(テンプレート)
Smart Assist 導入前ヒアリングシート
| 基本情報 | |
|---|---|
| 病院名 | ____________________ |
| 担当者 | ____________________ |
| ヒアリング日 | YYYY-MM-DD |
ネットワーク構成
- 構成図の提供: 可 / 不可
- Smart Assist PC設置場所: ________________
- IPアドレス: ________ / サブネット: ________
- デフォルトGW: ________
DNS
- 院内DNSサーバ: あり (IP: ________) / なし
- 外部FQDN解決: 可 / 不可 / 不明
ファイアウォール
- FW機種: ________________
- FQDN許可対応: 可 / 不可 / 不明
- 変更申請リードタイム: 約____日
プロキシ
- プロキシサーバ: あり (________:____) / なし
- 認証: あり (方式: ________) / なし
- SSLインスペクション: あり / なし / 不明
セキュリティレビュー
- レビュー要否: 必要 / 不要
- 所要期間: 約____日〜____日
11.2 セキュリティレビュー対応
セキュリティレビューの流れ
多くの病院では、外部接続を伴うシステム導入時にセキュリティレビューが必要となる。日本では情報セキュリティ委員会への諮問、米国ではベンダーリスクアセスメント(SIG/CAIQ/HECVAT等の質問票)やHIPAA Security Risk Assessment、EUではGDPR第35条に基づくDPIA(Data Protection Impact Assessment)がこれに該当する。
提出すべき資料
| 資料 | 内容 |
|---|---|
| システム概要書 | Smart Assistの目的、業務フロー |
| 通信フロー図 | 通信経路、プロトコル、ポート番号 |
| セキュリティ設計書 | 暗号化方式、認証方式、アクセス制御 |
| データフロー図 | 送信データの内容(含む/含まないの明示) |
| ファイアウォール許可申請書 | 送信元、宛先、ポート、方向 |
| 規制準拠状況 | 各国の医療情報規制への対応状況(日本: 3省2ガイドライン、米国: HIPAA、EU: GDPR) |
| 障害時影響分析 | Smart Assist停止時の業務影響 |
想定質問への事前準備
第3章 3.5で挙げた質問に対する回答を、提出資料と整合する形で事前に準備しておく。回答に矛盾があると信頼を損なう。
11.3 ネットワーク構成確認
現地確認で行うこと
ヒアリング情報に基づき、現地で実際のネットワーク構成を確認する。
確認チェックリスト
| # | 確認項目 | 確認方法 | 結果 |
|---|---|---|---|
| 1 | Smart Assist PCのIPアドレス | ipconfig | ... |
| 2 | サブネットマスク | ipconfig | ... |
| 3 | デフォルトゲートウェイ | ipconfig | ... |
| 4 | DNSサーバ | ipconfig /all | ... |
| 5 | GWへの疎通 | ping GW_IP | OK / NG |
| 6 | DNSサーバへの疎通 | ping DNS_IP | OK / NG |
| 7 | 外部FQDN解決 | nslookup smartassist.example.com | OK / NG |
| 8 | 外部疎通(ICMP) | ping 8.8.8.8 | OK / NG |
| 9 | ポート443疎通 | Test-NetConnection -Port 443 | OK / NG |
| 10 | HTTPS接続テスト | curl -v https://... | OK / NG |
確認結果の記録
すべての確認結果をスクリーンショットまたはテキストログとして記録する。障害発生時の比較基準(ベースライン)として使用する。
11.4 テスト通信手順
テスト通信の目的
本番データを流す前に、ネットワーク経路が正しく構成されていることを確認する。
テスト手順
| ステップ | 内容 | 確認ポイント |
|---|---|---|
| 1 | DNS解決テスト | nslookupで宛先FQDNが解決できること |
| 2 | ポート疎通テスト | 443/tcpポートへの接続が成功すること |
| 3 | HTTPS接続テスト | curlでHTTPS接続が確立できること |
| 4 | TLS証明書確認 | 証明書の発行者と有効期限が正しいこと |
| 5 | ヘルスチェックAPI | Smart Assistのヘルスチェックエンドポイントに接続 |
| 6 | テストデータ送信 | テスト画像をアップロードし、受付確認を取得 |
| 7 | テスト結果取得 | テストデータの分類結果が返却されること |
| 8 | LIS連携テスト | 結果がLISに正常に送信されること |
テスト通信が成功したら、必ずスクリーンショットやログを保存してください。「テスト時は繋がってました」と口で言っても、後で問題が起きたときに証拠がないと困ります。
最低限保存すべきもの:
curl -vの全出力(TLSバージョン、証明書情報、HTTPステータスが全部入っている)nslookupの結果(DNS解決のベースライン)ipconfig /allの結果(ネットワーク設定のベースライン)- テスト実施日時のメモ
これらを「導入時テスト結果」としてフォルダに保存しておくと、障害時に「テスト時と何が変わったか」を比較できて、切り分けが格段に速くなります。
テスト成功基準
| 基準 | 内容 |
|---|---|
| 必須 | ステップ1〜7がすべて成功すること |
| 必須 | ステップ8でLISが結果を正常に受信すること |
| 推奨 | 通信の応答時間が許容範囲内であること |
| 推奨 | 複数回のテストで結果が安定していること |
11.5 本番切替
切替前の最終確認
| 確認項目 | 内容 |
|---|---|
| テスト通信の成功 | すべてのテスト項目が合格していること |
| セキュリティレビューの承認 | 病院からの正式な承認を得ていること |
| 関係者への連絡 | 検査部門、IT部門への切替日時の通知 |
| 切り戻し手順の確認 | 問題発生時に元の状態に戻す手順を準備 |
切替手順
| ステップ | 内容 | 担当 |
|---|---|---|
| 1 | 検査業務の一時停止(必要に応じて) | 検査部門 |
| 2 | Smart Assistクライアントの設定を本番に変更 | エンジニア |
| 3 | 本番環境への接続テスト | エンジニア |
| 4 | テストデータによる動作確認 | エンジニア + 検査技師 |
| 5 | 実検体による動作確認 | 検査技師 |
| 6 | LISへの結果連携確認 | 検査技師 |
| 7 | 本番稼働開始 | 全員 |
切り戻し基準
以下のいずれかに該当する場合は、本番切替を中断し元の状態に戻す。
- 本番環境への接続テストが失敗する
- テストデータの送信・結果取得に失敗する
- LISへの結果連携が正常に動作しない
- 検査部門から業務影響の報告がある
11.6 障害時の一次対応フロー
障害発生時の初動
「昨日まで動いてたのに突然通信できなくなった」という障害報告を受けたら、真っ先に確認すべきことがあります。「最近、FWやプロキシの設定変更はありましたか?」
実は突然の通信断の原因として一番多いのが、病院IT部門によるFW/プロキシの設定変更(メンテナンスやポリシー更新)です。特に:
- FWファームウェアのアップデートでFQDN許可ルールがリセットされた
- URLフィルタリングのカテゴリが変更されてSmart Assistの宛先がブロックされた
- SSLインスペクションポリシーが変更されて除外設定が消えた
トラブルシューティングを始める前に、まずこの一言を聞くだけで、原因特定までの時間が大幅に短縮できます。
エスカレーション先一覧(テンプレート)
| カテゴリ | 担当 | 連絡先 | 対応時間 |
|---|---|---|---|
| 院内ネットワーク・FW・プロキシ | 病院 情報システム部 / IT Department [担当者名] | [電話番号] | [対応時間帯] |
| Smart Assist クラウド側 | [運用組織名] 運用チーム / Operations Team | [電話番号] / support@example.com | 24時間365日 / 24x7 |
| 検査部門(業務影響の報告) | 検査部 / Laboratory Department [検査責任者名] | [内線/電話番号] | ― |
| 規制・コンプライアンス(必要に応じて) | 日本: 個人情報管理責任者 / 米国: HIPAA Privacy Officer・Security Officer / EU: DPO | [該当する場合に記載] | ― |
障害報告書の記載事項
| 項目 | 内容 |
|---|---|
| 発生日時 | 障害が発生した日時(最初に認識した時刻) |
| 復旧日時 | 障害が解消した日時 |
| 影響範囲 | 影響を受けた業務、影響を受けなかった業務 |
| 症状 | 具体的なエラーメッセージ、動作の説明 |
| 原因 | 切り分けの結果判明した原因 |
| 対応内容 | 実施した復旧作業の内容 |
| 再発防止策 | 同じ障害を防ぐための対策 |
11.7 資料の読み方:初回攻略プレゼン資料(First Attack)
資料の概要
初回攻略プレゼン資料(First Attack)は、Smart Assistの新規顧客への初回提案に使用する営業・導入資料である。この資料を理解することで、提案段階で病院側に説明すべきサービスの全体像、料金体系、導入スケジュールを把握できる。
なぜ技術者がこの資料を理解する必要があるか? 営業担当者の初回提案後にエンジニアが導入作業を担当するため、「営業が何を約束したか」を正確に把握しておくことが、導入時のトラブル防止に直結する。
料金プラン
Smart Assistには検体処理量に応じた2つの基本プランと、追加料金オプションがある。
注: 以下の料金プランは日本向けのプランである。米国版は別途料金体系が設定されている。
| プラン | 月額料金(税別) | 月間処理検体数 | 対象規模 |
|---|---|---|---|
| Assist300 | ¥100,000 | 300検体/月 | 中小規模施設 |
| Assist1000 | ¥200,000 | 1,000検体/月 | 大規模施設 |
| オプション | 料金 | 内容 |
|---|---|---|
| Charge100 | ¥40,000/月 | 追加100検体分の処理枠 |
導入スケジュールの目安
初回攻略資料では、提案から稼働開始までの典型的なスケジュールとして以下のフェーズが示されている。
| フェーズ | 期間目安 | 内容 |
|---|---|---|
| Phase A: 準備期間 | 約3〜4か月 | 契約手続き、セキュリティレビュー申請、ネットワーク環境のヒアリング・調査 |
| Phase B: 導入・検証 | 約3〜4か月 | 機器設置、ネットワーク設定、テスト通信、本番切替、検証運用 |
| 合計 | 約6〜8か月 | 提案から本稼働まで |
注意: セキュリティレビューの期間は病院によって大きく異なる。大学病院や大規模病院では情報セキュリティ委員会の審議サイクルに合わせて数か月かかることもある(第12章ケーススタディ参照)。
提案時に把握すべき情報
初回提案の段階で、以下の情報を営業担当者とともに確認・収集しておくと、その後の導入がスムーズになる。
| カテゴリ | 確認項目 | 導入作業への影響 |
|---|---|---|
| 施設規模 | 月間検体処理数 | プラン選定(Assist300 or Assist1000) |
| ネットワーク | インターネット接続の有無 | 接続オプションの選定(第6章参照) |
| セキュリティ | セキュリティレビューの要否と期間 | スケジュール全体への影響 |
| LIS連携 | LISメーカー・機種・接続方式 | 連携設定の事前準備 |
| 設置場所 | 検査室のレイアウト、LAN環境 | 配線計画、IP設計 |
| IT部門 | IT担当者の有無・連絡先 | ヒアリング・申請の窓口 |
営業担当者との情報共有ポイント
エンジニアとして、営業担当者と以下の点を事前に確認しておくことが重要である。
- 契約プラン: どのプランで提案したか(Assist300/Assist1000)
- 約束した稼働開始時期: セキュリティレビュー期間を考慮した現実的なスケジュールか
- 特殊条件の有無: VPN要件、プロキシ環境、SSLインスペクション等の情報
- 顧客の懸念事項: セキュリティ面で特に気にしている点(データの所在、PHI、規制準拠等)
次章では、実際に発生した障害や導入時の困難を題材としたケーススタディを通じて、学んだ知識を実践に結びつける。