医療ITインフラ：ダウンタイムを削減する方法

医療分野におけるITインフラの障害は、ダウンタイムの割合では測れません。それは、予約のキャンセル、診療の遅延、そして業務の停止という形で現れます。この分野では、Health Level Seven International（HL7）やFast Healthcare Interoperability Resources（FHIR）といった複雑なインターフェースチェーン、厳格な規制監督、そして多くの遠隔地にはITスタッフが常駐していないなど、極めて容赦のない環境であるため、標準的な高可用性アプローチでは機能しない場合があります。

復旧計画が的を外すと、単純なハードウェアの不具合が瞬く間に深刻なビジネス上の問題へと発展しかねません。診療所側は請求期限を逃したり、給与を支払っているにもかかわらずスタッフが遊休状態になったりすることになり、患者は苛立ちを覚える遅延を経験することになります。これは信頼を損ない、患者を競合他社へと追いやる要因となり得ます。サーバーのダウンタイムが絶対に許されない診療所、診断検査室、画像診断センター、製造現場において、真のレジリエンスを構築する方法を詳しく見ていきましょう。

医療ITとは何か、そして稼働時間がなぜ重要なのか？

医療ITとは、人と機器をデータにつなぐ技術の連鎖です。臨床医が電子カルテ（EHR）を開く際、そのリクエストは、認証やDNSからストレージ、ネットワークに至るまでのトランザクションパス全体に依存しています。同様に、検査分析装置も、結果が検査情報システム（LIS）に届くまでに、ミドルウェアやインターフェースエンジンに依存しています。いずれかのリンクが機能しなくなると、サービスは技術的にはオンラインの状態を維持していても、実際には使用不能な状態になってしまう可能性があります。

クラウドホスティングではコンポーネントの実行場所は変わりますが、依存関係の連鎖は変わりません。SaaS型のEHRでもローカルなインターネットアクセスと認証が必要であり、クラウドアーカイブには医療用デジタル画像通信規格（DICOM）ゲートウェイと信頼性の高い帯域幅が必要です。モバイルアプリやポータルといった患者向けの接点は、この連鎖をさらに拡張し、データが患者記録に到達する前に認証や重複処理を必要とします。

アプリケーションは通常、HL7標準を介してこのデータを交換します。臨床インターフェースにはHL7 v2が使用され、FHIRはWeb指向のAPIを提供します。どちらもデータ交換のための構造を提供しますが、正しい患者の照合やインターフェースの正常な動作を保証するものではありません。

ダウンタイム対策の計画において、ワークロードは一般的に3つのカテゴリーに分類されます。すなわち、運用が即座に停止するもの、機能低下した手動ワークフローが許容されるもの、そしてデータをキューに入れて後で同期できるものです。この挙動によって復旧目標が決定され、どのシステムにローカルフェイルオーバーが必要で、どのシステムが標準的な復元を待てるかを判断する助けとなります。

医療ITインフラのコアコンポーネント

耐障害性のある設計は、通常稼働時および障害発生時に各インフラ層に何が必要かを理解することから始まります。環境を構築または見直す際は、障害発生という観点から各層を検討し、残りのワークフローが何に依存しているかを自問してください。

ネットワークパスは、利便性ではなく、障害ドメインごとに定義する必要があります。これらのパスをマッピングする際は、臨床アクセス、管理トラフィック、ストレージのレプリケーション、およびバックアップを分離し、同じ帯域幅を競合させないようにしてください。ネットワークをセグメント化して横方向の移動を制限し、転送中のデータを暗号化し、保護対象の健康情報（PHI）に接触するすべての操作をログに記録してください。

コンピューティング には、物理ホスト、ハイパーバイザー、およびEHR、インターフェースエンジン、通信、専門システムを実行するVMが含まれます。高可用性（HA）の規模を決定する際は、1台のホストが利用不能になったと想定し、残存するホストが優先度の高いワークロードを単独で処理できることを確認してください。

