re:Invent 2024: CignaがAWS HealthLakeで実現する会員体験向上
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Creating powerful member experiences: Cigna’s AWS HealthLake journey (HLS220)
この動画では、The Cigna GroupのEvernorth Health Servicesが、AWS HealthLakeを活用してメンバーエクスペリエンスを向上させた取り組みについて解説しています。AWS HealthLakeは、HIPAAに準拠したマネージドサービスとして、FHIRベースのデータを100ミリ秒以下の高速なレスポンスで処理し、分析機能も提供します。従来のシステムと比較してTCOを40-50%削減でき、ペタバイト規模のデータでも一貫したパフォーマンスを実現。Amazon Comprehend MedicalやHealth Scribeとの統合により、非構造化データの構造化や音声認識も可能です。2025年には独自スキーマの導入やネイティブデータコンバーターの実装など、さらなる機能拡張も予定されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS HealthLakeセッションの概要と登壇者紹介
皆様、本日はご参加いただきありがとうございます。本日は「強力なメンバーエクスペリエンスの創造：AWS HealthLakeにおけるCignaの取り組み」についての興味深いセッションをご用意しています。私はHealth AIチームのPrincipal Solutions ArchitectのMirza Baigです。始める前にアジェンダを確認し、その後Maniに引き継ぎたいと思います。
本日のアジェンダでは、まずCignaのビジネス目標について - ビジネスモデルの構成、全体的な成果、そしてCignaのような企業が克服すべき様々な課題について、Maniが説明します。その後、私がAWS HealthLakeの技術的な部分 - その概要、仕組み、内部構造、そして実際のソリューションの姿について説明します。最後に次のステップについて見ていきます。それでは、Maniに引き継ぎたいと思います。
Cignaのビジネスモデルと直面する課題
ありがとうございます、Mirza。皆様、こんにちは。本日は皆様とご一緒できることを大変嬉しく思います。まず、ご参加いただき誠にありがとうございます。私はEvernorth Health ServicesグループのMani Paulrajです。Evernorth Health Servicesとは何か、どのような事業を行っているのかと疑問に思われている方もいらっしゃるかもしれません。この機会に、The Cigna GroupとEvernorth Health Servicesの位置づけについて簡単にご説明させていただきます。The Cigna GroupにはCigna HealthcareとEvernorth Health Servicesという2つの部門があります。多くの方がご存知の通り、Cigna Healthcareは30カ国で1億7,000万人以上のメンバーに健康保険やその他のサービスを提供するグローバルヘルスケア企業です。Evernorth Health ServicesはCigna Healthcareを含む様々な顧客に対して、薬局・ケアソリューション、投薬管理ソリューション、行動サービスソリューションなどを提供しています。ここで重要なのは、Cigna Healthcareは顧客の一つであって唯一の顧客ではないということです。私たちは他のCigna Group子会社にもサービスを提供しています。私たちのミッションは、サービスを提供するメンバーの健康と活力を向上させることであり、そのための選択肢と機会を常に探し求めています。ご想像の通り、これらの機会のほとんどはデータ主導型です。
私が所属するInteroperabilityチームでは、パートナーと他の顧客との間のデータ交換のための企業全体のアプリケーションを支えるInteroperabilityプラットフォームの構築を進めています。これは他の顧客向けにも構築しています。先ほど言及したデータ主導型の機会とは具体的にどのようなものでしょうか？その一つが規制要件です。連邦政府や州政府からの規制要件があります。例えば、最近では患者の健康情報への直接アクセスを、相互運用可能で標準化された方法で実現しました。ヘルスケアに携わる方々はPatient Access APIについて話していることをご理解いただけると思います。ヘルスケアビジネスにおいて、規制要件は複雑で要求が厳しく、さらに継続的に進化しています。これらの要件には特有のニュアンスがあり、期限に関しても柔軟性がないことが多いのです。また、臨床データと請求データの交換プラットフォームを使用してメンバーエクスペリエンスを向上させることも目指しています。例えば、どのヘルスケア組織にとっても重要な事前承認ワークフローの改善や、全体的なケア提供指標の向上などです。このプラットフォームは全体的なソリューションの重要なコンポーネントであり、私たちはプラットフォームを継続的に最適化し改善していきたいと考えています。そしてヘルスケアは、特に私たちのような組織にとって複雑なビジネスです。
様々なソースから異なる標準で届くデータを一つの大きなプラットフォームにまとめることは、特にテラバイト規模のデータを扱う場合、大きな課題をもたらします。私たちのミッションは、安全で可用性が高く、運用効率が良く、高性能なプラットフォームを構築することです。多くの顧客からこのような要件を聞いたことがあるかもしれません。これは多くのユーザーに共通する要求であり、聴衆の中にも共感される方がいらっしゃると思います。私たちのケースでユニークな点は、私たちが扱うFHIRデータフォーマットの相互運用可能な性質です。
このプラットフォームを構想し、立ち上げを始めた際、私たちはいくつかの課題に直面し、また将来的な課題も予測しました。まず第一にコストの問題があります。サードパーティのライセンス料、インフラコスト、そしてプラットフォームにデータを取り込むための継続的なビルドとデプロイメントのコストなど、総保有コストが発生します。スケーラビリティは、外部の顧客データがプラットフォームに流入する際の重要な課題です。パフォーマンスはスケーラビリティと密接に関連しています。規制要件とSLAは特に厳格で、規制機関が定めるSLAに準拠しながら、大規模なデータセットを扱う必要があります。
データの再利用性も課題の一つでした。目的別に複数のデータゾーンやデータレイヤーを構築したくないという考えがありました。分析用と患者アクセスAPIで別々のセットアップを作るのではなく、データを一度プラットフォームに取り込んで複数の目的に使用したいと考えていました。AWS HealthLakeが紹介された時、私たちは通常そうするように小規模から始め、必要不可欠な機能を特定しました。そして、テスト結果、負荷テストの成果、データ取り込み速度、予測コスト、APIレスポンスなど、すべての面で驚くべき結果が得られました。HealthLakeがもたらした価値は素晴らしいものでした。
AWS HealthLakeの機能と特徴
パイロットプロジェクトから始めて、品質とセキュリティテストを経て、すでに1つのワークフローがHealthLakeで本番稼働しています。私たちはAWSと協力して、現在のHealthLakeの形まで開発を進めてきました。AWS HealthLakeについてさらに詳しく説明するために、Mirzaにバトンを渡したいと思います。皆さんはHealthLakeとは何かと疑問に思われているでしょう。HealthLakeは基本的にHIPAA対応のマネージドサービスです。この2つの要素について説明させていただきます。マネージドサービスと言う場合、S3のような通常のサービスとは異なります。S3の場合は、そのサービスをそのまま利用するだけですが、AWSのマネージドサービスの場合、S3、DynamoDB、Glue、OpenSearchなど、複数の主要サービスがHealthLakeという一つのまとまった概念として連携するように設計されています。
AWSファミリーには他にも多くのマネージドサービスがありますが、HealthLakeには特有の重要な機能があります。HIPAA対応という点も非常に重要で、基盤となるサービスがHIPAA対応であるだけでなく、マネージドサービスのコンポーネントもHIPAA対応です。取り込まれる個人医療情報（PHI）のセキュリティを確保し、HIPAAフレームワークで定められたルールや規範に準拠していることを確認するため、厳密なテストが行われています。
マクロレベルで見ると、基本的に2つの機能があります。1つは右側にあるRESTful FHIR APIエンドポイントで、もう1つは分析側の機能です。
一般的に、最新のFHIRサーバーを見ると、FHIRはデータを取り込むために使用されており、必ずしも分析の観点から活用されているわけではありません。AWS HealthLakeでは、カスタム実装と同様に大規模なデータを取り込み、それをリアルタイムでトランザクション処理できるようにしています。トランザクショナルAPIについて説明すると、その上にAPIレイヤーやUIレイヤーを構築し、読み取りや作成、更新、削除の操作をリアルタイムで100ミリ秒以下で実行できます。検索の内容や複雑さによっては、100ミリ秒、150ミリ秒といった具合になります。
メンバー向けアプリケーションを構築する場合、そのメンバーが患者であれ、保険加入者であれ、あるいはプロバイダー側で情報を利用する医療従事者であれ、すべてが非常に同期的で最適である必要があります。AWS HealthLakeをバックエンドに使用することで、非常に高性能なアプリケーション層を構築できます。ここでの基盤となるデータモデルはFHIRで、本質的にネストされたJSONオブジェクトであり、サイズは1キロバイトから場合によってはメガやギガにまで及びます。一般的に、FHIR JSONオブジェクトの平均サイズは1〜3キロバイト程度です。EOB（給付説明書）は通常もっと大きく、特にCignaや他の保険会社の場合はそうですが、患者、観察、受診、または症状の記録は基本的により小さな記録です。
扱っているのは、非常に高速に処理され、モバイルアプリやWebアプリなど、どのようなUIレイヤーを通じてもメンバーに提示される必要がある、これらの小さなファイルです。これは臨床アプリを作るだけでなく、相互運用性の姿勢のためでもあります。Patient Access APIに準拠した情報を公開するメンバーアプリやプロバイダーアプリがあるかもしれません。プロバイダーは本質的に、その患者に関連する様々な臨床記録や財務記録を参照する際にこれを使用します。いずれにしても、そのAPIの利用とやり取りはFHIR APIトランザクションを通じて行われます。
Cignaのようなクライアントがいますし、GEのようなグローバルヘルスケア分野のトップ5に入るISVもAWS HealthLake上で診療時点のアプリケーションを構築しています。実際、GEはAWS HealthLakeをデータファブリックとして使用して臨床アプリケーションを構築しています。最近ニュースになった最初のアプリケーションは、腫瘍学に関連するCare Intellectです。AWS HealthLakeが、患者と医師の診察が行われる時点で、非常に高性能で応答性の高い診療時点のアプリケーションを支えている様子が想像できます。これらはすべてSMART on FHIRを使用して実現されています。
PHIに関しては、認証だけでなく、適切な量の認可も必要不可欠です。特に認可に関する規制がより詳細になってきているためです。例えば、最近の規制では、同意が重要な問題となっています - 個人の記録へのアクセスを許可するか拒否するかを判断する際に、同意の部分をどのように管理するかということです。これらはすべてSMART on FHIR仕様の一部です。バージョン1.0は数年前に公開され、2.0が現在公開されており、2.2は2025-26年までに本番環境で使用される予定です。そのため、より深いレベルの認可、きめ細かなアクセス制御が可能になります。
素晴らしいところは、AWS HealthLakeがそれらの細かなニュアンスを理解してくれるため、あなたがすべてを把握する必要がないということです。SMART on FHIRのフレームワークに適応し、適切な権限と同意が適切な役割に関連付けられていることを確認するだけでよいのです。パフォーマンスを確保しながらセキュリティ面に対応できることが保証されています。なぜなら、実世界ではオープンアクセスでのパフォーマンスだけでは機能しないからです。
スライドの左側では、取り込まれたFHIR JSONデータが、AWS HealthLakeのマネージドサービスによって分析用のIcebergテーブルに変換され、表形式になっています。全体的なスキーマは変更されず、依然としてFHIR JSONスキーマに準拠しています。例えば、Mirzaの検査報告書で糖尿病の有無を確認したい場合、FHIRではその検査報告書はおそらくObservationリソースタイプに含まれているため、そのデータストアにアクセスすることになります。分析的な観点から直接アクセスする場合も、同じパターンを使用することになります。
このETLプロセスと変換プロセスはバックグラウンドで実行されています。オプションとしてオン・オフを切り替えることができますが、マネージドサービスの一部として、ユーザーの入力なしに処理が行われます。データが配置されると、SQL on FHIRのすべての機能が利用可能になります。対象のオブジェクトはネストされていますが、ドット記法とSQLを使用することで、社会的健康決定要因（SDOH）データやコホート管理に関する特定のデータなど、必要に応じてデータをマイニングできます。これらの情報はダッシュボードやその他の目的で利用可能です。
AWS HealthLakeの分析機能には、Amazon Comprehend Medicalも含まれています。ここ数日で聞いてきたように、これは自然言語処理ソリューションです。例えば、PDFの経過記録がある場合、それをHealthLakeのDocument Referenceリソースタイプに取り込みます。データストアでNLPが有効になっている場合、そのドキュメントは自然言語で解析され、非構造化データが構造化されます。例えば、MirzaがMetforminを服用している糖尿病患者かどうかを判断するために、観察結果、投薬記録、症状などがその記録から抽出され、システム生成のリソースが作成されます。その情報を使用してFHIR APIで処理したり、分析ワークフローで分析したりすることができます。
HealthLakeの実装と利点
私が話したことを図示すると、左側を見ると、私たちは医療データの大部分がまだFHIRではないことを知っています。FHIRがデータモデルとして主流になるまでには、おそらく何年もかかるでしょう。しかし、業界はFHIRをデータモデルとして採用する方向に進んでおり、これは単なるデータ交換だけでなく、ストレージの面でも同様です。データの大部分は多くの場合非構造化であり、FHIRでもないため、一般的に変換プロセスが必要になります。私たちの顧客の中には、主にクリニカルアプリケーションの構築の観点から、またはペイヤーの観点から、FHIR優先戦略を採用している企業もあります。クリニカルアプリケーションの構築の観点からは、FHIRはペイヤーが持つ全体的なエコシステムに新しく、かつ本質的なものとなっています。
私がこれまで関わってきたすべての医療保険会社の中で、少なくとも一つのグループやチームがFHIRを理解しています。中には完全にFHIRを採用し、FHIRを最優先で進めているところもあります。私が言いたいのは、データ変換の方法があるということです。自社で行うにせよ、InterSystems、Redox、Availなどのパートナーが提供する12種類のHealthLakeコネクターを使用するにせよ、これらのコネクターは既に組み込まれており、データをHealthLakeに取り込むことができます。
Implementation Guide（IG）についても少し時間を取って説明したいと思います。Maniが先ほどステップラダーのスライドで言及していた中間のステップで、IGについて触れていました。IGはコンプライアンスの観点から非常に重要です。コンプライアンスに興味がない場合でも、データの品質は気にかかるはずです。一般的に、取り込むデータが有効かどうかを確認する必要があります。そのペイロードが有効なFHIR JSONオブジェクトであったとしても、LOINC、ICD-10、SNOMEDなどのコードが有効かどうかを確認する必要があります。これがデータ品質の部分です。例えば、US Coreではオブジェクトに特定の要素が必須となっています。US Coreは患者データについて、FHIRの一般的な要件とは異なり、人種と性別を患者記録の必須項目としています。
データ品質の観点から、企業内で特定のIGを使用することができ、HealthLakeへの取り込み時にそれを適用できます。私たちは標準でサポートしているIGのリストを持っています。現在数百のIGが存在し、その大半がUS Coreをベースにしていますが、必要に応じてどれでもサポートすることができます。SMART on FHIR、私が挙げたIG、患者の運動データを扱うCMS Blue Button、多くの保険会社が使用するDa Vinciなどがあります。SMART on FHIRは現在1.1で、2.0が今月12月にリリースされ、2.2は来年半ばにリリース予定です。さらに、統合されたFHIR、Amazon Comprehend Medical、そして先ほど触れた分析機能もあります。
右側は、ユースケースに基づくデータの消費レイヤーです。実行したい予測モデルはありますか？例えば、特定のコホートや集団における再入院のリスクや心臓病のリスクについて懸念がありますか？これらをダッシュボードで表示したり、Cignaが行っているように独自のアプリケーションに組み込んだりすることができます。これらはすべて右側の消費パターンです。
これは細かい図なので、一行一行は読み上げませんが、主要なステップをご説明します。左側には様々なフォーマットがあります：X12、HL7、一般的にCCDAであるHIEデータ、EMRからのプロバイダーデータ、救急室やICUベッドで使用されているデバイスからのIoTデータなどです。これらのデータはすべて取り込む必要があり、複数のソースから来ています。例えば、複数の医師にかかっている患者のデータを照合したい場合があります。これらのデータがFHIR形式であれば、すべてHealthLakeに取り込むことができます。同期的に、あるいはバッチで非同期的に取り込むことが可能です。
FHIRフォーマットでないデータの場合、このスライドのステップ2に示されているように、変換プロセスを経る必要があります。その際、自社で開発するか、HealthLakeのパートナーが提供するコネクターを利用することになります。2025年には、HealthLakeにネイティブのデータコンバーターを組み込む計画があり、そうなれば変換作業を自社で行う必要がなくなります。
データが取り込まれると、Cignaが現在行っているように、トランザクションレイヤーに移行します。このデータを活用して、メンバーエクスペリエンス、Patient Access API、ピアツーピアのデータ交換、その他様々なAPI関連のトランザクションを実現できます。
分析レイヤーでは、Iceberg tableにアクセスするための計算レイヤーとして、Amazon AthenaとAmazon Redshiftをエコシステムの一部として利用できます。Athenaにログインして、必要なデータを検索・抽出することができます。大規模な処理が必要な場合は、パワフルなRedshiftを使用することも可能です。
HealthLakeの成果についてTCOの観点から見てみましょう。これは単にTCOだけの話ではありません。通常なら長期にわたって維持・構築・運用が必要なサービスを手に入れられるということです。さらに、そのサービスのパフォーマンスはAWSが責任を持ちます。つまり、APIのレイテンシーが一定のしきい値を超えた場合、お客様のチームではなく、私たちのチームが対応することになります。これがマネージドサービスの素晴らしい点です。運用の観点から見ると、必要なものを構築する時間が減るだけでなく、その維持に必要な運用時間も削減できます。その結果、それらのリソースを、より上位のビジネス価値を創出するための取り組みに振り向けることができます。
同じ条件で比較した場合、お客様は40～50%程度のTCO削減を実現しています。これは顧客によって異なり、開発やメンテナンスに関連する全体的なメカニズムにも依存します。スケールとパフォーマンスは私たちの主要な差別化要因の一つです。ここでデータモデルによる差別化は行っていません - FHIRはFHIRです。多くのベンダーがFHIRをサポートしており、私たちもFHIR仕様に準拠しています。これはAWSの仕様ではなく、世界中が貢献し、必要に応じて活用できるオープンソースのコミュニティ主導の仕様であり、拡張も可能です。
私たちは仕様に従いながら、APIの観点からパフォーマンスとスケーラビリティを実現しています。データストアに10ギガバイトのデータがあろうと、10テラバイト、100テラバイト、あるいは世界中のデータのほとんどに相当するペタバイト規模のデータがあろうと、期待されるパフォーマンスは一貫しています。10ギガバイトのデータストアで読み取り操作が40ミリ秒かかるなら、100テラバイトのデータストアでも同じ40ミリ秒を期待できます。これは第三者によるテストで実証されており、皆さんご自身でも確認いただけます。これは読み取りだけでなく、検索やすべてのCRUD操作にも当てはまります。一般的に、何かを犠牲にすることなくパフォーマンスの面でスケールすることは難しいのですが、私たちはそれを解決し、心配なくスケールできるようにしました。そして、これもマネージドサービスの一部です。SLAへの適合性は、主にEOBの観点から重要です。Explanation of Benefits（EOB）は定期的に生成され、24時間、48時間、または72時間という取り決めに基づいた短期間で取り込む必要があります。
HealthLakeの最新機能と活用事例
もしSLAを満たせない場合、大量のデータを受け取ったものの適切に取り込めていないことをステークホルダーに報告しなければなりません。そのデータ取り込みの速度はスケーラブルである必要があり、私たちはそれも対応済みです。Maniさんもこの点について経験をお持ちですよね。はい、詳細には立ち入りませんが、これは課題の一部として強調されています。その通りです。そして、データを一度取り込んで複数回再利用できるという点も重要です。
ここで、既に触れた点も含めていくつか強調したいことがあります。差別化された重作業の自動化や、臨床およびアプリケーションワークフローの両面からのゼロETLについて言及しました。セルベースのアーキテクチャも興味深い点です。AWS HealthLakeを最初に使用する際、デフォルトの設定がデプロイされます。このデフォルト設定が必ずしもユーザーに適しているとは限りません。基本的に、一定量のギガバイトのデータを取り込み、SLAのレイテンシー、取り込み速度、トランザクション能力の閾値を下回りながら処理できるという設定になっています。
例えば、EOBが大量にあるものの、アレルギー不耐性の記録はそれほど多くないケースを考えてみましょう。EOBは数十億件あるかもしれませんが、アレルギー不耐性の記録は数百万件程度だとします。このような場合、すべてのインデックスに同じ処理能力を均一に割り当てるような approach は取りません。このようなユースケースでは、検索、データ取り込み、分析のいずれの面でも、柔軟に対応できるよう微調整が可能です。この小さなコンポーネントの調整は全体の価格に影響を与えません。追加の調整に対して追加料金を支払う必要はなく、従量制の料金体系で利用できます。
統合されたNLPとマルチモーダル分析について少しお話ししたいと思います。冒頭で申し上げたように、私はHealth AIというグループに所属しています。Health AIは、HealthcareとLife Sciences向けの目的特化型サービスを構築しています。皆さんのほとんどはLife Sciencesではなく、Healthcare側のビジネスに興味をお持ちだと思いますが、Life Sciences側では、Healthomicsという特定のサービスがあります。VenetianのExpoフロアには複数のブースがありますので、ぜひお立ち寄りください。Healthomicsはゲノムシーケンスとバリアントデータを扱います。これもデータストアの一つです。なぜなら、データストレージとデータレイヤーを最適化し、その上でワークフローやAI/MLモデルを実行できるようにしたいからです。
同様に、DICOMベースおよびデジタル病理ベースのストアである Health Imaging サービスもあります。これも同じように、データを取り込んで大規模にスケールし、その上でワークフローを実行できます。先ほどお話しした AWS HealthLake もその一つです。さらに、Amazon Comprehend Medical と Health Scribe という2つのサービスがあります。Health Scribe は環境音声認識を行います。私は Health Scribe、Comprehend Medical、AWS HealthLake を担当するチームに所属しています。患者と医療提供者の対話において、その会話が環境音声認識によってSOAP形式のノートに変換され、要約されます。その後、自然言語処理によって解析され、ストレージレイヤーに保存されます。そこから、ユースケースに応じてLLMや Amazon SageMaker を使用してAI/ML処理を行うことができます。このように、患者と医療提供者のアクセスから、ケア管理、ケア承認に至るまでの情報の流れ全体を実現しています。これらはマルチモーダル分析に関する一例です。Amazon.comにマルチモーダル分析についてのブログがありますので、さらに詳しく知りたい方はそちらをご覧ください。
最新の機能についてお話ししましょう。昨日、HealthLake を採用したEHRの一つである Greenway のセッションがありました。Greenway には何千もの顧客がいます。彼らのオンボーディングの一環として、私たちはマルチテナンシーの構築に多大な時間を投資してきました。何千ものテナントがある場合、各テナントに個別のデータストアを作成すると、マネージドサービスであっても管理オーバーヘッドが発生してしまいます。そこで、スケーラブルな方法でテナントを管理できるようにしています。
FHIRプロファイルについて、先ほど実装ガイドの話をしました。一部の顧客は、HealthLake に取り込むデータに対して非常に寛容です。つまり、ステークホルダーから価値のある患者データが提供される場合、そのデータの一部を拒否したくないと考えています。一方で、厳格なデータ品質管理を行い、特定のデータ品質基準を満たすデータのみを取り込む顧客もいます。私たちはそれを決めることはありません - 警告を発するか、データの受け入れに非常に厳格になるかは、お客様が完全に柔軟に選択できます。
イベント管理に関して、データが入ってきた際にイベントについて通知を受けたい場合、例えば退院を監視したい場合など、イベント管理を実装して次のベストアクションを取ることができます。これは特に、バリューベースケア、マネージドケア、リスクケアに携わる場合、このようなイベントが重要となるため、非常に重要です。また、AWS Samples の一部として公開されている、活用可能なソリューションのコミュニティも成長しています。
特に強調したいソリューションの一つが、マスタリングとアイデンティティに関するものです。これは、顧客が複数のソースからデータを持っている場合に非常に重要になります。例えば、私の検査報告書が医師のオフィスと検査センター自体の両方から来る可能性があります。この場合、重複した報告書が2つあり、まずマッチングを確認し、その後、1つを破棄するか、1つを包含するか、それとも統合するかを決定する必要があります。Amazon Entity Resolution では、わずか2、3回のクリックで実装できるパターンを作成しました。これにより、複数のソースから入ってくるデータを処理し、マッチングを行い、マッチしたものに対してビジネスロジックを適用して何をするかを決定することができます。
今後の展望と質疑応答
私たちは最初にHealthLakeをアメリカでローンチし、その後インドでもローンチしました。インドは巨大な人口を抱えており、医療とペイメント・認可の両面でFHIRを標準として採用しています。ごく最近、ここ数ヶ月の間にロンドンとオーストラリアのシドニーでもローンチしました。両地域ともFHIRの利用に向けて動き出しているためです。
次は何でしょうか？現在直面している課題について話すと、私たちはペタバイト規模へのスケーリングを進めています。ここで強調したい重要なポイントは、Payerの世界であれProviderの世界であれ、両者とも対応すべきコンプライアンス要件があるということです。Provider側にはONCがあり、Payer側にはCMS規制があります。
AWSの観点からすると、私たちは規制Xに対応したコンプライアントなデータストアを提供しようとしています。つまり、特定の規制に対応したコンプライアントなデータストアを提供することを目指しています。例えば、CMS 0057が近づいていますが、私たちが計画しているのは、HIPAAの適格性と同じように、CMS 0057コンプライアンス適格なデータストアを提供することです。つまり、データを取り込めば、Provider Access、Patient Access、Peer-to-Peer Prior Authorization等の要件を満たすことが保証されるということです。CMS 0057でカバーされているすべての要件に対応します。
同様に、HTI oneについても、Provider側でコンプライアンス対応済みのデータストアを提供する予定です。必要に応じて、第三者機関による認証を受けることもできます。これにより、オンボーディングまでの道のりが大幅に短縮されます。パイロットからプロダクションまでのプロセスがテストしやすくなり、本番環境への移行もスムーズになります。理想的には7日以内でのオンボーディングを目指していますが、多くのケースではそれは現実的ではありません。
分析の部分については、先ほどスキーマがFHIRだと言及しましたが、2025年後半には、そのスキーマを定義するのはお客様に任せる予定です。私たちからスキーマを強制することはしません。分析の観点から、FHIRトランザクション側ではなく、独自のスキーマを持ち込むオプションがあります。Amazon Comprehend Medicalについては、特にHealth Scribeが加わることで、より高度なNLP関連のアクションも利用できるようになります。
最後に何かコメントはありますか？ Feature Slideについて触れたいと思います。フィードバックループが機能している様子を見られて素晴らしかったです。私たちが課題を提起し、それを受けてAWSが解決策を提示し、最新機能や将来の機能についてのロードマップを構築していく。締めくくりとして、AnaとAWSは非常によく似た企業だと言えます。というのも、両社ともデータ駆動型の機会を常に探求し、複雑な問題に対してシンプルなソリューションを見出そうとしています。今後もHealthLakeが私たちにもたらす価値に注目し続けていきます。
CignaとEvernorthとの素晴らしいパートナーシップについて触れましたが、私はこの2つを同じような意味で使っています。違いがあることは承知していますが。お客様、特に大手のお客様は多様なユースケースを持っており、その中にはその組織特有のものもあるという良いポイントを指摘されました。これはHealthLakeに限らず、他のサービスでも同様です。私たちはお客様を起点に考えていますので、最適でない点や不足している点を見つけた場合は、ぜひご連絡ください。喜んでお話を伺い、代替ソリューションの検討や、場合によっては製品機能としての要望として取り上げさせていただきます。
最後に、モバイルアプリでアンケートにご回答いただきますようお願いいたします。この内容が参考になれば幸いです。Maniと私はこの場に残っていますので、ご質問のある方はお気軽にお声がけください。少なくとも15分は、会場から追い出されるまでここにいます。どんな質問でもお答えしますので。ご参加いただき、誠にありがとうございました。 皆様、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion