医療機関向けバックアップソフトウェア：臨床ITの評価基準

医療機関向けのバックアップソフトウェアの評価は、一般的な企業向けバックアップの評価とは異なり、その違いを生み出す基準は独特です。

• プラットフォームは、バックアップチェーン全体を再構築することなく、特定のトランザクション時点の単一の電子カルテデータベースを復元できますか？
• 単一のコンソールから、サイト間でカバー範囲の抜け漏れなく、環境内で実行されるすべてのワークロードタイプを網羅できますか？
• 画像ライブラリが年間20～40％のペースで成長しても、価格設定モデルは予測可能なまま維持されるのだろうか？

この記事では、これらの疑問点に基づいて評価フレームワークを構築します。自己管理型ソフトウェアではなくBaaSを評価するチームにとって、自己管理型バックアップの代替手段としてBaaSを評価することは、マネージドサービスフレームワーク全体を網羅するものです。

Zmanda Proがこの評価フレームワークに対してどのようなパフォーマンスを発揮するかをご覧ください。

医療分野における一般的なバックアップ評価基準がなぜ失敗するのか

医療機関向けバックアップソフトウェアの評価フレームワークとして、一般的な企業向けバックアップチェックリストが不十分な理由は、以下の3つの具体的な不一致によって説明できます。

1. 業務量の多様性 一般的な評価では、仕様が不十分です。「VMwareをサポートする」ことは、「VMware仮想マシンからマシン全体を削除することなく、きめ細かなファイルレベルのリカバリをサポートする」こととは異なります。一般的な基準では、ワークロードのサポート状況を確認する必要があります。医療現場向けのバックアップソリューションでは、実際に環境で実行されるワークロードの種類ごとに、リカバリの粒度を確認する必要があります。
2. 回復精度 これは、一般的なフレームワークにおける標準的な評価基準ではありません。ほとんどの企業環境では、サーバーを最後のバックアップ状態に復元すれば十分です。しかし、電子カルテデータベースを最後のバックアップ状態に復元すると、8時間分の患者記録の更新が失われる可能性があります。トランザクションレベルでの特定時点への復元は、医療用バックアップソフトウェアに特有の要件であり、一般的な評価フレームワークには含まれていません。
3. 価格設定モデルへの影響 臨床環境では、時間の経過とともにコストが増大します。現在のデータ量では競争力があるように見えるGBあたりの価格設定も、画像ライブラリや電子カルテの記録が増加するにつれて持続不可能になる可能性があります。一般的な評価では現在のコストを比較しますが、医療分野の評価では、医療分野特有の成長率を用いて、3年後および5年後のデータ量におけるコストを予測する必要があります。

医療バックアップソフトウェアにとって実際に重要な評価基準

医療現場特有の6つの基準によって、医療機関向けバックアップソフトウェアが最も重要な場面で機能するか、あるいは実際の復旧作業中に欠陥が明らかになるかが判断されます。各基準には、確認すべき点、優れた対応とはどのようなものか、そしてどのような場合にそのプラットフォームを検討対象から外すべきかが示されています。

1. 業務範囲の広さではなく、深さが重要

評価のポイントは、どのワークロードタイプが機能マトリックスに掲載されているかではなく、実際に環境で実行される各ワークロードタイプに対する復旧機能の深さです。医療機関向けのバックアップソフトウェアは、デモの前に次の4つの具体的な質問に答える必要があります。

EHRデータベース（SQL Server、Oracleなど）の場合、プラットフォームはトランザクションログをサポートするエージェントベースのバックアップに対応しており、特定のトランザクションへのポイントインタイムリカバリが可能でしょうか？それとも、マシンの状態はキャプチャするもののデータベースのトランザクションの粒度は捉えないVMスナップショットに依存しているのでしょうか？この違いは臨床業務において非常に重要であり、現代の病院がバックアップアーキテクチャをどのように構築しているかについて、より詳細に解説されています。

PACSサーバーの場合：プラットフォームは画像データと、それをインデックス化するPACSアプリケーションデータベースの両方をバックアップしますか？インデックスなしで画像ファイルをバックアップするプラットフォームでは、インデックスが再構築されるまで個々の検査データを取得できないという復元シナリオが発生します。

VMwareおよびHyper-Vの場合：プラットフォームは、マシン全体の復元を必要とせずに、VMからのファイルレベルのリカバリをサポートしていますか？ Microsoft 365の場合：サポート対象には、メールボックスだけでなく、Exchange Online、SharePoint、OneDrive、Teamsも含まれますか？

良好な回答：上記すべてに「はい」と回答し、評価時にドキュメントとライブデモを提供した場合。不適格な回答：データベースのバックアップにVMスナップショットを使用している、ファイルレベルのVM復旧を実証できない、またはMicrosoft 365の対応範囲がメールボックスのみに限定されている場合。

2. 復旧精度：評価中にテストを実施し、展開後にテストしない。

医療機関向けバックアップソリューションのベンダーであれば、プレゼンテーションで復旧機能を説明することはできます。評価テストとは、デモ環境で実際のデータを使ってそれらの機能が正しく動作するかどうかです。評価対象となるすべてのプラットフォームには、以下の3つの具体的な復旧テストが必須です。

特定時点データベース復旧：テストデータベースを、最後のバックアップ状態ではなく、特定のトランザクションのタイムスタンプに復元します。復元がワークロード層に定義されたRTO（目標復旧時間）内に完了し、復元された状態が指定されたトランザクションに対して正確であることを確認します。

ファイルレベルのVMリカバリ： VMバックアップから単一ファイルを復元し、マシン全体を復元することはありません。手動操作やサポートの支援なしに、プラットフォームの標準インターフェース内でプロセスが正常に動作することを確認します。

PACSスタディの復元： PACSライブラリ全体を復元することなく、バックアップセットから特定の画像スタディを復元します。PACSアプリケーションデータベースのインデックスが破損していないこと、および復元後にスタディがすぐに取得できることを確認します。

評価時に代表的なデータを用いてこれら3つの復旧機能を実証できないプラットフォームは、実際のインシデント発生時に顕在化する精度上の欠陥を抱えている。

3. 単一コンソールからの複数拠点管理

評価のポイントは、プラットフォームが単一のコンソールからすべてのサイトのバックアップを真に管理できるかどうか、あるいは複数サイトをカバーするには個別のツールインスタンス、個別のログイン、またはサイトレベルの管理が必要になるかどうかです。具体的な質問は次の3つです。

バックアップポリシーは、サイトレベルの設定なしに、中央で定義してすべてのサイトにプッシュ配信できますか？サテライトクリニックでバックアップジョブが失敗した場合、クリニックのローカル管理者が報告する必要なく、中央ダッシュボードに表示されるアラートを生成できますか？オンサイトのIT担当者がいなくても、中央コンソールから任意のサイトの復旧を開始できますか？

良好な回答：ポリシーのプッシュ、中央アラート、リモートリカバリの開始のデモを含め、3つの質問すべてに「はい」と回答した場合。不適格な回答：サイトごとにコンソールインスタンスが別々になっている、サイトレベルでポリシー管理が行われている、または中央監視にエスカレーションされる前にサイトレベルでの確認が必要なアラートがある場合。

4. アーキテクチャ要件に合わせた柔軟な導入

安全な医療データバックアップには、ベンダーが推奨するアーキテクチャではなく、コンプライアンス要件に適合する導入モデルが必要です。ベンダー管理のクラウドモデルを強制する医療向けバックアップソフトウェアは、エアギャップの義務付けや、クラウドストレージに関するEHRベンダーとの契約上の制限を満たさない可能性があります。医療分野特有の3つの導入要件は以下のとおりです。

エアギャップ環境下での導入：エアギャップが義務付けられている組織や、クラウドストレージに関するEHRベンダーとの契約制限がある組織でも、インターネット接続なしでプラットフォームを運用できますか？エアギャップ環境下での導入は標準オプションですか、それとも個別のニーズに対応する必要がありますか？