ストレージには、プライマリボリューム、同期レプリカ、アーカイブ、バックアップが含まれ、それぞれが異なる復旧目的を果たします。ストレージ設計を見直す際は、レプリケーションがバージョン管理されたコピーや不変のコピーによって補完されていることを確認してください。保存中のデータは暗号化してください。破損したデータや暗号化されたデータが別のコピーにレプリケートされた場合、ライブレプリケーションだけでは信頼できる復旧ポイントを提供できないためです。

IDおよびアクセス管理は、誰が臨床データを閲覧または変更できるかを決定します。これには、ディレクトリサービス、ロールベースの権限、サービスアカウント、管理者向けの多要素認証、および管理された緊急アクセスが含まれます。

監視および監査は、残りの運用要件を網羅します。インフラストラクチャのテレメトリは、レイテンシ、容量、障害発生経路、および再同期負荷を追跡します。監査ログは、インシデントの調査や規制上の証拠として、アクセスや変更を記録します。

図1. 医療ITインフラの中核をなす構成要素

オンプレミス、クラウド、それともハイブリッド？

導入モデルによって、考慮すべき障害領域が変わってきます。オンプレミス型インフラでは、デバイス向けのサービスをローカルに維持し、WANへの依存度を低減できます。クラウドサービスでは、ローカルハードウェアの管理負担は軽減されますが、プロバイダーの可用性、ID管理、接続性、データの保存場所などが障害モデルの一部となります。ハイブリッド設計では、通常、機器のゲートウェイをオンサイトに設置しつつ、EHR、分析、アーカイブなどを別の場所にホストします。

これらのモデルを比較する際は、各依存関係がどこに位置し、その場所への接続が失われた場合に何が起こるかを確認してください。導入場所だけでHIPAAへの準拠が確定するわけではありません。米国保健社会福祉省（HHS）のクラウドガイダンスによれば、対象機関またはビジネスアソシエイトに代わってePHIを扱うプロバイダーはビジネスアソシエイトとみなされ、準拠したビジネスアソシエイト契約（BAA）の締結が義務付けられています。したがって、選定にあたっては、復旧目標、WANの許容度、データ配置に関する規則、および運用上の責任を考慮する必要があります。

業界別の医療IT活用事例

同じ稼働時間目標であっても、ワークロードによってインフラストラクチャの設計は大きく異なります。これらの違いがインフラストラクチャの決定にどのように影響するかを確認するには、各医療環境を、リスクにさらされているワークフロー、チームが見落としがちな依存関係、およびそれに基づく設計上の決定と照らし合わせて分析することができます。

この表が示す重要な点は、サーバーの復旧はワークフローの復元の一部に過ぎないということです。実際の復旧目標は、そのサーバーに依存する業務プロセスや臨床プロセスに結びつける必要があります。

検査室の復旧テストは、LISサーバーが再起動した時点で終了するわけではありません。検査結果が正しい患者MRNに正常に紐付けられた時点で終了します。検査室の復旧シナリオをテストする際は、実際のテストデータ量に対してバッファの深さを測定してください。つまり、データの上書きが発生したり、大量の未処理データによってインターフェースエンジンが処理能力を超えたりする前に、分析装置がローカルに保持できるデータ量が何時間分あるかを確認します。

イメージングは、ストレージへの負荷が大きいワークロードです。なぜなら、単一のノードが、アクティブな検査への対応、新規検査の取り込み、フェイルオーバー後のレプリカ再構築という3つのジョブを同時に処理することが多いためです。この同時負荷により、ディスクのIOPSが飽和し、1日平均の容量数値では表れない制限が露呈する可能性があります。1日平均の数値のみを用いて環境の規模を決定すると、フェイルオーバー時の負荷を過小評価してしまう恐れがあります。

研究および製薬システムには、もう1つのコンプライアンス要件があります。それは、リカバリ時に管理された記録の状態を維持しなければならないということです。電子記録およびデータ整合性に関するFDAのガイドラインの下では、フェイルオーバーの証拠は、リカバリの純粋な速度と同様に重要です。リカバリ中に何が起こったかを実証し、その結果として生成された記録が依然として信頼できるものであることを検証できる必要があります。

