Amazon Web Services ブログ

医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1

医療情報システムとは、医療に関する患者情報を扱うシステム全般を指し、安全かつ信頼性のあるアーキテクチャで構築、運用される必要があります。

具体的には、日本では 3 省 2 ガイドライン ( 厚生労働省が定めた「医療情報システムの安全管理に関するガイドライン」 、総務省・経済産業省が定めた「医療情報を取り扱う情報システム・サービスの提供事業者に おける安全管理ガイドライン」の総称 ) に対し、医療機関等と共に関連事業者や責任者が要求事項を整理検討し、必要に応じて対策を施す必要があります。

前回の 医療情報ガイドラインの改定から読み解くクラウド化 のブログでは、3 省 2 ガイドラインにおける医療情報を取り扱う情報システム・サービスの提供事業者と医療機関等の位置付けについて取り上げました。

厚生労働省のガイドラインは、医療情報システムのサービス提供事業者だけではなくサービスを委託する医療機関等が主体的に遵守する必要があります。医療機関等のシステム管理者および責任者は、ガイドラインの情報を整理し、サービス事業者との契約の際に、当該サービスを利用した運用形態がガイドラインに準拠していることを自ら確認する必要があります。下記の厚生労働省が公開している Q&A では、クラウド型の電子カルテサービスを例に挙げ、サービスを委託する際に医療機関等がガイドラインに準拠しているかを確認する必要性が明記されています。

Ｑ－23 クラウド型の電子カルテサービスを行う業者に認定制度のようなものはあるのか。もしなければ、業者を選定する際に３省のガイドラインに準拠していることは、どうやって確認すればよいのか。

Ａ 認定制度は現在のところ存在しません。なお、厚生労働省のガイドラインは、サービス提供業者ではなく、サービスを委託する医療機関等が遵守すべきものです。 サービス業者の選定に当たっては、「「医療情報を取り扱う情報システム・サービスの 提供事業者における安全管理ガイドライン」に準拠している旨」をサービス業者に確認させるとともに、契約を結ぶ際に、その旨を条項に盛り込んでおくとよいでしょう。 また、サービスを委託する医療機関は、当該サービスを利用した運用形態が、厚生労働省のガイドラインに準拠していることを、自ら確認してください。

「医療情報システムの安全管理に関するガイドライン 第 6.0 版」 に関するＱ＆Ａ 企画管理編 Q-23 より 抜粋

従来のオンプレミス型の医療情報システムでは、サーバ室の管理からハードウェア機器の管理まで、医療情報システムの担当者や責任者が確認すべき点は膨大な範囲でした。AWS を活用することにより、これらの一部をオフロードし、運用上の負担の軽減に役立ちます。（参考：AWS の クラウドが選ばれる 10 の理由）

本ブログでは、はじめに AWS の責任共有モデルに触れ、どのように医療機関等のお客様が負担をオフロードできるかについて整理します。次に、クラウド環境で医療情報システムを構築・運用する際に、特にご質問をいただくことの多いネットワークの観点で、Part 1 では厚生労働省の医療情報ガイドラインに即した医療情報システム構築におけるポイントとして、専用線的接続や VPN を利用し医療機関等の拠点とクラウドを接続するハイブリッド構成に焦点を当ててご紹介します。

医療情報システムにおける責任共有モデル

従来のオンプレミス環境では、お客さま自身のデータやアプリケーションの運用に加え、物理的なハードウェア、ネットワークなどのインフラストラクチャの管理などを行う必要があり、お客様の責任範囲は膨大となっていました。AWS では責任共有モデルに従って、セキュリティとコンプライアンスは AWS とお客様の間で共有される責任としています。

セキュリティとコンプライアンスはAWSとお客様の間で共有される責任です。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム (更新とセキュリティパッチを含む)、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループファイアウォールの設定に対する責任と管理を担っていただきます。使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異なるため、お客様は選択したサービスを慎重に検討する必要があります。また、この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できます。以下の図に示すように、この責任の相違は通常クラウド ’の’ セキュリティ(Security ‘of’ the Cloud)、およびクラウド ’における’ セキュリティ(Security ‘in’ the cloud)と呼ばれます。

