Citus Health が AWS を使用して安全でリアルタイムのバーチャル患者ケアを提供する方法

AWS アソシエイトスタートアップソリューションアーキテクト、Vincent Zheng および AWS スタートアップソリューションアーキテクトマネージャー、Christine Samson による記事

Citus Health を設立する前、共同創業者兼 CEO の Melissa Kozak 氏は、8 年間、在宅輸液療法を受けている患者に直接ケアを提供していました。この療法では、患者に薬を静脈内または皮下に投与します。看護師として勤務している間ずっと、質問がある場合や問題が発生した場合に、医療提供者と直接連絡を取るために利用できるツールに欠けていることに気づきました。Kozak 氏 は、患者の点滴ポンプ音が一晩中鳴り続けていた事、コールサービスに連絡したところ 3 回転送され、その後接続が切断され、その結果、用量を逃してしまった事を思い出しました。Citus Health の共同創業者である Shadid Shah 氏は、キャリアの中で複数の電子医療記録システムを構築してデプロイしてきたデジタルヘルスケア分野のオピニオンリーダーであり、その支援を受けて、患者中心のコミュニケーションツールとリソースというアイデアを実現することができました。

仕組み

Citus Health は、ヘルスケアチーム、パートナー、家族間のリアルタイムかつ安全なコラボレーションを可能にし、医療提供者の経済的成果にプラスの影響を与えながら、可能な限り最高の患者エクスペリエンスを提供するデジタルヘルストランスフォーメーションのスタートアップ企業です。ウェブとモバイルでアクセス可能なこのアプリケーションは、安全な双方向コミュニケーション、一元化された看護メモ、文書化、スケジュール、ビデオセッションなどの機能を患者と医療提供者に提供します。Citus Health ではサードパーティのシステム統合も可能で、企業は自社のアプリケーションを AWS 上で稼働する Citus Health のマイクロサービスと統合できます。たとえば、専門製薬会社は Citus Health のプラットフォームと統合して、患者自身と医療提供者との両方から文書や重要な患者情報を送受信できるようにすることができます。これにより、患者が必要とする医薬品をよりスムーズかつ簡単に提供できるようになります。

Citus Health が AWS をどのように利用しているか

Citus Health のアプリケーションは、PHP、NodeJS、Angular、Ionic を組み合わせて構築されており、API を使用して AWS インフラストラクチャで実行されているマイクロサービスと相互作用します。同社のウェブサイトとマイクロサービスは、Amazon Elastic Container Service (Amazon ECS) と Elastic Compute Cloud (Amazon EC2) の起動タイプでホストされています。アプリケーションが大きくなるにつれて、これらのコンテナのデプロイ、構造、スケーリングの管理はますます複雑になります。ECS のコンテナオーケストレーション機能は、面倒な作業を処理しながら構成オプションを簡素化することを目的としています。

Citus Health は、リアルタイムメッセージング、認証情報、登録などの機能を提供する複数のマイクロサービスのコンテナを利用しています。Amazon ECS は、Docker にプリインストールされている Amazon EC2 クラスターへのこれらのコンテナの配置を処理します。また、AWS マネジメントコンソールによるこれらのインスタンスのスケーリング、モニタリング、管理も簡単になります。これらのコンテナが置かれているインスタンスと Amazon ECS 間の通信は ECS Container Agent を介して行われます。ECS Container Agent もクラスター内の EC2 インスタンスにプリインストールされています。Amazon EC2 起動タイプを利用すると、これらのマイクロサービスコンテナが置かれるインスタンスファミリーやサイズなどの詳細をより細かく制御できます。Citus Health はインスタンスファミリー、サイズ、その他の設定の詳細を決定できるため、コンテナオーケストレーションの利点を活用しながら、アプリケーションに必要な適切なリソースと容量を確保するために不可欠なインフラストラクチャ管理の特定の側面を制御できます。

Citus Health は、認証情報、安全なメッセージング、登録などのタスクを処理するマイクロサービスを含むプライベートサブネットなどのツールも利用しています。これらの API サービスはネットワークアドレス変換 (NAT) ゲートウェイの背後に配置されているため、API は他の AWS リソースやインターネットとやり取りをしながら AWS クラウド外の外部接続をブロックできます。RDS 上で稼働している PostgreSQL データベースは、別のプライベートサブネットにあります。これらのデータベースは、アプリケーションで生成されたデータを格納するために使用されます。ネットワークアクセス制御リスト (NACL) はすべてのサブネットの前に配置され、不要な接続を除外します。

学んだ教訓

Citus Health が最初に AWS への移行を評価したとき、2 つの大きな懸念事項がありました。ひとつは、カナダのある顧客の PIPEDA 規制への準拠に関するデータ主権と、マネージドサービスプロバイダー (MSP) の Rackspace から AWS に移行する最も簡単な方法を見つけることです。データ主権に関する懸念から、Citus Health はアカウントチームと協力して PIPEDA への準拠方法を決定しました。コンプライアンスとセキュリティに関する責任分担モデルは Citus Health にとって目新しいものではありませんでしたが、PIPEDA が AWS で具体的にどのように機能するかについて、より明確にする必要がありました。HIPAA 事業提携契約 (BAA) が PIPEDA を対象としているのか、それともどちらかの当事者 (Citus Health または AWS) が PIPEDA に準拠するためにより多くの措置を講じる必要があるのか、確信が持てませんでした。Citus Health は AWS アカウントチームとコンプライアンススペシャリストと面談し、この懸念事項について話し合いました。彼らは、責任分担モデルが依然として適用されていることを知りました。つまり、AWS はクラウドのセキュリティとコンプライアンスを担当し、クラウドのセキュリティとコンプライアンスには自社が責任を負うということです。また、AWS Artifact を使用して PIPEDA コンプライアンス標準に関連するレポートを生成する方法や、AWS から BAA を取得する方法についても学びました。しかし、AWS が顧客データを移動しないことがどこに記載されているかも知りたいと思いました。アカウントチーム、コンプライアンススペシャリスト、および Citus Health の弁護士の協力を得た結果、署名した AWS カスタマーアグリーメントページにその旨が明記されていることがわかりました。