分散型サイトでは、アーキテクチャはサポート性（保守性）と密接に関連しています。複数の遠隔地を管理する場合、中央チームが同じアーキテクチャに対して遠隔からトラブルシューティングを行う必要があるため、標準化が特に重要になります。クラスタと監視環境を標準化しておけば、中央チームは数十カ所の拠点を管理できますが、拠点ごとに独自のスタックがあると、遠隔での診断、メンテナンス、および予備部品の計画がはるかに困難になります。

医療ITのダウンタイムの原因は何でしょうか？

障害が発生したコンポーネントが、必ずしも一見してわかるサーバーであるとは限りません。ID管理やDNSの障害により、正常に動作している複数のアプリケーションに一度にアクセスできなくなることがあります。仮想スイッチの設定変更を誤ると、ホスト上のすべてのVMが孤立してしまう可能性があります。ストレージのレイテンシは、アプリケーションの問題のように見えることもあります。インターフェースエンジン、証明書サービス、データベース接続は、HA計画に使用されるワークロードのインベントリから除外されていることがよくあります。

メンテナンスには、それ特有の障害モードが伴います。更新によってドライバーが変更されたり、ファイアウォールルールによってインターフェースがブロックされたり、あるいはチームがアプリケーションのログインのみをテストし、その背後にあるインターフェースをテストしなかったために証明書の有効期限が切れてしまうことがあります。

HA計画を見直す際は、サーバーやVMだけでなく、これらの依存関係も障害モデルに確実に含めるようにしてください。EHRパスに変更を加えた後は、ワークフロー全体を確認してください。サイバー攻撃や拠点の喪失は、それぞれ異なる復旧上の問題を引き起こします。ランサムウェアは、同じ認証情報でアクセス可能なすべての同期コピーに損害を与える可能性があります。火災、洪水、または長時間の停電により、クラスタノードが両方同時に使用不能になることもあります。こうした事象が発生すると、対応はローカルフェイルオーバーからバックアップや災害復旧へと移行します。

• ・臨床医は、単にログイン画面にアクセスできるだけでなく、カルテを開いて指示を出せるでしょうか？
• ・インターフェースエンジンは、単に緑色の「接続済み」ステータスを表示するだけでなく、メッセージをエンドツーエンドでルーティングしていますか？
• ・ファイアウォールやネットワークアクセス制御リスト（ACL）の変更により、インターフェースやサービスアカウントが依存するポートがブロックされていませんか？
• ・チームが確認を忘れないようにしていたホップだけでなく、すべてのホップで証明書は依然として有効ですか？
• ・本番環境と同等の負荷でテストした場合、フェイルオーバーパスは依然としてRTO（復旧目標時間）内に完了しますか？

なぜバックアップだけでは不十分なのでしょうか？

ホストに障害が発生した場合、バックアップだけでは稼働中のワークロードを引き継ぐことはできません。データを正常に動作するコンピューティングリソースに復元し、アプリケーションを起動し、その依存関係を再接続する必要があります。この復旧プロセスには、臨床や本番のワークフローが許容できる時間よりも長い時間がかかる可能性があります。

HA（高可用性）とバックアップは、それぞれ異なる障害シナリオに対処するものであり、これらを互換性があるものとして扱うと、復旧計画に抜け穴が生じます。復旧戦略を見直す際には、各レイヤーが実際にどのような状況から復旧できるかを確認することが役立ちます：

同期レプリケーションは、誤って削除されたデータ、書き込みの破損、ランサムウェアによる暗号化など、現在の状態を保持します。したがって、正常なレプリカが2つあるからといって、それが2つのリカバリポイントになるわけではありません。重要なワークロードについては、本番環境の認証情報や障害ドメインから隔離された状態で、HAクラスタ自身の管理者認証情報ではアクセスできないメディア上にバックアップを作成する必要があります。

RTOには、単にデータをコピーするのに必要な時間だけでなく、サービスの完全な復旧までの時間を含めるべきです。RPOは、アプリケーションのワークフローや記録上の義務を損なうことなく、アプリケーションを復旧できる時点を反映すべきです。復旧順序も重要です。ID管理やDNSはデータベースよりも先に復旧する必要があり、その後にアプリケーションとそのインターフェースが続く場合があります。

