re:Invent 2025: PhilipsのAWS HealthImagingによるデジタル病理学ワークフロー変革事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Transforming Integrated Diagnostics: Philips' AI Journey with AWS (IND219)
この動画では、AWSとPhilipsが統合診断の変革について解説しています。医療現場では適切なデータへのアクセス不足により約10%の生産性低下が発生しており、特にデジタル病理学の分野で大きな課題があります。AWS HealthImagingは、DICOM画像の保存・管理における差別化されていない重い作業を取り除くマネージドサービスとして紹介されています。Philipsは134ペタバイトの医療データをクラウドに移行し、Enterprise Pathology Solutionを通じて、従来11時間35分かかっていたワークフローを36分に短縮することに成功しました。AWS HealthImagingのタイル消費機能により200ミリ秒以下で画像を取得でき、病理医の100%がデジタル病理導入後は顕微鏡に戻りたくないと回答しています。放射線科、心臓病学、病理学のデータを統合することで、臨床医間のリアルタイム協力と精密医療の実現を目指しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
統合診断の変革：医療データサイロの課題と生産性損失
みなさん、ようこそ。Reinvent へようこそ。本日ここにいられることは本当に光栄です。Reinvent の初日を素晴らしく過ごされていることを願っています。すでに4つ、5つの異なるセッションに参加された方々からの素晴らしいお話をたくさん聞いています。これが本日の最後のセッションかもしれませんが、私にとってはもちろんこれがハイライトです。そして、このセッションの終わりまでに、これがみなさんのハイライトにもなることを本当に期待しています。それは、本日カバーする素晴らしいトピックがあるからです。統合診断の変革についてです。もし適切なデータへのアクセスを簡単にし、データサイロを打ち破ることができれば、どのようにして医療を改善し、患者さんのケアの質を向上させることができるでしょうか。
本当に素晴らしいのは、ここで AWS の観点から純粋なテクノロジーと理論的にどのようにできるかについて話しているだけではなく、パートナーの Philips もステージに登場して、彼らが実際に現場の患者さんと医師のための臨床ケアを推進するソリューションをどのように構築しているかを説明するのを手伝ってくれるということです。AWS HealthImaging チームの素晴らしいチームがいます。Jaron Nix と Wilson To 博士、そして Royal Philips の Predrag Angelovski です。私の名前は Sam Kool で、AWS のシニアソリューションアーキテクトで、Philips のようなヘルスケア顧客をサポートしています。
Amazon 内で何かを始めるときはいつでも、私たちは常に顧客から逆算して考えます。ヘルスケアの中では、これは非常にシンプルです。顧客は患者さんであるべきです。直接的にでも、間接的にでも。それはいつも、患者さんに最も良いサービスを提供し、彼らにとって最高の成果を提供するにはどうすればよいかということに帰結します。ヘルスケアにはいくつかの課題があり、これらはすべてニュースを読んだり、医療費の上昇についての話を見たりしたことがあれば、おそらくご存知のことばかりです。
高齢化する人口、医療費の上昇、そしてより複雑な疾患状態があります。これらは私たちのサービスと医療システムに負担をかけています。 そして、異なるデータサイロがあります。紙ベースのシステムから電子システムへと移行してきた中で、私たちは一歩ずつそうしてきました。これらすべての異なるデータサイロを生成するソリューションを作成してきました。移行してきた一方で、今度はそれらのデータサイロを打ち破ることが私たちの役割です。どのようにしてそれをすべて統合し、次のステップに進むことができるでしょうか。
また、不足もあります。スタッフの不足だけでなく、医薬品と物資の不足もあります。スタッフの不足は私が特に指摘したいものです。なぜなら、看護師、専門医、医師が患者さんと実際に一緒に過ごす時間がないことについてのニュース記事をたくさん見ているからです。どのようにして彼らに時間を取り戻させ、本当に適切なケアの質を提供することに焦点を当てさせることができるでしょうか。
これをサポートする素晴らしい引用があります。Philips Future Health Indexからの引用なのですが、世界中でほぼ2,000人のヘルスケア専門家を対象に調査した結果、大多数の77%が、適切なデータにアクセスできないことによって約10%の生産性低下を経験していると述べられています。Reinventではジェネレーティブ AIがいかに業界を変革しているかについての様々なトークが見られますが、これを見ると、単に適切なデータにアクセスできないという理由だけで、これほど多くの生産性が失われているんです。シンプルな問題に思えるかもしれませんが。
しかし、医療とそれを支えるすべてのデータをより深く見ると、非常に複雑なんです。単一のデータタイプではなく、異なるスペース内に複数のモードのデータがあります。電子健康記録データ、検査室データ、すべて異なるシステムからのものです。イメージング領域内でも、放射線科、病理学、心臓病学など、あらゆる種類の異なるデータがあります。精密医療へとさらに進み、ヘルスケアシステムの次のステップを踏み出していく中で、全体像を完成させるためにゲノミクスをますます取り入れていくことになります。
患者中心の統合データシェル構築とクラウドパソロジーの可能性
データサイロを打ち破ることで私たちがしたいことは、特定のデータタイプ、特定の専門分野向けに構築したポイントソリューションから離れ、患者中心の統合されたデータシェルを構築することです。どの医師でもそれにアクセスして、必要に応じて適切なデータを取得できるようにしたいのです。Philipsがどのように革新しており、Philipsが AWSと一緒にどのように革新しているかについて、重要な例を1つ挙げたいと思います。それは病理学です。
病理学は多くの異なる側面から見ても非常に興味深いものです。科学的な観点からも非常に興味深いです。病理学に詳しくない人のための通常のフローは、通常がん治療で使用されます。生検、つまり組織の小片を採取して、病理検査室に送ります。そこで組織が準備され、ガラススライドの間に挟まれた薄い組織片として、顕微鏡の下で観察されます。病理医はそのサンプルから患者がんを患っているかどうかを判断することができます。
どのタイプのがんを見ているのか？病気はどの程度進行しているのか？どのタイプの治療が最も効果的かもしれない、または効果的でないかもしれない治療は何か、患者にとってより良い結果をもたらすのか？そのすべてのデータが収集され、検査室システムと患者履歴内で既に収集されているすべての他のデータと集約され、その後、確定診断を下す治療医に送られます。
科学的な視点からも、ヘルスケアの視点からも、テクノロジーの視点からも、本当に興味深いことです。 デジタルパソロジー自体は、複数のステップに分かれながら、全体的な進化を遂行しており、これらすべてのステップにおいて積極的に成長しています。現在のところ、ほとんどのヘルスケア機関は依然として顕微鏡パソロジーベースであり、従来のセットアップを使用しており、それはある程度すべてが手作業であるため、労働集約的です。オートメーションのオプションは限定的であり、ガラススライドに純粋に基づいているため、時間の経過とともにデータ品質がある程度低下します。
だからこそ、私たちは徐々にデジタルパソロジーへと移行し始めています。私たちはまだ非常に初期段階にあり、Philips はこの分野で素晴らしいパイオニアとなっています。本質的には、顕微鏡から超高解像度カメラへと移行し、顕微鏡を通して見る代わりに、スクリーン上のピクセルを見ることになります。これには大きな可能性があります。なぜなら、今やデータを持っているので、そのデータの上で推論することができるからです。コンピュータに機械学習を実行させて自動分析を行わせたり、マルチモーダルデータを収集して臨床医のための 1 つのビューに提示することもできます。
さらに進化するための次のステップは、クラウドパソロジーを通じてデータを開放し、その完全な可能性を引き出すことです。もはや単一のヘルスケア機関の制限に縛られることはありません。それを開放して、都市、州、そして国際的に臨床医がアクセスして協力できるようにしたり、様々なドメインとヘルスケア機関にわたってデータを収集できるリサーチクラスターを構築して、がん研究を推し進めたり、予測と診断をより良くするための新しい機械学習アルゴリズムを開発したりできます。もちろん、クラウドに入ると、AWS からのすべての異なるサービスを使用することで、単なるソリューション以上のものを活用することができます。
統合診断を支える4つの柱とAWS HealthImagingの登場
これが、統合診断ビジョン内でクラウドが果たす役割をどのように見ているかです。少し視点を広げて、より広い視野で見ると、定義できる 4 つの柱があります。相互運用性、統一されたアクセスとコンピュート、そして付加価値サービスです。相互運用性は、ヘルスケア内の本質的なものについて本当に語っています。私たちは常にあらゆるタイプとモダリティのデータを持つことになります。では、どのようにしてそれらを統合するのでしょうか。私たちはすでに標準を持っています。実際にそれを 1 つの統一されたデータセットとして機能させるにはどうすればよいでしょうか。これらを適切に一緒に機能させるにはどうすればよいでしょうか。
だからこそ、私たちはヘルスケア業界に特化した AWS 上にすべての異なるサービスを構築し、すべてのパートナーソリューションと提携して、データファンデーションを迅速に構築できるようにしました。私たちは、小さなボリュームであろうと大規模なボリュームであろうと、データを開放できるようにすべてのストレージサービスを活用しており、その後、コンピュートをレイヤリングして、収集されているすべてのイメージまたはデータを簡単にトランスコード、ストリーム、アクセス、処理できるようにしています。その中核は、それを超えて付加価値サービスへと移行することです。これがクラウドの力です。すべてのパートナー、ソリューション、サービスを一堂に集めて、AI、ビッグデータ分析、またはその他の機能であろうと、より多くの価値をレイヤリングできるようにすることです。
ここからもう少し視点を広げて、アーキテクチャの観点から見てみると、これが今、多くのお客様が構築しているものです。これは、病理学であれ、その他の専門分野であれ、クラウド上の医療画像セットアップがどのようなものになるかを非常にシンプルに表したものです。基本的には、いくつかの重要なコンポーネントがあります。何らかのコンピュートリソース、何らかのストレージ、そしてデータベースです。これらを使って画像をキャプチャし、処理し、保存し、管理することができます。これを何度も何度も見かけます。そして、これを中心にアーキテクチャを構築する方法は無数にあります。良い選択肢もあれば、それほど良くない選択肢もあり、すべてのお客様が独自の基本的な基盤を作成しています。
その上に、私たちは付加価値サービスをレイヤーとして追加していきます。優れたユーザー体験でシンプルにすること、生成 AI で価値を追加すること、そしてカスタムモデルで差別化を図ることです。同じ基盤を何度も何度も繰り返すことが、私たちが AWS の差別化されていない重い作業と呼んでいるものです。これは、競合他社との差別化にならない同じ基盤を何度も何度も作成することです。これはお客様が焦点を当てるべき場所ではありません。だからこそ、私たちはそれを加速させるために異なるサービスを構築することに焦点を当てています。だからこそ、AWS HealthImaging を構築したのです。
AWS HealthImaging は、AWS 上の DICOM ストアとして目的別に構築されたサービスであり、すべての複雑さを取り除くことができます。イメージング領域内の製品ごとに独自に構築する必要はもうありません。代わりに、すべてを処理するマネージドサービスの利点を活用することができます。いくつか挙げてみました。ピクセルメタデータ、エンコーディング、デコーディング、DICOMweb を配信メカニズムとして使用することなど、その中にはさらに多くのものがあります。しかし、その核となるのは、マネージドサービスに直接オンボードでき、複雑さを取り除くことができるということです。そうすることで、重要なことに焦点を当てることができます。それは、付加価値サービスとコンポーネント、つまり、あなたの製品を差別化するものを構築すること、そして本当に臨床ケアを前に進めることです。
臨床ケアを本当に前に進めるのは、患者さんをより良くするためにどのようにサポートできるかを理解することです。これは 1 つのデータセットだけでなく、多職種の観点からも実現できます。病理学、放射線科、心臓病学など、1 つのタイプのデータだけを見ているわけではなく、クラウド上の医療画像を備えた 1 つの共通データセットまたはデータプラットフォームを持つことで、それを活用し、統一し、その上に構築するための統合された基盤を持つようになります。これについてもう少し深く掘り下げる価値があると思います。だからこそ、次のスピーカーが AWS HealthImaging についてさらに詳しく説明してくれることをとても嬉しく思っています。AWS HealthImaging のシニアプロダクトマネージャーである Jaron Nix に温かい拍手をお願いします。
医療画像処理の基本的課題：DICOMデータ構造とメタデータ階層
皆さん、こんにちは。Jaron Nix です。AWS のシニアプロダクトマネージャーです。毎日、Philips のようなパートナーと一緒に、クラウド上の医療画像をより高速に、より費用対効果の高い、そして非常にシンプルにするために取り組んでいます。今日は、ペタバイト単位の医療画像データを扱う Philips のようなお客様がクラウドワークロードをより効果的にするために、私たちがどのようにサポートできるかの例を説明します。
医療画像処理における基本的な課題はこういうことです。特定の患者さんの画像が必要になります。例えば Alice さんと Bob さんがいるとして、Bob さんのデータは他のデータと関連しています。ですから Bob さんの病理検査の生検データが欲しいし、それから過去のある時点での T2 axial MR のような履歴データも引き出したいわけです。 一見すると、これは比較的シンプルに見えるかもしれませんが、2つの暗黙的な要件があります。データは、それがどれだけ昔に必要だったとしても、1秒以内にロードされる必要があります。 そして、 Philips のスケールで運用している場合、ペタバイト単位で、そして数億個、あるいは数十億個の画像にまで及ぶデータを取得する必要があります。
医療画像として私たちが考えるものは、通常、一連の画像であり、これらは画像はメタデータを通じて互いに関連しています。メタデータは患者名、それが取得された日付、それを取得した modality などです。そしてメタデータには他にも多くの臨床的背景情報があります。これらの各画像には数十万の属性が付属しています。使用された電圧やテーブルの高さなど、あらゆるものを持つことができ、これは放射線科医や一般的には医師に重要な臨床的背景を提供します。
医師として画面に実際に見えているものは、どこかのデータセンターに保存されているファイルです。これらがファイルとして、そして別々のファイルとして保存されている理由は、DICOM は比較的古い標準で、今から30年から40年前のものであり、元々はネットワーク標準として設計されたからです。modality 間でデータをどのように送信するか、golden copy storage に、医師の viewport に、そして機関間で送信するか、という話です。私たちはこの標準を流用してこのデータを保存してきており、これはいくつかの複雑さをもたらしてきました。CT スキャナは通常、データを段階的に収集します。スライスを再構成し、そのデータが準備されると、PACS に送信しています。これがどのように非常に複雑になる可能性があるかについて、いくつかの例を説明します。
デジタルラジオロジーの最も古い modality があります。X線です。例えば、毎回の検査、つまり病院を訪れてデータを取得する必要があるたびに、X線は通常、側面図と正面図です。胸部 X線はこの良い例です。互いに関連しているいくつかのファイルがあり、これが医師が実施されたばかりの検査の包括的なビューを持つために必要なすべてです。
PET、CT、MR のような体積データを持つより現代的な modality は数百の画像であり、検査は しばしば両方を組み合わせることができます。ですから PET CT は一般的なデュアル modality 検査であり、データはより大きくなり、互いに関連しているすべてのファイルが数百個あり、すべてクラウドデータストアの個別のオブジェクトとして、またはオンプレミスのファイルシステム内のファイルとして保存されています。そして、その後、digital pathology のようなより現代的な modality があります。 ギガピクセル画像です。つまり、がん組織、組織標本をイメージングし、ガラススライドに取り付けて、このデータをマイクロン解像度でイメージングしています。これが重要なのは、プレゼンテーション全体を通じてこれに触れるからです。データのカーディナリティは、ファイルが少ないということですが、これらのファイルは巨大です。イメージングしている解像度に応じて、通常は1ファイルあたり最大4ギガバイトで、特に20倍または40倍の対物レンズ倍率でイメージングしている場合、各ファイルには10万個以上の画像が含まれています。これは課題を提示します。その膨大な画像に含まれている特定のデータを、医師が確認するため、病理医が確認するためにクライアントに1秒以内で取得するにはどうするかということです。
では、ここで小規模な例を見てみましょう。つまり、Alice の 9 月に撮影された CT スキャンを見つける必要があります。 ここに 4 つのファイルがあり、DICOM 標準がこのデータをどのようにナビゲートするかを説明していきます。これら 4 つの画像が異なることは非常に明確に見ることができ、過去の例から、このうち 2 つが Bob のものであることがわかっています。そこで、ファイルを読み込んでメタデータヘッダーを確認することができます。DICOM ではメタデータとピクセルは決して分離されないからです。
2 つは Bob のものです。ファイルを読み込んでメタデータヘッダーを確認することができます。DICOM ではメタデータとピクセルは決して分離されないからです。すべての画像には重要な臨床情報が付属する必要があります。患者を確認して、これが Bob であることを判断できます。したがって、これは一致しないので、先に進むことができます。 階層を下って study を確認します。これら 2 つは同じかもしれません。例えば、Alice が病院を訪れて、CT 機械に横たわる直前に胸部 X 線撮影を受けた可能性があります。その後、メタデータ階層をさらに掘り下げて、series 属性で一致させます。 1 つは X 線で、もう 1 つは CT であることがわかりますが、問題はそこで終わりません。CT データは、私が述べたように、ボリュメトリックであり、このメタデータは、例えば、データの世界に 500 個以上のインスタンスがあることを示します。 これは数百万の患者、ペタバイト単位のデータ、そして潜在的には数十億のオブジェクトにわたっています。では、医師に必要なデータを迅速に、かつコスト面で銀行を破産させることなく提供するにはどうすればよいでしょうか。サンプルアーキテクチャを説明します。これは 通常、当社の顧客がこの問題にアプローチしている方法です。これは DIY アーキテクチャであり、この問題への平均的なアプローチを表すことを意図しています。S3 から始めます。S3 はバイトを高い耐久性で保存し、それらを取得するための優れた製品ですが、DICOM リソース階層が難しいのです。メタデータを患者に関連付け、ピクセルへの高速アクセスを提供することです。これらのオブジェクトのどれがどの患者に属し、どのシリーズに属しているかをどのように知ることができますか。Lambda から始めるかもしれません。Lambda は新しいオブジェクトがバケットに書き込まれたときに検出し、 ファイルを取得してメタデータヘッダーを解析し、RDS などのリレーショナルデータベースに挿入します。しかし、RDS だけではこの階層をナビゲートするのに十分ではありません。例えば、John Doe と Doe, John は同じ患者です。RDS はそれを理解しませんが、OpenSearch のようなマネージドサービスは理解します。セマンティック検索を提供します。 調整が必要な患者名があるとしましょう。Lambda や Step Functions などのサーバーレスサービスを使用して、調整が必要なデータを取得し、メタデータヘッダーを編集し、バケット内のオブジェクトを upsert することができます。 医療画像は 30 年または 40 年前からデジタル化されています。これらの画像の多くは、Web ブラウザーと互換性がなくなった方法で圧縮されています。ピクセルデータの多くが破損している可能性があります。これは 30 年または 40 年間このデータを保存することの残念な部分です。Fargate を使用してこのデータを取り込むことができます。取り込むとは、ピクセルデータが破損しているかどうかを検出することを意味します。その場合、通知してから、それを修正できるソフトウェアを構築します。また、レガシーデータを再圧縮します。例えば、数十年前の非圧縮データや JPEG baseline またはその他のデータは、JPEG 2000 や high throughput JPEG 2000 などのより最新の圧縮コーデックである必要があります。そしてもちろん、相互運用性とデータ アクセスのための API が必要です。EC2、API Gateway、および Verified Permissions を使用します。これは、クラウド内の医療画像に対して十分なデータ管理層を提供する最も基本的なアーキテクチャです。これはデータ管理層に過ぎないことを忘れないでください。ビジネスロジックとアプリケーションロジックは、この上に構築される必要があります。このアーキテクチャがすべての顧客で繰り返されるのを見ると、これが正しい経験であるかどうか疑問に思い始めます。顧客から逆算して考えると、言及されていた差別化されていない重い作業は、これらの反復的なワークロードに対する正しい顧客体験ではないかもしれません。 答えは、AWS HealthImaging のようなドメイン固有のマネージドサービスである可能性があります。これは、顧客がデータを自動的に整理、正規化、調和させ、低レイテンシーと標準ベースの API インターフェースでそのデータをストリーミングするのに役立ちます。これは S3 ベースのアーキテクチャに置き換わります。これはクラウド内の医療画像のゴールデンコピーストレージを対象としています。 当社はこれらのサービスのバンドルを提供しています。例えば、取り込み：ペタバイト単位のデータをこのデータストアに高速で取得する必要があります。月単位でペタバイト単位のデータを取り込むことができます。また、モダリティからデータストアへの同期書き込みのためのストアもあります。臨床データの豊富な検索とデータ管理 API、および標準ベースのインターフェースを使用した高速取得を提供します。 ここで何が起こっているかを説明します。S3 からのデータが、前に提示したアーキテクチャと同様にサービスに取り込まれ、メタデータが自動的に検索インデックスに入力されます。画像フレームが再圧縮され、解析されて一意の ID が付与されるため、それらを直接取得できます。メタデータの単一の JSON を提示しており、これもバージョン管理されているため、これらの画像グループの履歴全体にわたるすべての変更の不変レコードが保持され、患者の人口統計を簡単に取得および更新できます。
AWS HealthImagingによるデータ管理の自動化とドメイン固有サービスの価値
例えば、患者名の変更などのこれらの更新は、このコンセプトを更新するときに、データストア内のすべての関連オブジェクトに反映されます。これについては次のスライドで紹介します。このイメージセットを更新すると、調和されたメタデータがデータストア内のすべての関連オブジェクトに患者名の変更を反映します。
当社の例に進むと、AWS HealthImaging が行うことは、Alice という患者 コンセプトを作成することです。study date と modality などの関連メタデータを取得し、画像を image set と呼ぶ 1 つの AWS リソースにグループ化します。image set は、アクセス制御を実行し、image set メタデータを変更し、それを削除する場所です。次のスライドでこれがどのように見えるかの例を示します。
また Bob もいます。Bob がデータストアに 2 つの study を持っていることがわかっています。彼が MR を受けたことがわかっており、Alice の CT で行ったのと同じことを行います。 これらを一緒にバンドルします。また、彼が pathology を受けたことがわかっており、 これらすべての pathology フレームから image set を作成します。この例では、これは 100,000 フレーム以上であり、これは実際には pathology モダリティではかなり小さいです。これらのフレームに UID を付与します。私が述べたように、その理由はここにあります。
病理学は非常に大きな分野です。これまでにも述べてきましたが、病理学においてピクセル データにアクセスする方法はおおよそこのような感じです。病理医の仕事は、夜空の中から一つの星を探すようなものであり、それを非常に素早く行わなければなりません。アルゴリズムも同じようなことをしています。つまり、アクセスパターンは予測不可能です。ギガバイト単位のデータ、数十万のフレームがあり、高速アクセスが必要なのです。
AWS HealthImaging がこのデータを整理する方法は DICOM 階層構造であり、私たちはこれを正規化されたメタデータと呼んでいます。例えば、最上部に患者の概念があり、研究情報、シリーズ情報、そしてインスタンス内に含まれるすべてのイメージフレームが image frame get API を通じて直接アクセス可能なので、このデータをクライアントに素早く届けることができます。フレームをバッチでリクエストすることができ、各フレームはおよそ 200 ミリ秒でクライアントに配信されます。
AWS HealthImaging が皆さんにできることは、ファイル操作をバイパスし、AWS 上で独自のアーキテクチャを使用してこれらのオブジェクトを自分たちで管理することを避けることです。このサービスは、皆さんがアプリケーション開発をより迅速に進められるように存在しています。私たちは、お客様が優れた患者ケアと差別化された機能に焦点を当て、AWS HealthImaging のようなマネージドサービスを活用することを望んでいます。私たちはヘルスケアデータのプラッピングの面倒を見ます。基礎となるヘルスデータ機能を運用します。
これは AWS HealthImaging に限った話ではありません。私たちは 多くのドメイン固有のヘルスケアおよびライフサイエンスのマネージドサービスを持っています。例えば、FHIR 形式で患者記録を保存するための AWS HealthLake、ゲノミクスストレージとバイオインフォマティクスワークフロー用の AWS HealthOmics、DICOM ストレージと低遅延検索用の AWS HealthImaging、医師と患者の相互作用からノートを生成する AWS HealthScribe などです。 私たちはパートナーが構築するための基盤を提供し、スケーラブルなデータサービスを提供しています。私たちのお客様、そして最終的には患者である最終顧客です。これは高度に専門化されたソフトウェアと高度に規制された分野によって実現されています。私たちはパートナーを通じて患者への影響をもたらします。
Philipsのヘルスケア・インフォマティクス：ベッドサイドから始まる共創イノベーション
このことについて Philips ほどよく語ることができる人はいません。Wilson To をステージに招待して、彼の部分について話してもらいます。皆さん、こんにちは。この部屋に多くの見覚えのある顔を見ることができて素晴らしいです。昨年以来、実際に私たちのヘルスケア インフォマティクスポートフォリオ全体で行っている仕事についての講演をしてから、本当に長い時間が経っています。今日は、もう少し深く掘り下げて、パートナーシップを通じてチームが成し遂げてきた進歩を本当にショーケースし、私たちが取り組んでいる患者と臨床医のために何をしているのかについてもっと深く掘り下げることができて嬉しいです。
Philipsについてあまり詳しくない方もいるかもしれませんが、赤ちゃん用のボトルや浴室の歯ブラシなど、見たり聞いたりしたことのあるブランドだと思います。ただ、今日は私たちのヘルスケア・インフォマティクス・ポートフォリオ全体についてもう少し詳しくお話しします。良くも悪くも、病院に行ったことがあれば、デバイス、モダリティ、あるいはソフトウェアの観点から、Philipsというブランドを見たり聞いたりしたことがあるはずです。
Philipsの中核的なミッションは、世界中の25億人の生活と幸福を改善することです。毎年それが私たちの目指すところであり、私たちはそのためのミッションを遂行しています。実は、私たちは大きな進展を遂げています。実際のところ、米国のトップ100病院のうち95の病院がPhilipsのヘルスケア・インフォマティクス・ソリューションを使用しています。実は、トップ250病院のうち82%も同じことをしており、それは私たちが持つ多くの異なるモダリティにまたがっています。
放射線科のような専門分野では、放射線科医と協力して、ピクセルが何を意味するのかをより良く理解し、それをサービスすることで、彼らの生活をより簡単にするのに役立てています。
これはまた、例えば心臓病学のすべてに広がっており、心臓病学パッチシステムと協力して、チームが参加して見ることができるビジュアライゼーションとエコーを提供し、それをクラウドに移行しています。Jaredが言及したように、そして以前チームが言及したように、私たちは病理学でもそれを行っています。ガラススライドを扱い、その基本的なシフトをクラウドに移行させ、デジタル化することは簡単なことではなく、それは私たちがポートフォリオ全体にわたって推し進め続けていることです。
ピクセルデータであれ、急性期医療スペースの一部のソリューションが提供するような波形データであれ、私たちはAWSと非常に密接に協力して、病院全体のデジタル変革が、私たちの臨床医が一緒に取り組んでいるノートを変え、シフトさせるものになることを確認しています。私たちはそこで止まりません。実際のところ、私たちがどのように革新するかは、皆さんの多くが革新する方法や、AWSが革新する方法と非常に似ており、それは本当に顧客から始まり、そこから逆算するのです。私たちにとっては、実は臨床医と患者とのやり取りがさらに多く、私たちは実際にベッドサイドから始まり、そこから逆算するのです。
これが重要なのは、世界中の長年のクリニカルパートナーとどのように考え、どのように協働するかを考慮に入れているからです。臨床医、看護師、テクノロジスト、IT チーム、そしてあらゆるスタッフと肩を並べて協働するためです。共創と共イノベーションという観点から考えると、世界中のすべての病院とヘルスシステムとのパートナーシップは、そのテーブルにいるすべての人よりも長く続きます。このタイプの関係とパートナーシップの焦点を強調することで、私たちが行っている仕事の種類が本当に明確になります。デザインとテクノロジーに焦点を当てるのではなく、すべての臨床医が有用なソリューションで経験することになる体験に本当に焦点を当てているのです。
それが時間とともにどのように進化するかを考えると、単にクラウドで同じシステムを実行しているだけではなく、物事がどのように行われているかを再発明するチャンスがあります。これは、臨床ワークフローが時間とともに変化し、無限のコンピュートまたは無限のストレージにアクセスできれば、物事を異なる方法で行うことができるという考えとともに変化するという事実に基づいています。今日、AI アルゴリズムと AI モデルをどのようにデプロイするかを考えると、過去 10 年から 20 年間存在していた既存のワークフローを単に拡張して配置するのではなく、AI ファーストの考え方と臨床医の考え方を念頭に置いて、臨床ワークフローをゼロから再考し、今は異なる方法で物事を行うことができるようにするのです。
20年のパートナーシップ：134ペタバイトのデータをクラウドへ移行
AWS との協働の方法について少し共有しようと思います。これら 3 つの柱が AWS との私たちのすべての仕事を支えており、これは一夜にして起こったものではありません。実は、AWS との パートナーシップはほぼ 20 年にわたっています。2008 年、それが AWS と Philips が協働を開始した時です。それ以来、私たちは顧客のために非常に積極的にイノベーションを推し進めてきました。
2014 年と 2015 年に、Philips は実際に本番環境の医療ワークロードをクラウドに展開した最初の企業でした。そこから、私たちは実際にチームに、どのように共イノベーションを行い、異なる方法で設計するかについて考えるよう促してきました。顧客とホスピタルシステムがデータにアクセスしている領域や、AI アルゴリズムを実行するためにそのデータを表示している方法において、差別化されていない重い作業を取り除き続けるためです。この関係とパートナーシップは、実際には画面の右側に表示されている時点に到達するために、かなりの年数にわたっています。
Philips 内で enterprise informatics ビジネスが形成されてから過去 3 年間、私たちは実際に非常に積極的に、ヘルスケア情報ポートフォリオ全体をクラウドにシフトするために動いてきました。2023 年に、私たちは HealthSuite Imaging PACS をクラウドに展開し、150 以上のカスタマーサイトをクラウドに移行しました。病理学についても同じことが言えます。私たちは、ヘルスイメージングの使用のようなこれらの機能を持つことが何を意味するのかを理解しようとする道を進み始めました。異なるタイプのアクセスパターンについて考えるために、私たち自身でそれについて心配する必要がないようにするためです。そして Predrag がそれについてもう少し深く掘り下げるつもりです。
先週も Cardiovascular Workspace をクラウドで発表したばかりです。つまり、突然のことですが、私たちのポートフォリオ全体がクラウドでアクセス可能になり、クラウドが顧客が実際にエンゲージし、インタラクトし、データに異なる方法でアクセスできるようにするためのバックボーンになったわけです。その中で、私たちが統合診断の観点で行っていた取り組みの勢いを、完全に異なるレベル とスケールに押し上げました。
Darren が先ほど少し触れていましたが、統合診断という観点で私たちが持つ情報学スタック全体がクラウドにあります。それが私たちと顧客にとって意味することは、134 ペタバイトのデータがクラウドにシフトされ、顧客がこれまでできなかった方法でデータにアクセスし、処理し、計算し、送信することができるようになったということです。その 134 ペタバイトのデータの背後には、時間とともに増え続ける 3,400 万件の患者検査があります。移行したすべてのサイトは、パートナーシップが私たちのために生み出した勢いを構築するために、私たちと非常に密接に協力し続けています。
私たちの中核的なミッションの根本を考えるとき、年間 25 億人の命にどのようにインパクトを与え、健康と幸福を改善するかを問います。ソフトウェアは私たちがスケールすることを可能にし、クラウドは私たちがスケールすることを可能にします。その 134 ペタバイトのデータの背後には、患者がどのように臨床医と異なる方法で治療されるかに対応するのに役立つ 110 億件の医療記録と画像があります。ズームアウトすると、Sam がこのスライドを先ほど示していましたが、 医療機器と医療ケアのスペースは完全にデータ駆動型です。前のスライドで私が言及したすべてのことは、データ、ビットとバイトについてのすべてであり、私たちはすべてのビットとバイトの背後に患者がいることを理解しています。
Philips の方向性と医療情報学ポートフォリオを結びつける方法は、統合診断のレンズを通じてです。私たちは、臨床医が単一のペインオブグラスを通じてアクセスし、意思決定をより簡単にするのに役立つさまざまなタイプのデータ要素を見ることができる未来を見ています。左下隅のボックスでは、Sam がこれらが重要なコンポーネントであることを述べていますが、それはモダリティがどのようにクラウドにシフトするか、そしてそれらの重要性についてです。それはまさにあなたが前のスライドで見たもので、私たちのポートフォリオのさまざまなシフトをクラウドに発表しました。
結局のところ、それが意味することは、Philips が病院とそれらのスペース内のすべての部門と協力するとき、生物学的信号をデータに変換する仕事から、そのデータが異なるデータサイロを超越し、臨床医がデータを異なる方法で見ることができるようにする方法へとシフトしているということです。臨床医が患者について良い全体像を得るために 16 の異なるシステムを立ち上げる必要はありません。私たちのソリューション、方向性、統合診断のビジョンを使えば、紹介元の臨床医であろうと腫瘍医であろうと、画面の左側のすべてをオーバーレイできるワークスペースが見えます。
放射線科のモダリティであれ、病理スキャナーであれ、そのすべてが臨床医が患者を異なる方法で見ることができるようにオーバーレイされることができます。このデータの融合は、臨床医が患者にとって最良の治療計画が何であるかを把握するために協力する際の臨床医間の議論だけでなく、臨床医と患者の間の会話も、異なるタイプの議論を生み出します。それを踏まえて、私たちは治療をどのように異なる方法で行うことができるかを考えます。データ駆動型イメージングモダリティがどのように本当に異なる治療計画に変換されるかについて、臨床医を再考し、装備し、可能にする方法を見ています。
それを念頭に置いて、自宅であれ病院であれ、患者の監視と監視がどのように行われるかについて考えます。それはすべて、今日の病院での臨床医の行動と運営方法を再考し、さらに重要なことに、放射線科、心臓病学、または病理学の異なるスペースへと進んでいく彼らの将来を再考することになります。それでは、Predrag に舞台に上がっていただいて、特に病理学の分野についてもう少し深く掘り下げていただき、クラウドへの私たちの取り組みについて詳しく説明し、さらに重要なことに、統合診断にどのようにアプローチしているかについて説明します。
統合診断が実現する臨床ワークフローとデータ統合の革新
ありがとうございます、Wilson。皆さん、こんにちは。まず最初に、申し訳ございません。少し体調が悪いので、声がかすれたり、マイクに咳をしたりしたら申し訳ございません。私の名前は Predrag Angelovski です。Philips Healthcare Informatics の Chief Technology Officer です。本日は、統合診断についてお話しする時間をいただきたいと思います。それが何を意味するのか、そして実際にそれが病院、患者、そして精密医療の未来の両方にどのように影響するのかについてです。その後、病理学ソリューションについてもう少し深く掘り下げ、AWS HealthImaging が実際にどのように私の同僚が話していた負担の一部を取り除き、臨床的価値と臨床的イノベーションに本当に焦点を当てるのに役立つかについて説明します。
アーキテクチャについてお話しし、なぜ私たちが最善を尽くすことに焦点を当てるべきなのかを説明したいと思います。それは、臨床医が患者を支援するための最良のツールを提供することであり、データをどこに保存するか、データライフサイクルをどのように管理するか、ホットデータとコールドデータをどのように保つかについての質問で彼らに負担をかけることではありません。そう言った上で、まず統合診断についてお話しする時間をいただきたいと思います。なぜなら、ここで何度も聞いた言葉だと思うからです。表面的には、非常にシンプルなことです。統合診断について考えるとき、あなたは一束のソリューションが一緒に機能するシステムについて考えています。
しかし、統合診断について本当に考えるとき、放射線科、心臓病学、デジタル病理学が半ば孤立したサイロで機能し、ポイント・ツー・ポイント統合とデータ移動によってつなぎ合わされているようなシステムとして考えるべきではありません。統合診断について話すとき、本当に重要なのは、これらすべての分野が統一されたファブリックの中で一堂に集まり、放射線科データ、心臓病学データ、病理学データ、そして他のあらゆるイメージングモダリティからのデータを含む、患者の縦断的なビューを提供することです。デジタル病理学は、これらすべてをまとめる重要な要素です。
例えば、画像診断の決定の70%はデジタル病理学データに基づいて行われています。腫瘍またはがん診断の100%は、適切な診断と治療を定義するために、何らかのレベルのデジタル病理学を必要とします。しかし病理学は、専門分野の中で最後にデジタル化されました。放射線科は数十年前にデジタル化され、心臓病学もすぐに続きましたが、病理学は常に困難で面倒なものと見なされていました。病理学スライドは放射線科検査の10倍から20倍のサイズです。スライドは大きく、単純に病院内のオンプレミスに適切なアーキテクチャと適切なリソースがなかったのです。
最近のテクノロジーの進歩、特にクラウドの進歩により、デジタル病理学ソリューションを開発することが可能になりました。私たちが参入することで、ようやく適切な統合診断ソリューションを構築することができます。では、これは病院と臨床医の仕事にとって何を意味するのでしょうか。トピックの対象となっているこれらのレイヤーのいずれかに、今日の仕事のやり方とは異なる一定の影響があります。
ワークフロー層を見ると、今日、複数の分野からの画像を持ってきて見たい場合、異なるシステムを操作するか、スクリーンショットを撮るか、プリントアウトするか、異なるレポートでオフラインでデータを共有するかのいずれかに依存しています。放射線科と病理学のデータを並べて見ることができる統一されたビューアを持つことで、臨床医はより良い情報を得ることができ、より良い決定を下すことができます。ワークフロー層をもう一度見ると、今では専門分野を超えたワークフローを持つことができます。デジタル病理学のトリガーを放射線科医または次のタスクを実行しようとしている医師に直接送信することができます。
今日、それは非常に面倒でエラーが起きやすいポイント・ツー・ポイント統合か、患者記録またはメモを回す手動ステップのいずれかです。同様に重要な要素の1つはインフラストラクチャにあります。4つ、5つ、6つ、または7つの異なるソリューションを管理する代わりに、異なるソフトウェアアップグレード、異なるデータベースソフトウェア、異なる標準、異なるネットワーク要件を持つ代わりに、今はより管理と運用が簡単な1つの統合ソリューションで作業することになります。
最後に、データについてです。これは最も過小評価されているものです。今日、データはサイロ化されています。放射線科のデータは PACS に存在し、心臓科のデータは心臓科ソリューションに存在し、病理学のデータはデジタル化されていれば独自のソリューションに存在します。意味のある研究を行ったり、特にモダリティ横断的に意味のある AI モデルを開発したりしたい場合、本当にそのデータをコピーすることに依存しています。複数のソースからそのデータを持ってきて、実際にそれらの操作を実行する新しい場所に統合する必要があります。
統合診断では、データが一箇所に存在し、単なるデータだけでなく、メタデータも一箇所に存在します。すべてが接続され、よく説明され、事前に定義されています。ですから、マルチモーダル AI モデルのトレーニングのようなことは、データへのアクセスがあるため、はるかに簡単になります。では、Philips の Enterprise Pathology ソリューションについて説明する前に、私が皮肉を込めて「スライドの物語」と呼ぶこのスライドにお連れしたいと思います。以前の方、または私の同僚の一人が言及したように、スライドはガラスの一片で、生検後、技師または病理医がサンプルをそこに置き、それを一緒に塗抹して、それがその手順の唯一の真実になります。スライドが破損すれば、すべてが失われます。スライドがより高い湿度に曝露されれば、それは失われます。ですから、そのスライドは文字通り、プロセスの下で起こるあらゆる発見またはあらゆることの唯一の証拠です。
「スライドの物語」：手動病理学からデジタル病理学への劇的な時間短縮
スライドが取られたら、特に手動病理学では、そのスライドを準備する必要があります。すべてのスライドには、患者と何であるかを識別するハードラベルが付けられる必要があります。もちろん、すべてがスライドの上にあるわけではありませんが、参照でラベル付けされています。その後、品質管理があります。スライドが適切に塗抹されたか。サンプルが適切に準備されたか。その後、おそらくすべてがトロリーに積み込まれます。十分なスライドがあると、プロセスの次のステップに移動されます。
その後、病理医の仕事が来ます。今日の病理医の仕事は顕微鏡を通して見て、干し草の中から針を探そうとすることで、彼らはこれに非常に優れています。しかし、それでもなお、非常に困難で退屈な仕事です。興味深い部分を見つけることが難しいだけでなく、分析を行うと同時にレポートを書くことができないからです。
つまり、彼らはメモを取るわけです。頭の中でか、それとも紙に書くか、どちらかです。そしてその後、分析を続けていきます。電子顕微鏡でずっとズームインしていくんですね。測定は手動で行ったり、まあ、電子顕微鏡でサポートされながら行ったりします。そして最後に、レポートを書かなければなりません。それまでに行われたすべての作業、取ったすべてのメモ、見たことを覚えているすべてのこと、それらをレポートに書くわけですが、これは画像とは繋がっていないんです。ご想像の通り、これはエラーが起こりやすいだけでなく、非常に効率的ではありません。
Digital pathology はこれを非常に根本的な方法で変えます。スライドが塗られて準備ができた瞬間、スキャナーに入ります。これらは高性能なスキャナーです。そしてスライドがデジタル化された瞬間、それは cloud native imaging fabric の一部になります。メタデータで豊かにされます。AI アシストされたアルゴリズムが自動測定と測定の取得を開始します。
他の Philips と第三者のアルゴリズムがあり、それらは染色を支援したり、識別とカテゴリ分けを支援したりします。そして自動的なプレ品質管理を行うアルゴリズムもあります。つまり、スライドが次のステップに到達する前に、つまり品質管理に到達する前に、スライドに対してすでに多くの作業が行われているということです。これは技術者を支援し、その後に続く病理医が実際に彼らの作業を実行するのを支援するためです。
品質管理は以前に行われた AI アシストされた管理の検証になります。そしてその作業は即座に、ほぼ即座に病理医が利用できるようになります。即座にと言いましたが、まあ、ほぼ即座にですね。常に何らかの時間がかかります。病理医の作業が最もポジティブな影響を受けるものです。
顕微鏡でズームインとズームアウトをする代わりに、彼らは高解像度画像のスクリーンを見ています。AI のおかげで、彼らはスライドを引き出し、特定の領域にフォーカスし、スライドの異なる領域間で簡単に切り替えることができます。それだけではなく、彼らはブックマークを取ることができ、メモを追加することができます。スライドと並行してレポートを書くことができるんです。
彼らはレポートを書くだけでなく、実際のデータソースを見ながら書いているわけです。そしてブックマークのおかげで、レポートをスライドに直接リンクさせることができます。つまり、レポートを読んでいるときに、すべてが同じプラットフォーム上で動作しているので、異なるブックマークをクリックして、直接ソース・オブ・トゥルースにズームバックすることができるんです。
そして最後に、効率性です。これは私たちがずっと言ってきたことです。ひっ迫した医療システムの中では、1分1秒が大切です。平均的な手動デジタルパソロジーワークフロー、複数の調査からの平均値ですが、スライドからレポートまでに約11時間35分かかります。これの多くは、スライドの手動での移動、手動でのメモ、そして複数のスライドを集めて前に進める必要があるからです。
デジタルパソロジーでは、これが36分に短縮されます。これは非常に重要な時間短縮です。単なる効率性のためだけではなく、これはパソロジストがより多くのケースを処理でき、より多くの人々を助けることができるようになり、サンプル採取から潜在的な診断までの時間を短縮することができるということを意味しています。そして特にデジタルパソロジーでは、1分1秒が大切なんです。では、Philips Enterprise Pathology Solutionとは何でしょうか？
Philips Enterprise Pathology Solution：AWS HealthImagingを活用したクラウドネイティブアーキテクチャ
Philips Enterprise Pathology Solutionはソフトウェアではないということが重要です。Philips Enterprise Pathology Solutionはスライドからレポートまでの完全なソリューションです。私たちは1分以内にDICOM whole slide imageを生成する高性能スキャナーを製造しています。これは、ルールやAIアルゴリズムに基づいて人々がこのデータを次の適切なステップに移動させることを可能にする、完全に自動化されたワークフローとワークリストをサポートするバックエンドと統合されています。
自動品質管理と測定、および事前診断とカテゴリ化のためのAIアルゴリズムがあります。これは他の検査室情報システムとEHRと完全に統合されています。そして最後に、このデータを使用してAIをトレーニングし、それをシステムに戻してデプロイすることができる他のシステムと統合されています。これはAWS上に完全に構築されたクラウドネイティブソリューションであり、私たちのパートナーのおかげで、これは精密診断とデジタルパソロジーの未来だと思っています。
アーキテクチャについてお話しするために、スライドと提示されたすべての内容に戻りますが、3つのことに焦点を当てます。それは、ingestion、storage、clinical diagnosis and review、そして tumor boards と secondary clinical use cases です。Ingestion に関しては、先ほど申し上げた通り、Philips は非常に高性能なスキャナーを持っており、1分以内に whole slide images を生成します。これは大したことのないように聞こえるかもしれませんが、先ほど示された数字と比較すると、スキャナーあたり1分間にほぼ1ギガバイトのデータが生成されることになります。病院は10台以上のスキャナーを運用しており、複数の施設を持つ病院もあります。私たちのエコシステムには数千の病院が存在する可能性があります。
このすべてのデータを ingestion できるスケーラブルなアーキテクチャが必要です。そのため、私たちは AWS HealthImaging とのパートナーシップを決定しました。AWS HealthImaging は ingestion の負担を完全に取り除いてくれます。私たちはデータを S3 バケットに直接ストリーミングし、AWS HealthImaging がそのデータを消費します。AWS HealthImaging が実は DICOMweb インターフェースを持っているのに、なぜ間に S3 バケットを置くのかと疑問に思われるかもしれませんが、pathology のデータサイズの場合、データが転送中に破損する可能性があり、メタデータが変更または破損する可能性があるため、実際にはクラウドにデータをまずステージングする方が良いのです。
スライド画像のスキャン中に何か問題が発生した場合、ハードウェアに戻って探し出して再度アップロードするよりも、1つの場所にデータがあって何が起こったのかを把握できる方が私たちにとって良いのです。例えば、メタデータの再アップロードやメタデータの修正だけが必要な場合はなおさらです。もう1つの重要な部分は lifecycle management です。AWS HealthImaging は実は私たちに完全な hot と mid-tier storage を提供しています。つまり、必要な画像が常に最高の速度で利用可能であることを保証してくれるということです。
次のセクションで consumption についてもう少し詳しく説明しますが、このサイズのデータを扱う際の大きな問題の1つは、どの画像がいつ必要になるのかが決してわからないということです。すべてを非常に hot storage に保存しようとすると、非常に難しくなります。データは大きく、コストがかかります。AWS HealthImaging はこの問題を私たちから取り除いてくれます。これは抽象化レイヤーを追加し、私たちが何を要求しても、常に特定の速度で取得できるようにしてくれるのです。
最後に、他の AWS サービスのおかげで、実は私たちはソリューションの残りの部分を完全にステートレスになるように設計しました。私たちのロジックのほとんどは containers で実行され、残りは Lambda で実行されます。患者のメタデータストレージの一部には Aurora Serverless を使用しています。つまり、AWS のパートナーとともに、私たちは事実上無限にスケーラブルなシステムを設計・構築しているということです。これが重要な理由は、データが大きいだけでなく、患者の数も増加しているからです。今日だけでなく、明日、そして将来にも十分なシステムが必要なのです。
では、臨床診断とレビューについて、もう一度確認しておきたい重要なポイントが2つあります。
1つ目はタイル消費です。タイルというのは先ほど説明したもので、スライド全体を見ると、AWS HealthImagingによってインデックス付けされた、ズームイン画像を表す小さなボックスがあります。任意のスライドから任意のタイルをリクエストすると、200ミリ秒以下の応答が得られます。つまり、病理医はスライドをどんなスピードでクリックして進めても、画像の読み込みに遅延を感じることはありません。
もう1つの部分はライフサイクル管理に関わっています。AWS HealthImagingにスライドをアップロードすると、メタデータもアップロードされます。その後、AWS HealthImagingはデータが適切なストレージ層に移動されることを保証します。Glacierなどの他のAWSサービスのおかげで、このデータをアーカイバルストレージに移動することもできます。病理データは診断が下された時点では重要ですが、将来的に臨床医が腫瘍が進行したかどうか、何かが変化したか、成長したか、新しい特徴が発生したかを評価したいときにも重要になります。データは常に重要ですが、その量のデータをホットストレージに保持することは実質的に不可能です。
AWSとAWS HealthImagingの他のネイティブAWSサービスとの統合のおかげで、S3、AWS HealthImaging、そしてアーカイブ用のGlacierなど、異なるストレージ層にデータをスマートに移動するワークフローを設計できます。極めて重要な臨床診断の側面では、AWS HealthImagingとAWS Security Token ServiceやAWS Identity and Access Managementなどのサービスとの統合により、ゼロフットプリントビューアを実現できます。クライアントはソフトウェアをインストールする必要がなく、すべてウェブベースです。私たちのソフトウェアはAWS HealthImagingに直接アクセスしてこれらの画像を取得します。
これは複数の理由で重要です。デジタル病理では、複数の病理医がリアルタイムでデータにアクセスでき、クラウドベースであるため、リアルタイムで協力することができます。異なる地域の病理医が互いに協力することができます。米国の病理医がオランダの病理医にアドバイスを求めることが実際に可能です。今日、それをしたいのであれば、物理的にスライドを移動する必要があります。スクリーンショットを送ることはできますが、そうすると「そこのスクリーンショットを送ってもらえますか？これのスクリーンショットを撮ってもらえますか？この領域にズームインしてもらえますか？」という質問になってしまいます。しかし、セカンドオピニオンを得たいのであれば、物理的にスライドを移動する必要があります。AWSのクラウド上のデジタル病理により、臨床医間の協力をシームレスで効果的にすることができます。
統合診断ワークスペースでは、放射線科医が病理データを見ることができ、心臓専門医も病理データを見ることができるという同じ機能があります。病理について戻るのは、放射線科は画像をくれるけれど、病理が真実をくれるからです。細胞の形が悪いものや腫瘍は見ることができますが、生検をするまでは、それが癌なのか、どのステージなのかは分かりません。病理は、統合診断ソリューション全体を結びつける接着剤なのです。
最後に、もう2つの重要な側面があります。研究についても少し話します。腫瘍ボードは、異なる分野の専門家がオフラインの会議で集まるプロセスです。患者のすべての記録を持ち寄って、その所見について議論し、治療と今後の診断という観点から患者にとって最善の進め方を決定します。今日、腫瘍ボードはオフラインの会議で、重要だと思うデータを持ち寄ります。データを忘れてしまったり、スライドから間違った画像を取ってしまったり、レポートに載っていないため準備ができていない質問を受けたりする可能性があります。
デジタル病理では、腫瘍ボードは完全にオンライン化され、完全にデジタル化され、完全に機能するようになります。レポート内のブックマークのおかげで、スライドにズームインすることができます。画像のデジタル化のおかげで、私たちは常に同じ情報源を見ています。最後になりますが、研究があります。データを1か所に置いて、複数の別々の場所にコピーする必要がないというのが、AWS HealthImaging が私たちにとって区別される点です。Amazon SageMaker などの他のシステムとそれを接続することで、そのデータを持ってきて、モデルをトレーニングまたは特化させ、そのモデルを評価してから、データがどこにあるかについて心配することなく、またそれを管理することなく、ソリューションに戻してデプロイすることができます。
デジタル病理学の臨床的インパクト：病理医100%が顕微鏡に戻りたくないと回答
では、これは病理医の仕事にとって何を意味するのでしょうか？
これは52人の病理医と検査技師を対象とした調査に基づいています。調査全体について説明するつもりはありません。皆さんが本日最後のセッションを終わらせたいというお気持ちはよく分かっていますから。調査対象となった病理医の100%が、デジタル病理を経験した後は顕微鏡に戻りたくないと答えています。デジタル病理と手動病理を比較すると、デジタル病理では約21%多くの症例が診断されています。調査対象となった病理医の100%が、デジタル病理はオンラインでのデジタルコラボレーションを可能にすることで、診断の合意形成に役立つと表明しています。
最後になりますが、本日ご議論いただき、デモンストレーションしていただいたすべてのことから、これが非常に複雑で難しいテーマであることをご理解いただけたと思います。複雑な分野では、すべてを一人で行うことはできません。それはすべてパートナーシップについてなのです。私たちはパートナーシップから始まりました。そしてパートナーシップで終わりたいと思います。Philipsは、私たちの臨床専門知識と臨床知識、高度に規制された環境での運営に関する理解、病院や臨床機関とのパートナーシップ、そして革新における長年の伝統をもたらします。
AWSは、私たちに安全でスケーラブルな環境をもたらし、継続的にイノベーションを進めています。必要なストレージを提供し、私たちの生活から複雑さを取り除き、私たちが得意とすることに集中することを可能にしてくれます。だからこそ、このようなソリューションは真のパートナーシップを通じてのみ実現可能なのです。それでは、お時間をいただきありがとうございました。ご質問がございましたら、喜んでお答えさせていただきます。皆様とお会いできることを楽しみにしております。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion