ヘルスケア プロバイダ( 医療サービス提供者、Hospital、HealthTech )のパターン

ヘルスケア プロバイダが取り扱う医療データには、CT・MRI・内視鏡・超音波などのデジタル画像データや被診察者の診療データがあり、独自のデータ フォーマットで、データの交換や管理が行われています。また、機微な情報を取り扱うケースも多く、データの取り扱いに注意する必要があります。
これらのデータを安全に統合管理し、分析・活用を可能とするデータ基盤を構築することで、患者の容態把握や将来の疾患発症予測をはじめとした、新たな価値提供を目指す第一歩となります。

医療分析プラットフォーム

解決する課題・使い所

ヘルスケア プロバイダが取り扱う​​電子カルテや PACS をはじめとしたデータは、Fast Healthcare Interoperability Resources(FHIR)や Digital Imaging and Communications in Medicine(DICOM)と呼ばれる独自のデータ フォーマットでやりとりされ、独立して管理されていることが多く、統合してデータ分析を行うことは困難でした。また、これらの医療データは、技術の進歩とともに爆発的に増大しており、データの蓄積そのものに対する問題も顕著となっています

個人情報の匿名化や保存データの暗号化の機能も具備しているので、法規制にも対応できます。


アーキテクチャ

アーキテクチャの前提として、病院システムはパブリックなネットワークに出られないことを想定しています。病院システムから Google Cloud への経路には、Cloud Interconnect を利用した閉域網による接続を想定しています

Cloud Healthcare API は、HTTP を使用します。HL7v2 や DICOM は、独自プロトコルを使用しているため、アダプタを用いてプロトコル変換を行います。

Cloud Healthcare API

Google Cloud の医療データ専用のサービスを利用するための API であり、HL7v2 や DICOM などの成熟した医療データ標準と、FHIR などの新しい標準のサーバーレス / マネージド サービスの実装を提供します


BigQuery

ペタバイト スケールのデータまで取り扱うことのできるエンタープライズ データ ウェアハウスです。エンタープライズ データ ウェアハウスとカテゴライズされますが、ストレージのコストが Cloud Storage とほぼ同程度のため、構造化データに限ればデータレイクとして利用することも可能です。また、データマートとして利用することもできます


Dataflow

さまざまなデータ処理のパターンの実行に対応したデータ パイプラインを実現する上で、欠かせないマネージド サービスです。バッチ処理にも、ストリーミング処理にも対応し、負荷状況に応じて動的にスケールできるので、大規模なデータに対する複雑なデータ処理にも対応しています


Vertex AI

機械学習に必要な、あらゆるツールを備えた単一プラットフォームであり、データ サイエンティストが正式な ML トレーニングを受けることなく、データの管理、プロトタイプ作成、テスト実施、モデルのデプロイやモデルの解釈、本番環境でのモニタリングが可能です


Looker

Looker は、リアルタイムのビジネス分析を簡単に探索、分析、共有できる BI ツールで、データ分析プラットフォームです


利点

同意管理プラットフォーム

解決する課題・使い所

診療では、さまざまな場面で患者の同意を得る必要があります。例えば、手術や処置など、治療の実施に対する同意や、 診療目的で情報を収集・利用、および第三者に提供することに対する同意、情報を研究などの学術利用することに対する同意などがあり、それぞれのケースに対して患者の診療情報を適切に保護することが求められます

Consent Management API は、患者から受け取った同意情報を保存し、ユースケースごとに許可されたデータを追跡し、アプリケーションが患者の同意情報に基づいてデータを使用できるよう支援します


ユースケース

患者の同意情報の管理や、患者の診療情報へのアクセス権限を管理する場面で、非常に有用なソリューションです。例えば、患者に診療 / 処置に関する説明をし、署名をしてもらうアプリケーションを構築する場合、Consent Management API や Cloud Storage API を用いることで、患者の署名を含むドキュメントを Cloud Storage に自動的に保存し、Consent Store で患者の同意情報やステータスを簡単に管理することができます

また、データの属性やデータにアクセスする人の属性、データへのアクセス ポリシーを事前に定義しておくことで、同意情報に基づいてアクセス権限を判定することができます。例えば、個人情報を含むデータは、医師などの病院関係者のみがアクセス可能であり、データ分析を行うリサーチャーはアクセス不可とするといったポリシーを定義しておくことで、リサーチャーは顧客が同意し、匿名化されたデータにしかアクセスすることができないので、機微な情報の流出を避けることができます


アーキテクチャ

以下は、アプリケーションから Google Healthcare Consent Store へ患者の同意情報を保存し、事前に定義したアクセス ポリシーをもとにアクセス権の検証を行うことで、データへのアクセスを適切に管理するためのアーキテクチャです

Resource Attribute Definition

アクセス権を管理するデータの属性情報を定義します。例えば、個人情報を含むか否かなどです


Request Attribute Definition

データにアクセスするグループを定義します。例えば、医師などの病院関係者や、データ分析を行うリサーチャーなどです


Consent Artifact

患者の識別子、Compute Engine に保存された同意の署名および同意書類のスクリーン ショットの URL、同意日時、同意のステータスなどを保存します


Consent

患者の同意に対して、アクセスポリシーを定義します。例えば、データ属性として個人情報が含まれている場合は、病院関係者のみがアクセス可能であり、個人情報が含まれていないデータはリサーチャーもアクセス可能などの条件を設定することができます


User Data Mapping

アクセスするデータの識別子を定義し、属性情報を Resource Attribute Definition を用いてマッピングします


利点