これが、バックアップテストは成功しているように見えても、実際のサービス復旧が失敗する理由です。1台のVMを単独でテストすると、問題のないバックアップレポートが生成されるかもしれませんが、それは、アプリケーションスタック全体が復旧され、必要なRTO内にサービスに復帰できることを証明するものではありません。

2ノードのHAクラスタはどのように機能するのでしょうか？

2ノード構成では、各サーバーが演算能力とローカルストレージを提供します。同期レプリケーションにより、ノード間でデータコピーが一致した状態が維持され、仮想化クラスタに対して共有ストレージとして提供されます。1つのホストに障害が発生した場合、そのVMは、利用可能なストレージコピーを使用して、稼働中のホスト上で再起動します。

この設計において、レプリケーションネットワークは極めて重要な要素となります。同期書き込みでは、両方のコピーが書き込みをコミットしてから初めて承認されるため、ネットワークへの依存度が高まります。経験則として、クラスタノード間の同期レプリケーションには、往復遅延が1桁台前半のミリ秒（通常は2～3ミリ秒程度、あるいはそれ以下）であることが求められます。遅延がこの範囲を超えると、通常稼働時を含め、すべてのVMにおける書き込み遅延も増加する可能性があります。

レプリケーションリンクは、この低遅延を一貫して維持するとともに、本番トラフィックやノード復旧後の再同期に必要な十分な帯域幅を確保する必要があります。これらのリンクの容量を決定する際は、通常のワークロードトラフィックに加え、状態の再構築も考慮に入れてください。

クォーラムロジックは、通信が途絶えた後も、両方のノードが矛盾するコピーを提供することを防ぎます。具体的なメカニズムとしては、ハートビートチャネル、ウィットネス、またはノード過半数ロジックなどが使用されます。ウィットネスの配置場所は、多くの設計で想定されている以上に重要です。もしウィットネスを、2つのノードのいずれかと同じラック、同じ電源回路、または同じ物理ホストに配置した場合、ブレーカーのトリップやラックスイッチの故障といった単一の事象によって、ノードとウィットネスが同時に機能停止する可能性があります。

その結果、生存しているノードもクォーラムを失うことになり、フェイルオーバーすべきだったクラスタが停止し、本来は正常なハードウェアが遊休状態になってしまう可能性があります。2ノードクラスタを設計する際は、ウィットネスの配置をフェイルドメイン設計の一部として扱う必要があります。

容量は、正常時ではなく障害時の状態に基づいて設定されます。1つのノードが優先度の高いVMを実行しつつ、アプリケーションの応答目標を達成できなければなりません。技術的には成功したフェイルオーバーであっても、画像アーカイブ・通信システム（PACS）の検索やLISトランザクションの処理速度が著しく低下してしまう場合、稼働時間ダッシュボードが何を報告していようとも、運用要件は満たされていないことになります。

障害のメカニズム：クォーラム、ストレージ、およびネットワーク設計

ネットワークパーティションとスプリットブレイン

2ノードクラスタでは、ハートビートやレプリケーションパスの障害により、両方のサーバーの電源は入ったままでも、互いに認識できなくなる可能性があります。両側が同じワークロードの処理を継続すると、ストレージの状態が乖離する恐れがあります。クォーラムは、過半数の票を持つパーティションのみがクラスタ化されたワークロードをオンラインに維持できるようにすることで、この結果を防止します。

ウィットネスが保持するのは投票権であり、臨床データではない。そのため、その配置はネットワークおよび電源設計上の決定事項となる。iSCSI、SMB Direct、RDMAはストレージトラフィックを伝送するが、いずれもクォーラムを決定するものではない。両方のパーティションを強制的にオンラインにすると、保護機能が無効化され、書き込みの競合が発生する可能性がある。

ネットワークを計画する際は、クォーラムパスとストレージパスを別々に考慮すること。高性能なストレージネットワークであっても、不適切なクォーラム設計を補うことはできず、正常なウィットネスであっても、過負荷のレプリケーションリンクを修復することはできません。

PACS：アーカイブサイズ、バーストトラフィック、およびキャッシュ