ハイブリッド展開：プラットフォームは、単一のコンソールからオンプレミスとクラウドストレージの保存先を管理し、バックアップデータをローカルNAS、クラウドストレージ、オフラインの保存先に同時に送信できますか？これに影響を与えるアーキテクチャ上の決定事項については、「医療分野におけるクラウドおよびハイブリッド展開の検討事項」で詳しく説明しています。

自社ストレージの利用：組織は、ベンダー管理のストレージを使用する代わりに、自社のクラウドストレージアカウント（AWS S3、Azure Blob、Wasabiなど）を接続できますか？これは、バックアップデータ内の電子医療情報（ePHI）に関するBAAの範囲とデータ主権に影響します。

5. 将来のデータ量に基づいて評価される価格モデル

医療データは急速に増加しており、現在のデータ量に基づいた価格評価では不十分です。医療ITソリューション向けバックアップストレージに関する価格モデルに関する2つの疑問点は以下のとおりです。

ワークロード単位料金とGB単位料金：ワークロード単位料金モデルでは、システムが生成するデータ量ではなく、保護対象のシステム数に基づいて料金が課金されます。画像ライブラリが年間20～40%増加する医療環境では、ワークロード単位料金モデルはデータ量の増加に関わらず予測可能な価格設定を維持できます。一方、GB単位料金モデルはデータ量の増加に伴って価格が変動するため、医療特有の成長率に対してコストが年々上昇し、累積的なコスト増につながります。

ソース側での重複排除と圧縮：バックアップデータをストレージに送信する前にクライアント側で重複排除と圧縮を行うプラットフォームは、実効データ量を削減します。比率は、ベンダーが公表している平均値ではなく、代表的な医療データで確認してください。また、医療コンプライアンスのためのバックアップ保持ポリシー（HIPAAに基づく対象記録の6年間保持）が、標準料金プランでサポートされており、追加ストレージとして課金されないことを確認してください。

6. HIPAA準拠アーキテクチャ：3つの具体的な質問

HIPAA固有の制御に関する評価フレームワーク全体については、バックアップソフトウェアのHIPAA準拠評価基準に記載されています。医療機関向けのバックアップおよびリカバリソリューションの運用状況に特に関連する3つの質問は以下のとおりです。

• プラットフォームは、顧客が管理する鍵を使用したクライアント側暗号化をサポートしていますか？そうすれば、ベンダーは強制されてもバックアップデータにアクセスできません。
• このプラットフォームは、設定可能な保持期間で、標準フォーマット（JSON、CSV、syslog）のエクスポート可能な監査ログを生成しますか？
• プラットフォームは、復元テストのドキュメント作成をサポートしていますか？具体的には、日付、テスト対象システム、使用されたバックアップセット、達成されたRTO、結果など、各復元テストの記録をエクスポートできますか？

医療現場向けバックアップソフトウェアの評価における注意点

医療機関向けデータバックアップおよびリカバリを評価する際に、プラットフォームを検討対象から除外すべき6つの条件：

• データベースのバックアップは、エージェントベースのオプションがなく、完全にVMスナップショットに依存しています。これは、特定時点への復旧を必要とするあらゆる電子カルテ（EHR）または臨床データベースワークロードにとって、復旧精度の面で大きな課題となります。
• ファイルレベルの仮想マシン復旧には、手動による介入またはサポートの支援が必要です。ベンダーのサポートなしにITチームがインシデント発生時に実行できない復旧機能は、臨床業務において信頼できる復旧機能とは言えません。
• 複数拠点管理には、拠点ごとに個別のコンソールインスタンスまたは個別のライセンスが必要です。これにより管理が分断され、サテライト拠点で監視の抜け穴やアラートの見落としが発生します。
• 重複排除や圧縮を行わない、ギガバイト単位の料金体系。この料金モデルは、医療データの増加率に対して拡張性が低く、画像ライブラリの拡大に伴い、毎年コストが累積的に上昇する原因となる。
• 不変ストレージはガバナンスモードでのみ利用可能です。ガバナンスモードでは管理者による上書きが可能ですが、管理者認証情報が漏洩したランサムウェア攻撃からは保護されません。
• エアギャップ環境の導入には、個別の対応が必要となるか、標準オプションとして提供されていません。エアギャップ環境を必要とする組織にとって、他の機能に関わらず、標準構成としてエアギャップ環境の導入をサポートできないプラットフォームは、現実的な選択肢とは言えません。

