この記事では、Azure クラウド プラットフォームを使用して、遠隔医療システムを構築する方法について説明します。
Architecture
このアーキテクチャの Visio ファイルをダウンロードします。
ワークフロー
このソリューションは次の 4 つの柱によって構築されます。
- クライアント
- 通信コンポーネント
- API およびビジネス ロジック
- ストレージおよびインフラストラクチャ サービス
アーキテクチャの図の左側には、医療専門家と患者という 2 つのクライアント グループが表示されています。 医療専門家は、調整ソフトウェアと Web ポータル クライアントを使用して患者との通信を行います。 一方、患者は、Bluetooth 接続を介して医療機器にリンクされているモバイル アプリを使用します。 この通信のやり取りは、次のようなバックエンド サービスを使用して実現されます。
- パブリックに公開されている API
- Web RTC、または Signal を使用したクライアント間通信を介してビデオ通話などのワークフローを担当する内部のマイクロサービス。 Signal は、サーバー コードで非同期通知をクライアント側 Web アプリに送信できるようにする Microsoft ASP.NET のソフトウェア ライブラリです。
これらのサービスの状態は Azure Database for PostgreSQL などの複数の Azure サービス (上の図の右側を参照) によって永続化されます。 メディア ファイルは Azure ストレージ アカウントに保存されます。 すべてのサービスのすべてのログが、Azure Application Insights を使用する一元化されたログ記録ソリューション内に収集されます。 最後に、Azure Notification Hub を利用したプッシュ通知を介して、クライアント間の非同期通信が実現されます。
このようにセットアップされたソリューションによって、次のことが実現されました。
バックエンドで実行されているクラウド サービスのスケーラビリティからメリットが得られます。
ソリューションを構築するチームの自律性が向上します。 各チームが機能ドメインを監視し、コンポーネントの進化を促進します。 機能ドメインが重複しないため、各チームが独自のペースでイノベーションを進めることができます。 また、サービスのコードベースが独立しているので、ソリューション全体の CI/CD パイプラインが簡素化されます。
複数のマイクロサービスに分散している各機能が必要とするサービス間の通信と調整メカニズムが構築されます。 このドキュメントで説明されているソリューションでは、Azure Cache for Redis を使用してこのタスクが実行されます。
一元的な監視が実現され、ソリューションのトラブルシューティング機能が強化されます。
マネージド ID を利用してシークレット、資格情報、証明書、キーの管理を簡略化し、サービス間の通信をセキュリティで保護します。
Components
- Azure Database for PostgreSQL: ユーザー (患者と医療専門家) およびデバイス関連のデータを格納します。 このサービスが選択された理由は、安定性、軽量であること、およびベンダー ロックインがない点です。
- Azure Kubernetes Service: アプリケーションのビジネス ロジックをホストし、展開の容易さとカスタマイズの柔軟性を実現します。 また、このサービスによって、内部で使用されている実際のハードウェアからソリューションが抽象化されます。
- Azure Cache for Redis: サービス間データ (共有データ) に使用される一時データをホストします。 キャッシュ内のデータの有効期限が切れた場合、データベースからサービスを再作成できます
- Azure Notification Hub: チャット、ビデオ通話、デバイス構成設定などの受信コンテンツを患者に通知します。
- Azure Functions: タスクをスケジュール設定します。 たとえば、多数のユーザーへの広範な通信や、バックエンドでの分析作業 (集計など) の調整といったタスクです。
- Azure Application Insights: トラブルシューティングの目的で、システムからのシグナルとイベント (マイクロサービス、フロントエンド、デバイスからのログとログのテレメトリ) を一元化します。
- Azure Content Delivery Network (CDN): Web ポータルのメンテナンスと更新 (Java スクリプト ファイルの配信) に使用され、ポータルを通じてメディア ファイル (ビデオ、画像) が配信されます。 これらコンテンツはすべて、バックグラウンドで Azure ストレージ アカウントに格納されます。
- Azure Traffic Manager: 地理的な場所の間で負荷を分散します。
- Azure SignalR: サーバー コードで非同期通知をクライアント側 Web アプリに送信できるようにします。 エンド ユーザーのデバイスは、標準モードまたは詳細設定モードで構成できます。
代替
データベース側には、その他の任意の PaaS データベース サービスを使用できます。 アプリケーション ロジックをホストする場合、Azure Kubernetes Service を使うのではなく、Azure App Service の使用を検討できます。
シナリオの詳細
この詳細は、専門の医療機関を離れた場所にいる患者に接続する、実際の顧客実装に基づいています。 このようなシステムを構築する方法は他にもありますが、ここで説明するソリューションでは、互いに離れた患者と医療提供者の間で通信を確立すると共に、患者が携帯する医療機器をリモートから調整することに成功しています。
約 7 億の人々が聴覚障害に苦しんでいます。 しかし、補聴器を使用して生活の質を改善している人は、そのうちの 10% に過ぎません。 必要なときに患者が直接的な支援を受けられない地域や状況もあります。 たとえば、次のような患者を考えてみましょう。
- 聴覚の専門医療機関の診察室では再現できない、特定の聴覚環境 (公園での散歩中、パーティへの参加中、在宅中など) での支援を必要としている患者。
- 移動に困難があるか、聴覚の専門家から遠く離れた場所に居住している患者。
- 聴覚治療の専門家の人数が限られている新興国/地域に暮らす患者。
これらの困難を克服するためには、聴覚医療サービスをリモートから提供する機能を実現することが重要です。 この場合、医療従事者はチャットやビデオによる通信を使用して、離れた場所にいる患者とやり取りします。 聴覚に障碍がある人は、リモート セッション中に補聴器へのアクセスが可能なスマートフォンを使用します。 聴覚の専門家がリアルタイムで補聴器の構成に変更を加えると、患者はたちどころに聴力が改善するのを体験できます。
考えられるユース ケース
このソリューションは、医療業界に最適です。 次のような他のユース ケースでも、設計パターンは似ています。
- このようなソリューションを使用して、Bluetooth 対応デバイスにアクセスし、リモートから調整できます。
- リモートでの設定やコンテキストにおける通信 (テキスト、音声、ビデオ) または情報交換 (教育、満足度調査)。
- グローバルに分散した Web コンテンツの管理。
- モノのインターネット (IoT)
モード
標準モード
標準モードでは、調整ソフトウェアによって通知が準備されます。この通知には、デバイスの構成 JSON ファイルまたはコンテンツが格納されます。 通知は Azure Notification Hub に渡され、そこからユーザーのスマートフォンにプッシュされます。
詳細設定モード
詳細設定モードでは、補聴器の専門家が調整ソフトウェアを使用して、詳細な構成をデバイスにプッシュします。 これには、バックエンドとデバイスの間に安定性と信頼性の高い接続が必要ですが、これは SignalR で Websocket を使用して実現します。 エンド ユーザーのスマートフォンは、このチャネルの受信端に位置します。 スマートフォンからは Bluetooth 接続によってデバイスとの最終的な通信リンクが確立されます。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
リージョン間の待機時間を最適化するため、またクラスターが使用できなくなった場合のフォールバック メカニズムとして、クラスターの前面でトラフィック マネージャーを使用することをお勧めします。 データベースについては、大量のデータの読み込みと集計を必要とするクエリ用に、読み取り専用レプリカを使用することをお勧めします。 キャッシュを介して速度を向上するには、コンテンツ配信ネットワーク (CDN) を使用して静的な Web ファイル (.html、.js、画像など) をグローバルに配信することをお勧めします。
デプロイ
このシナリオを展開する際に考慮すべき最も重要な側面は、クラウドベースのバックエンドとフロントエンド (スマートフォン/デバイス) の間の展開をどのように調整するかということです。 これを実現するには、機能フラグの概念の使用を検討します。
管理
特定のマイクロサービスを使用して処理される各機能ドメインを長期的に維持するという考え方を適切に実現するために、データベースを複数の小さなデータベースに分割することができます。 こうすることで、すべてのサービスに関連するデータを単一のデータベースに集中させるのではなく、各マイクロサービスに関連した原則に分離し、それぞれのフローの自律性を実現することができます。 この目的を達成するには、それらのデータベースのプロビジョニングと管理を自動化する必要があります。これは、クラウドの PaaS データベース サービスの中心的な機能の 1 つです。 このデータベース管理レイヤーは、ソリューションおよび統合監視ソリューションに一体化する必要があります。
監視
各階層を監視することが重要で、各監視ファセットはクラウド内の 1 つのバケットにフェデレーションする必要があります。 コンポーネントとレイヤー全体で総合的な分析情報を確保するためには、これらのすべてのログとテレメトリ データ ポイントの相関関係を有効にすることが重要です。
現在、監視対象のレイヤーには以下が含まれます。
- Windows アプリケーション (聴覚の専門家のデスクトップ上の調整ソフトウェア)
- ホストされるアプリケーション ロジック
- クラウド サービス
サイズ変更とスケーリング
一日の時刻パターンや地域パターンによって変動するスケーリング要件に対応するように、Azure Kubernetes クラスターの構成が最適化されていることを確認します。 Azure Database for PostgreSQL で読み取りレプリカを使用することによって、読み取りワークロード (クエリの集計など) をオフロードすることを検討してください。
PostgreSQL の TimescaleDB 拡張機能を使用すると、医療機器から送信される時間関連データの処理を効率化できます。 複数のデータベース ノードをプロビジョニングすることによってグローバルにスケーリングするには、Azure Database for PostgreSQL 上で Hyperscale (Citus) などのスケールアウト ソリューションの使用を検討してください。
セキュリティとコンプライアンス
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。
このソリューションでは、PHI データと個人データを処理します。 そのため、医療アプリケーションとして認定 (HIPAA 認定、データベースに残っているデータだけでなくログとテレメトリ データについても) されているサービスを使用することが重要となります。 詳細については、Microsoft Trust Center の HIPAA セクションを参照してください。
パスワード管理を簡略化するには、次の種類のパスワードレス認証をサポートするすべての Azure ID でマネージド ID を使う必要があります: AKS、PostgreSQL、Redis Cache、Notification Hub、Azure Key Vault、Azure Functions。 Azure リソースのマネージド ID をサポートする Azure サービスをすべて確認してください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。
1 つのリージョンでの展開については、価格情報の例が「料金計算ツール」に記載されています
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Jean-Yves Devant | プリンシパル プロダクト マネージャー
次のステップ
お客様のビジネスに匹敵するアーキテクチャの実装を開始するには、Web サービス、データベース (Azure Database for PostgreSQL など)、およびモバイル アプリケーションの開発手法とテクノロジ (.NET MAUI など) に関するスキルを強化することをご検討ください。
製品ドキュメント:
- Azure Database for PostgreSQL とは
- Azure Kubernetes Service
- Azure ストレージ アカウント
- Azure Cache for Redis について
- Azure Functions の概要
- Azure Application Insights
- Azure Notification Hubs とは
リアルタイム コミュニケーション:
WebRTC でモバイル アプリケーションにリアルタイム通信機能を提供する方法の詳細については、WebRTC プロジェクト サイトを参照してください。
TURN サーバー:
Icelink クライアント ライブラリ (スマートフォンのアプリケーションおよび補聴器の専門家のデスクトップ上の調整ソフトウェアによって読み込まれます) を使用して、2 つのクライアント (調整ソフトウェアとスマートフォン上のアプリケーション) の間で TURN サーバーと接続の種類 (TCP、UDP、P2P) を管理します。 クライアント ライブラリでは、以下を実行します。
- ストリーミング チャネルを作成する
- 接続を確立する
- エラーやパケット不足の場合に接続を管理し、帯域幅の変動に合わせてストリーミングを自動調整する
- 通話 (音声/ビデオ) をエンコード/デコードする
* TURN サーバーは、VoIP 関連のプロトコルにおいてメディアの中継を担当するネットワーク エンティティです。 このソリューションでは、世界各地にある複数のデータセンターにおいて、https://xirsys.com/ でホストされます。 同じセッションに参加している 2 つのクライアント間で直接接続を確立します。