DICOMは構造化されていますが、PACSストレージの挙動は、従来のトランザクション型データベースというよりは、大容量オブジェクトのワークロードに近いです。日々のデータ取得は予測可能かもしれませんが、一括移行、アーカイブの復元、またはノードの再同期は、ほとんどの場合予測不可能であり、はるかに大規模な持続的なデータストリームを引き起こす可能性があります。

同期レプリケーションでは、フォアグラウンドでの書き込みは、両方のコピーがコミットして初めて承認されます。PACSのインポートがEHRやLISのワークロードとディスクやリンクを共有している場合、大規模な転送によりクラスタ全体のレイテンシが上昇する可能性があります。ライトバックキャッシュは短時間のバーストを吸収できますが、キャッシュが満杯になると、スループットはより遅いレプリカまたはネットワークパスの速度まで低下します。

このため、容量テストでは、各ワークロードを個別にベンチマークするのではなく、臨床読み取り、ピーク時の画像取り込み、および完全な再同期を組み合わせて実施する必要があります。最近のものや頻繁に参照される検査データは、アクティブなHA階層に保持してください。保存期間や検索要件が許す場合は、古いDICOMオブジェクトをPACSまたはVNAがサポートするアーカイブ階層に移動してください。

アーカイブの移行を計画する際は、一括転送の速度を調整し、ソースコピーを削除する前にアーカイブが検索可能であることを確認してください。これにより、実用的な復旧および可用性の確認が可能になります。

ストレージおよびレプリケーションネットワーク

物理パス、専用VLAN、およびQoSを使用して、クライアント、管理、クラスタ、ストレージ、およびバックアップのトラフィックを分離してください。iSCSIの場合は、MPIO対応の専用アダプタまたはHBAを使用してください。iSCSIがルータを経由する場合は、パス全体にわたるレイテンシ、パケットロス、MTU、およびフェイルオーバーを徹底的にテストしてください。

負荷の高い 2 ノードのストレージクラスタの場合、10GbE が実用的な出発点となりますが、PACS による取り込み、VM による書き込み、再同期トラフィックによって低速回線が飽和状態になると、25GbE が適切になります。リンクの容量は、日中の平均利用率ではなく、障害時や再構築時の状態を想定して決定してください。

ジャンボフレームを使用するには、すべての NIC およびスイッチで MTU を一致させる必要があります。SMB DirectにはRDMA対応のアダプタとSMBマルチチャネルが必要であり、RoCEには適切なDCBおよびPFC設定が必要です。常にアクティブレプリケーションを実行して負荷テストを行い、レイテンシ、再送信、パケットドロップ、キュー深度を監視してください。

重要なのは、これらの条件を組み合わせてテストすることです。ネットワークは、合成帯域幅テストでは良好なパフォーマンスを示しても、VMの書き込み、PACSの取り込み、ストレージの再同期が同じリソースを競合すると、処理に支障をきたす可能性があります。

外部SAN対2ノードHCI

医療ワークロードにおけるローカルHAストレージについて、組織は通常、専用のSANアレイと、別途のストレージアレイを使用せずにローカルサーバーディスク間で同期レプリケーションを行う方法のどちらかを選択します。

SANは、専任のストレージ管理者がいる大規模なデータセンターには適していますが、分散した診療所ネットワーク全体で運用するのはより困難になります。外部アレイを導入する各拠点では、専任のITスタッフがいない可能性のある場所に、専用のハードウェア、ファームウェア、サポート契約、および追加の障害モードが持ち込まれます。

2ノードHCIは、この複雑さを解消します。各サーバーが独自のストレージを搭載し、ペアとなるサーバーと同期的にレプリケーションを行い、別途のSANアプライアンスやストレージチームを必要とせずに、ハイパーバイザーに共有ストレージを提供します。

StarWindでは、このモデルを2つの方法で実装しています。Virtual SAN (VSAN)は、社内に管理スキルを持つチーム向けに、既存のサーバーストレージ上で動作します。