Citus Health は、データが SNS 経由で他の地域に送信される場合や、これらのメッセージを含む電話が別の国に持ち込まれる場合は、データの行き先を認識する必要があることも認識しました。また、こうしたシナリオを考慮し、データがカナダ国内に留まるようにするためにどのサービスを利用すべきかを判断できる必要もあります。

移行に関する懸念から、Rackspace は AWS 上で稼働し、同社のお客様のインフラストラクチャを管理しているだけです。Citus Health は、アカウントチームと協力して、データとサーバーを通常の方法で Rackspace から AWS に移行する必要がないことを発見しました。Rackspace は AWS 上で稼働しているため、Rackspace が管理する AWS アカウント ID を持っています。アカウントチームのアドバイスを受けて、Citus Health は Rackspace に直接連絡し、アカウントの所有権を Rackspace から AWS に直接移管できるかどうかを尋ねました。そうすれば、アカウントやプラットフォーム間で実際に何かを移行する必要がなくなります。Rackspace はこれを行うことができるため、初期段階のスタートアップ企業にとっては、移行を迅速化し、顧客側の作業を軽減するのに役立ちます。

Citus、AWS と共に

Citus Health のジャーニーを通じて、同社はさまざまなツールとサービスを活用し、顧客とサービスを提供する企業の両方を最大限に保護することを学んできました。セキュリティは常に最優先事項でなければなりません。Citus Health の社内では、踏み台ホストを備えた別の VPC を利用しています。踏み台ホストは、許可された接続が踏み台ホストに接続できるようにしながら、不要な接続を精査してブロックします。踏み台ホストを通じて、DevOps チームと開発者は VPC ピアリングを通じてメイン VPC のリソースにアクセスできます。リソースを 2 つの別々の VPC に分離すると、リソースを分離しやすくなり、保護と分離がさらに強化されます。各 VPC の仮想ファイアウォールとして機能するセキュリティグループが配置されます。アプリケーションは、不要な接続をブロックしながら、許可された API コールを通じて Citus Health のマイクロサービスと通信できます。NACL はセキュリティグループと連携して動作するため、セキュリティ層がさらに強化されます。セキュリティグループはインスタンスレベルで機能し、接続が VPC 内のリソースに到達するのを防ぎますが、NACL はリソースが配置されているサブネットに入る接続をフィルタリングします。NACL では接続を明示的に拒否することもできますが、セキュリティグループでは許可ルールのみを実装できます。NACL はステートレスでもあり、許可が明示的に定義されていない限りトラフィックは拒否されます。CloudTrail や IAM Analyzer などのモニタリングツールも、誰がどのリソースにアクセスしているかを追跡するのに役立ち、Citus Health は外部エンティティと共有されているリソースやロールを追跡できます。これらはすべて、患者とその情報を保護すると同時に、Citus Health のサービスを利用する他の医療企業も確実に保護されるようにするために導入されています。

Citus Health は成長を続けるため、顧客の要求に応えられるようにリソースをスケールする必要があります。Rackspace による管理から AWS への最初の移行後、Citus Health はトラフィックを分散するために Amazon EC2 インスタンスと Elastic Load Balancer (ELB) だけをセットアップしていました。彼らがスピンアップした容量は、現在のトラフィックと需要を満たすのに十分でした。Citus Health は当初、米国でのみ展開されていましたが、規模が拡大し始めるにつれて、最終的にはカナダ地域にも拡大しました。この成長に伴い、顧客が引き続きスムーズでシームレスなエクスペリエンスを受けられるように、容量を増やす方法として、自動スケーリング対策を導入する必要が生じました。Citus Health もカナダ地域で Amazon ECS を活用し始め、アプリケーションを分離してコンテナオーケストレーションを活用する方法として、アプリケーションをマイクロサービスに分割しました。

また、Amazon Relational Database Service (Amazon RDS) インスタンスのディザスタリカバリとして、マルチ AZ 設定も行っています。データはプライマリインスタンス間で同期的に複製され、プライマリ RDS インスタンスに障害が発生した場合、Amazon RDS は管理者の介入なしにスタンバイインスタンスへの自動フェイルオーバーを開始します。患者にヘルスケア提供者とのコミュニケーション手段を提供するという点では、伸縮性によってスムーズでシームレスな体験が保証され、可用性によって患者は常に繋がり続け、必要なリソースへのオープンなコミュニケーションが確保されます。

まとめ

スタートアップ企業は非常に速いペースで動いており、製品やサービスをできるだけ早くリリースしたいという理由で、セキュリティ、伸縮性、可用性などの詳細が無視されてしまう可能性があります。AWS を利用することで、Citus Health は組み込みのツールとサービスを活用して環境を保護し、サービスの可用性と耐障害性を維持することができました。セキュリティグループ、NACL、ロードバランサー、自動スケーリング、マルチ AZ 設定などが適切に設定されていることを確認することで、アプリケーションの可用性と安全性が維持され、長期的に見て顧客に最もスムーズなエクスペリエンスを提供できるようになります。