責任共有モデル より抜粋

この共有モデルは、AWS がホストオペレーティングシステムの仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまでの要素を AWS が運用、管理、および制御することから、お客様の運用上の負担の軽減に役立ちます。

また、お客様がクラウドサービス事業者を利用する際の多くは重層的な責任共有モデルとして考えられます。（参考：責任共有モデルとは何か、を改めて考える）。医療情報システムにおいても以下のように考えられます。

ここで、AWS は医療情報システムにおける 3 章 2 ガイドラインへ対応しているか？ という質問を多くのお客様よりいただきます。AWS では責任共有モデルに従って、お客様や AWS パートナーの皆様の固有のシステム要件やアプリケーションの要求事項に見合う形で、どのように各種 AWS サービスをご活用いただけるかということを検討するための AWS サービスに関する情報をご提供しお客様ご自身にご判断いただいております。そのため AWS から一概に対応可否を回答しておりませんが、AWS パートナー各社作成の「医療情報システム向け AWS 利用リファレンス」を活用いただくことが可能です。

したがって、クラウドの利用においても医療機関等は仕組みを正しく理解した上で、ガイドラインを遵守した構築を医療情報を取り扱う情報システム・サービス提供事業者へ委託を行う必要があります。

ここまで責任共有モデルに従いクラウド ’の’ セキュリティ(Security ‘of’ the Cloud)をご紹介しましたが、AWS ではお客様が クラウド ’における’ セキュリティ(Security ‘in’ the cloud) を高めるためのマネージドサービスを提供しております。例として、マネージドサービスである、Amazon GuardDuty ではマネージド型の脅威検知の仕組みを提供しており、お客様の AWS アカウント環境を保護するために役立つ機能を提供しております。AWS のセキュリティ、アイデンティティ、コンプライアンス関連のマネージドサービスはこちらよりご確認ください。また、これから AWS アカウントを取得される方向けに最初にやるべき AWS セキュリティ設定 10 のことのオンデマンドセミナーも開催しております。
その他にも、有償のコンサルティングサービスである、AWS Professional Services ではガイドラインへの対応に向けた支援メニューも提供しています。ぜひ、クラウド導入に関する相談については、お問合せ窓口よりお気軽にお問合せいただければと思います。

医療機関等とクラウドを結ぶハイブリッド構成

ここからは、厚生労働省のガイドラインで触れられている医療機関等と外部の接続について整理し、お客様のクラウドにおけるセキュリティを高めていただくため、専用線的接続や VPN を利用し医療機関等と医療情報システムを結ぶハイブリッド構成について紹介します。

ガイドラインの 6.0 版ではシステム運用編 [Control] の「13. ネットワークに関する安全管理措置」にて、医療機関等を外部と接続する際の遵守事項と考え方が整理されています。特に考え方の部分では、接続先が限定された「セキュアなネットワーク」と、接続先や接続先への経路が管理されていない「オープンなネットワーク」について紹介されており、遵守事項の②では、原則としてセキュアなネットワークを利用することが述べられています。一方で、「13 . 1 . 2 選択すべきネットワークのセキュリティ」では、専用線や IP-VPN による接続は高コストであるために多目的な利用にはなじみにくい状況に触れ、IPsec 等の技術を用いてインターネット VPN を利用し、オープンなネットワーク経由でセキュアなネットワークへ接続するパターンについても触れられています。

AWS では Amazon VPC (Virtual Private Cloud) を利用し、論理的に隔離されたお客さまの仮想ネットワークを構築可能です。VPC 内には仮想サーバーである Amazon EC2 インスタンス等の各種リソースを起動できます。VPC はガイドライン内で示されるセキュアなネットワークに該当します。デフォルトでは閉じたネットワーク空間ですが、インターネットゲートウェイの関連付けを設定することで、インターネットとの接続も可能です *1。

それでは、医療機関等とクラウドを接続した構成 (ハイブリッド構成)を、AWS Direct Connect を利用したセキュアなネットワーク上で接続する方法と、AWS Site-to-Site VPN により IPsec VPN を利用してオープンなネットワーク上で実現する方法について紹介します。

*1 NAT ゲートウェイを利用することで、VPC内へのインバウンドの通信を拒否しつつ、アウトバウンドの通信のみを許可することも可能です。IPv6 の場合は Egress-Only インターネットゲートウェイを利用することで制御可能です。利用例としては OS やミドウルウェアのアップデートに外部への接続が必要なケースなどがあります。

a. セキュアなネットワークを用いた接続

セキュアなネットワークを利用した接続のユースケースとしては、クラウド型電子カルテなどのミッションクリティカルな医療情報システムが考えられます。セキュリティ観点では、患者のゲノム情報などを扱うケースも特に機密性の高い情報を扱う場合も一例として考えられます。また、データ量の観点では PACS (医用画像管理システム)のような高解像度の医用画像の転送等により大容量の通信が想定されます。

AWS Direct Connect は、クラウドとオンプレミスや拠点を専用線的接続するためのサービスです。プライベートなネットワーク接続を提供し、大量のデータの転送やリソースの共有を効率的に行います。AWS は世界中の多くの地域に Direct Connect ロケーションと呼ばれる接続拠点を有しており、日本国内では 2023 年 5 月に追加された印西データセンターを含め 4 箇所(記事執筆時点: 2023 年 8 月 22 日) の Diect Connect ロケーションが利用可能です。回線は専用接続を利用する場合、1 Gbps、10 Gbps、100 Gbpsの速度が選択できます。ホスト型接続の場合は、50 Mbps、100 Mbps、200 Mbps、300 Mbps、400 Mbps、500 Mbps、1 Gbps、2 Gbps、5 Gbps、10 Gbpsの速度が選択できます。また、オンプレミスや拠点等のお客様環境から Direct Connect ロケーションまでの接続について、AWS Direct Connect デリバリーパートナーの支援が利用できます。その他の検討ポイントとして Direct Connect の料金 は、ポート使用料と物理回線費用が必要となりますが、アウトバウンド料金が通常のインターネット向けと比べてデータ量あたりの費用が低い（インバウンドの料金はどちらも無料です）ため、この点を考慮するのが良いでしょう。AWS Direct Connectに関する解説は、 [AWS BlackBelt Online Seminar] AWS Direct Connect (動画はこちら)から確認できます。

大学・研究機関において、国立情報学研究所 (NII) が構築、運用している学術情報ネットワーク (SINET:Science Information NETwork) を利用されている場合は、SINET 経由で AWS を利用する SINET クラウド接続サービスも選択肢として考えられます。【大学・研究機関向け】学術情報ネットワークSINET経由でのAWS利用の基本情報とアップデートのウェビナーを開催しておりますのでぜひご確認ください。

b. オープンなネットワーク上で IPsec VPN を用いたセキュアな接続

オープンなネットワーク上で IPsec VPN を利用したセキュアな接続のユースケースとしては、医療情報の 2 次利用基盤としてクラウドを活用するケースなどが想定されます。スモールスタートでクラウドのスケール可能な計算リソースを活用する場合にも適していると考えられます。その他にも、Direct Connect のバックアップ回線を安価に用意する方法としても選択できます。

AWS Site-to-Site VPN は、AWS のマネージド VPN サービスの 1 つであり、クラウドとオンプレミスのネットワークを IPsec を用いて安全かつ暗号化された接続で結ぶためのサービスです。インターネット回線とIPsec 対応ルーター、固定 Public IP があれば、容易に環境構築ができスモールスタートで始められる点がメリットです (プライベート証明書による認証の場合、非固定 Public IP にも対応可能)。Site-to-Site VPN であれば、オンプレミスのネットワークと VPC 間でのセキュアな通信を確立し、プライベート IP アドレス同士で通信することも可能です。医療機関等のオンプレミス側でセットアップする必要のあるカスタマーゲートウェイデバイスの要件はドキュメントから参照できます。AWS Site-to-Site VPN に関する解説は、 [AWS BlackBelt Online Seminar] AWS Site-to-Site VPN (動画はこちら)から確認できます。