医療バックアップソフトウェアの概念実証を構築する方法

医療機関向けバックアップソフトウェアの有意義な概念実証（POC）は、3つの段階を経て進められます。これらの段階は順次進行し、各段階で作成される文書は次の段階の指針となり、調達記録にも反映されます。

ステージ1：デモ前のカバレッジ検証

製品デモをスケジュールする前に、環境内のすべてのワークロードタイプに対するワークロードカバレッジに関するドキュメントを要求してください。トランザクションログをサポートするエージェントベースのデータベースバックアップが、ご使用のデータベースバージョンで利用可能であることを確認してください。PACSバックアップにアプリケーションデータベースインデックスが含まれていることを確認してください。Microsoft 365カバレッジに4つのサービスすべてが含まれていることを確認してください。アーキテクチャで必要な場合は、エアギャップまたはハイブリッド展開が標準オプションであることを確認してください。

デモを行う前に、特定のワークロードバージョンに対する対応状況を文書化できないベンダーは、デモを実施すべきではありません。環境内のすべてのワークロードタイプについて、書面による対応状況の確認が取れてからデモに進んでください。

ステージ2：代表データを用いた回復精度テスト

POC（概念実証）の実施中は、上記の3つの復旧シナリオ（特定時点のデータベース復旧、ファイルレベルのVM復旧、PACSスタディ復旧）を、ベンダーが作成した合成データではなく、自社環境の代表的なデータを使用してテストしてください。各復旧にかかった時間、復旧状態の正確性、および手動による介入が必要だったかどうかを記録してください。

この文書には2つの目的があります。1つは、契約締結前にプラットフォームが貴社の臨床RTO要件を満たしていることを確認することです。もう1つは、HIPAA第164.308条(a)(7)項に基づき、貴社のHIPAA復元テスト記録の一部となることです。同項では、復元テストの実施日、テスト対象システム、および結果を明記した文書による証拠が求められています。構造化された概念実証（POC）は、調達プロセスの副産物としてコンプライアンス文書を作成します。

ステージ3：複数拠点におけるポリシーおよびアラートのテスト

プラットフォームが複数のサイトを管理する場合は、概念実証（POC）中にポリシーのプッシュと中央アラートをテストします。バックアップポリシーを中央で構成し、テストサイトにプッシュして、サイトレベルの介入なしに正しく適用されることを確認します。バックアップジョブの失敗をシミュレートし、サイトレベルのエスカレーションを必要とせずにアラートが中央ダッシュボードに到達することを確認します。オンサイトのIT担当者がいなくても、中央コンソールからテストサイトの復旧を開始できることを確認します。

ステージ3の成果物は、上記の評価基準における3つの具体的な要件に対する、複数拠点管理機能の文書化されたベースラインです。管理された概念実証（POC）においてステージ3をクリアできないプラットフォームは、実際の運用環境におけるサテライト拠点で優れたパフォーマンスを発揮することはできません。

バックアップソフトウェアを評価する医療ITチームの次のステップ

上記の評価基準とPOC構造は、医療機関向けバックアップソフトウェアの契約締結前に適用されます。ワークロードのカバー範囲、復旧精度テスト、複数拠点管理の検証、価格モデルの予測は、導入後に確認するのではなく、評価期間中に完了する必要があります。契約締結前にこの評価を完了した医療機関は、調達記録を保持しており、これはセクション164.308(a)(7)に基づくHIPAA復元テスト文書の一部としても機能します。