結局のところ、分散型クリニックにおける選択は、運用上のオーバーヘッドに帰着します。サーバーを再利用すれば初期費用は抑えられますが、後になって複数の拠点にまたがる異なるハードウェアやソフトウェアスタックのトラブルシューティングを行う必要が生じ、エンジニアリングに多くの時間を要する可能性があります。単一ベンダーによるエスカレーション体制を備えた標準化されたハードウェアは、数年単位の導入期間を通じて運用やサポートが容易になる可能性があります。

選択肢を比較する際は、初期のハードウェアコストだけにとどまらず、さらに広い視野で検討してください。午前2時にコンポーネントが故障した際のトラブルシューティングを誰が担当するか、交換部品が遠隔地にどれほど迅速に届くか、そして中央のITチームがすべての拠点で同じ復旧手順を適用できるかどうかを考慮する必要があります。

ストレージのアプローチにかかわらず、保護の対象となるのはクラスタ上の仮想化ワークロードです。WANサービス、SaaSの可用性、医療機器、およびサイトレベルの災害復旧は、それぞれ別個の設計上の考慮事項となります。

医療ITインフラのコストを管理する方法

コスト管理は、すべてのアプリケーションに同じ可用性レベルを購入するのではなく、ワークロードに合わせて保護策を調整することから始まります。高可用性（HA）は、復旧を待つ運用コストが冗長インフラのコストを上回る場合に導入すべきです。優先度の低いシステムには、標準的なバックアップと復旧を利用できます。

既存のインフラを評価する際は、まず障害発生時の要件を確認してください。既存のサーバーは、障害発生時の負荷を処理でき、かつ統合作業のコストを正当化できるだけの十分なサポート残存期間がある場合にのみ、経済的です。クラウドの見積もりには、単にコンピューティングの項目だけでなく、冗長な接続、データ転送、バックアップ、監視、セキュリティツール、およびサポートも含める必要があります。

遠隔地をまたがる環境では、再現性のある構成と一元的な監視により、単発のハードウェア購入におけるわずかな割引よりも、長期的にはより多くのコスト削減が可能になります。複数の拠点を管理している場合、標準化により、チームが異なる構成のトラブルシューティングや交換部品の計画に費やす時間も削減されます。

医療分野のセキュリティおよび規制要件

規制では、2ノードのクラスターや特定のストレージ製品を義務付けてはいません。規制対象の記録を保存または処理するシステムに関する管理措置や証拠の在り方を規定しています。したがって、インフラストラクチャの設計では、HAプラットフォーム自体をコンプライアンスの証明とみなすことなく、必要なセキュリティおよびコンプライアンス管理措置をサポートする必要があります。

対象機関および業務提携先については、現行のHIPAAセキュリティ規則により、電子保護医療情報の機密性、完全性、および可用性を確保するための保護措置が求められています。その緊急時対応計画に関する規定には、バックアップ、災害復旧、緊急モードでの運用、および計画のテストが含まれます。HAは可用性の要素をサポートできますが、コンプライアンスの記録は、より広範なリスクおよび管理プログラムに基づいて作成されます。

CMS緊急時対応規則は、指定されたメディケアおよびメディケイド参加プロバイダーおよびサプライヤーの種類にのみ適用され、要件はカテゴリーによって異なります。CLIAプログラムは、正確で信頼性が高く、適時に行われるヒトの臨床検査に焦点を当てています。FDA規制の対象となる研究および製造については、関与するシステムや記録に応じて、パート11、CGMP、バリデーション、およびデータ完全性の要件が適用される場合があります。

EU内で事業を行う場合、GDPRが個人データの処理を規定しており、NIS2は適用範囲内の医療機関に対してサイバーセキュリティおよびインシデント報告の義務を課す可能性があります。医療機器に該当するソフトウェアはEU MDRの対象となり、IEC 62304は医療機器ソフトウェアのライフサイクルプロセスに関する規格を定めています。これらの要件はすべての医療アプリケーションやプロバイダーに適用されるわけではないため、適用範囲と義務についてはケースバイケースで確認する必要があります。

暗号化キーとバックアップの分離

セキュリティ計画は、キー管理レベルにまで及ぶ必要があります。アーキテクチャ記録では、保存時の暗号化と転送中の暗号化を明確に区別する必要があります。BitLockerで保護されたボリュームを使用するWindowsクラスタの場合、鍵保護機能はボリューム層およびクラスタ層に配置され、復旧用データは2ノードの障害ドメインの外でエスクローされる必要があります。レプリケーションにTLSまたはIPsecを使用する場合、接続にはセッション鍵が存在しますが、長期有効な認証情報は、保護されたホストのキーストア、またはプラットフォームによって選択された外部のKMSやHSMに保持されます。

設計書には、これらの鍵や認証情報の保存場所、管理担当者、ローテーションおよび失効処理の方法、および鍵サービスが利用不能になった場合のフェイルオーバー時の対応を明記する必要があります。NIST SP 800-57は鍵管理のフレームワークを提供していますが、具体的な実装は製品やハイパーバイザーごとに異なります。

バックアップの隔離も同様に重要です。2ノードのクラスタでは、エアギャップや不変のバックアップは提供されません。両方のレプリカはオンライン状態で、同じ承認済み書き込みを受け取るため、ランサムウェア、削除、または破損の影響が両方に及ぶ可能性があります。サイバーリカバリ用のコピーには、独立したセキュリティおよび障害ドメイン、個別の認証情報、および不変の保存方法またはオフラインメディアが必要です。

CISAはオフラインバックアップを推奨しており、NISTはレプリケーションと不変性、および特定時点での復旧を区別しています。復旧テストを行う際は、隔離されたコピーが単一のファイルだけでなく、アプリケーションのワークフロー全体を復元できることを確認してください。

インフラストラクチャの見直しでは、各技術的制御を証拠（承認済みのアーキテクチャ、アクセスルール、変更記録、バックアップ結果、フェイルオーバーテスト、復元テスト、および責任者）と結びつける必要があります。製品の冗長性はこの取り組みを支援しますが、関連するプロセスや証拠は依然として維持される必要があります。

結論

医療分野におけるダウンタイムへの備えとは、ワークロードが診療へのアクセス、検査結果、あるいは画像診断のキューのいずれであるかにかかわらず、個別のサーバーではなくワークフロー全体を見据えることを意味します。2ノードクラスターは、障害発生時のホストが再構築を待てない場合、単一ノードで運用負荷を処理できる場合、およびサイト復旧が別途管理されている場合に適しています。

環境を計画する際は、保護範囲を明確に定義してください。オンサイトのハードウェアやストレージの障害に対してはローカルHAを活用し、HAではカバーできない障害シナリオについては、バックアップ、ネットワークの耐障害性、および文書化された復旧手順で対処します。インフラストラクチャに負荷がかかっている状況でも、ワークフローを継続させ、復旧プロセスが確実に機能するようにする必要があります。

よくある質問(FAQ):

臨床環境では、フェイルオーバーをどのくらいの頻度でテストすべきですか？

インフラストラクチャやアプリケーションに重要な変更があった後は必ずテストを行い、リスクに基づいた定期的なスケジュールでもテストを実施してください。テストは、単に仮想マシンが再起動しただけでは完了したとは言えず、臨床医やスタッフが影響を受けたワークフローを無事に完了できて初めて完了したものとみなされます。

医療復旧テストには誰が参加すべきですか？

少なくとも、IT部門、アプリケーションの所有者、および日常的にシステムに依存している臨床、検査、製造部門のスタッフが参加する必要があります。規制対象の記録やサイバー復旧シナリオがテストに含まれる場合は、コンプライアンスチームやセキュリティチームも参加させてください。

医療ダウンタイムのランブックには何を記載すべきですか？

誰が停止を宣言するか、障害発生中に臨床および運用ワークフローをどのように継続するか、重要なサービスを復旧させる正確な順序、およびシステムが復旧した後にキューに蓄積されたデータや紙の記録をどのように照合するかについて、明確な手順を記載してください。

また、ランブックには、各ステップの責任者や、復旧が定義されたRTO（復旧目標時間）を超過した場合のエスカレーション手順も明記する必要があります。通常その環境を運用していない人でも、インシデント発生時に手順に従えるよう、十分に具体的に記述してください。