c. 発展的なネットワーク構成

医療機関等におけるクラウドの活用が進むにつれて、いくつかの課題が出てくることも想定されます。
例として、本ブログでは 2 つケースを取り上げ、それらを解決する発展的なアーキテクチャを紹介します。

ケース 1 ）クラウドで稼働する医療情報システムの増加

クラウドで運用される医療情報システムが増えることに伴い各システムへの個々の VPN 接続を行う場合、接続数が増え VPN ルータの管理運用の負荷が高まることが想定されます。これらはクラウドに限らず、従来より医療機関と外部システムを繋ぐ際にルータの管理をされていた担当者の方は経験のある話かと思います。

ケース 2）マルチテナントの医療情報システムにおける、接続先の医療機関の増加

マルチテナント SaaS 型サービス事業者の視点からネットワークを考えると、複数の医療機関と VPN 接続が必要となるため、 セキュリティ観点の課題や IP アドレス範囲の重複の課題が考えられます。

ケース 1 に対しては、 AWS Transit Gateway を利用した複数 VPC への接続が、ケース 2 に対しては AWS PrivateLink を利用した閉域 SaaS アーキテクチャが役立ちます。

ケース 1 のように、医療機関等をクラウドで稼働する複数の医療情報システムに接続する場合は AWS Transit Gateway が利用できます。ルーティングは Transit Gateway のルートテーブルおよび、各 VPC に紐づくルートテーブルで制御が可能です。さらに、AWS Network Firewall を利用することでオンプレミスとクラウド間の通信のセキュリティを高めることも可能です。AWS Network Firewallのデプロイモデルのブログでは Transit Gateway と Network Firewall を組み合わせ、インターネットからの入口を集約しトラフィックを検査する構成なども紹介しています。

AWS PrivateLink を利用すると、インターネットを経由させることなく VPC と AWS のリソース間の通信が可能です。ケース 2 において SaaS 事業者の VPC 内にある NLB (Network Load Balancer) に対して VPC エンドポイントを用意することで、セキュアにアクセスすることが可能です。また、直接 VPC 間をピアリング接続しているわけではないため、IP アドレスが重複していたとしても問題なく動作します。エンドポイントの名前解決には Route53 Resolver の Inbound Endpoint が利用できます。
また、SaaS 型で医療情報システムを提供されている事業者は、AWS PrivateLink Ready パートナーに認定に認定されると、AWS と共同で製品のマーケティングを推進することもできますので、こちらもぜひご検討ください。詳細はAWS PrivateLink を利用した SaaS アプリケーションへのセキュアな接続のブログから確認できます。

まとめ

本ブログでは、はじめに AWS の責任共有モデルに触れ、どのように医療機関等のお客様が運用の負担を軽減できるかについて紹介しました。また、医療機関等とクラウドをセキュアに接続する方法として専用線的接続や VPN を利用したネットワーク構成について解説しました。ネットワーク編 Part 2 では医療機関等のクライアント端末やサーバーからオープンなネットワークを利用した接続について解説を行う予定です。本稿が、医療情報システムをクラウド上に構築する医療機関等および医療情報を取り扱う情報システム・サービス提供事業者のみなさまの参考になれば幸いです。今後もお客様をサポートし、課題解決に寄与できればと考えております。

本記事では 2023 年 8 月時点での AWS 環境上で医療情報ガイドラインに対応するための考え方や関連する AWS の情報を概説しました。最新状況は、ぜひ AWS コンプライアンス「日本の医療情報ガイドライン」のページをご確認ください。

本ブログシリーズの各種リンクはこちら。

著者について

片山 洋平 (Katayama, Yohei) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

 

 

 

尾原 颯 (Ohara, Soh) は AWS Japan にて主にヘルスケア系スタートアップに対して技術支援をしています。好きなサービスは Amazon SageMaker と Amazon HealthLake です。