技術概要：PyHealth 2.0

問題定義

臨床深層学習研究は、再現性、アクセシビリティ、スケーラビリティに対する持続的な障壁に直面しています。標準化された 5 段階のパイプライン（データ処理、タスク定義、モデル初期化、トレーニング、評価）が存在するにもかかわらず、断片化された実装、異なるランダムシード、および機能停止した依存関係により、報告された結果はしばしば再現不可能です。主要な課題は以下の通りです：

• 再現性の危機： 研究者は、構造化された EHR コードなどの類似したデータモダリティに対して、頻繁にカスタム処理ステップを実装しており、これにより不整合なベースラインと煩雑な監査が生じています。
• 依存関係と互換性： 既存のリポジトリは、互換性のない、あるいは機能停止した依存関係に依存していることがよくあります。Docker は複製を提供しますが、単純な Python コーディングを超えたエンジニアリングのオーバーヘッドを追加します。
• マルチモーダルな複雑性と計算上の障壁： 臨床データは本質的にマルチモーダル（シグナル、テキスト、画像、EHR）です。MIMIC-IV のような大規模データセットには数億のイベントが含まれており、しばしば数百ギガバイトの RAM を必要とし、一般消費者向けハードウェアでのトレーニングを不可能にしています。
• ドメイン知識のギャップ： 機械学習研究者と臨床専門家との間に断絶が存在し、現実の臨床ニーズに対応するモデルの開発や、その関連性の検証を妨げています。

手法

PyHealth 2.0 は、臨床 AI 開発パイプラインを統合するために設計された、強化されたオープンソースの深層学習ツールキットとして導入されます。これは、モデルトレーニングとモデル評価の側面に整理された 9 つの主要モジュールからなるモジュラーアーキテクチャを通じて、前述の課題に対処します。

コアアーキテクチャ

このツールキットは、以下の分野でインターフェースを標準化することにより、予測モデリングのための「7 行のコード」ワークフローをサポートします：

1. pyhealth.data： 患者とイベントを中心にデータを整理する、柔軟な 2 層階層データ構造。他のスキーマとは異なり、日付やデータタイプに関する仮定を置かず、シグナル、画像、構造化 EHR をサポートします。
2. pyhealth.processors： 正規化、トークナイゼーションなどの迅速なデータ変換を PyTorch テンソルへ処理します。
3. pyhealth.datasets： Dask と Polars を使用した最適化された遅延読み込みソリューションを実装します。データは必要な場合のみメモリに読み込まれ、大規模データセットを効率的に処理するための並列タスク処理がサポートされます。
4. pyhealth.tasks： 入力/出力スキーマと呼び出し関数を通じて ML タスクを定義するための統一インターフェースを提供します。これにより、特徴量の含め方とエンジニアリングロジックが標準化されます。
5. pyhealth.models： モジュール性と PyTorch Lightning などの分散トレーニングフレームワークとの互換性を設計した、カスタム PyTorch モデル（RETAIN、StageNet、Transformers など）のライブラリです。

評価とトレーニング後

このツールキットは、標準的な性能指標を超えて以下を含むように拡張されています：

• pyhealth.metrics： 公平性、解釈可能性、不確実性の定量化を含む包括的な評価。
• pyhealth.interpret： 臨床モデル向けに調整された解釈可能性手法（Attention-Grad、GIM、DeepLift、SHAP）の直接実装。
• pyhealth.calib： モデル較正（Temperature Scaling、Dirichlet）とコンフォーマル予測による不確実性の定量化。
• pyhealth.medcode： 医療コーディング標準（ICD、CCS、ATC、RxNorm、NDC）間の翻訳とオントロジー検索。

設計哲学

PyHealth 2.0 は、モダリティ非依存のアプローチを採用し、EHR、バイオシグナル、画像、テキストなど多様なデータタイプを、個別の専用ツールを必要とせずに単一のフレームワーク内で統合します。既存の標準（OMOP、FHIR）およびフレームワーク（MEDS、MONAI）との相互運用性を維持しつつ、複数のツールを学習するオーバーヘッドを軽減する統一 API を提供します。

主要な貢献

本論文は、3 つの主要な貢献を概説しています：

1. 包括的なツールキット： 15 以上のデータセット、20 以上の臨床タスク、25 以上のモデル、5 つ以上の解釈可能性手法、および 5 つ以上の不確実性定量化手法を統合します。多様なモダリティをサポートし、単一のフレームワーク内で 5 つ以上の医療コーディング標準を翻訳します。
2. アクセシビリティ重視の設計： 以前のバージョンおよび素朴なベースラインと比較して、最大39 倍の高速処理と20 倍の低いメモリ使用量を達成します。これにより、専用サーバーインフラを必要とするのではなく、一般消費者向けハードウェア（例：16GB のノートパソコン）でのトレーニングが可能になります。
3. 活発なオープンソースコミュニティ： 400 人以上のメンバーからなるコミュニティが、広範なドキュメント、再現可能な研究貢献、および多言語サポート（RHealth を通じて）を提供し、ドメイン専門知識への参入障壁を低下させています。

結果

著者は、MIMIC-IV データセット（31.5 万人の患者、1 億 2400 万件の検査イベント）を用いて、死亡率予測、薬剤推奨、入院期間予測の 3 つのタスクにおいて、PyHealth 2.0 を PyHealth 1.16、MEDS エコシステム、および素朴な Pandas ベースラインと比較ベンチマークしました。

• 性能と効率： PyHealth 2.0 は大幅な高速化を示し、素朴な Pandas より最大39 倍の高速処理を達成しました。重要なのは、マルチワーカーシャードリングにより、ワーカー数の増加に伴ってもメモリ使用量が比較的一定に保たれたことです。
• ハードウェアへのアクセシビリティ： 顕著な結果として、16GB の MacBook Pro M2 Pro上で実行された PyHealth 2.0 は、ローカル NVMe SSD と NAS I/O ボトルネックおよび高いメモリ帯域幅の違いにより、死亡率予測タスクにおいて 32 コアのサーバーワークステーションよりも高速でした。MacBook はサーバー上の PyHealth 1.16 より35 倍少ないピークメモリを消費しました。
• コード削減： 患者データ探索に必要なコード行数は、PyHealth 1.16 の 14 行から10 行に削減され、タスク初期化はすべてのタスクで7 行に標準化されました。
• ベースラインの再現性： このツールキットは、EHR、画像、テキスト、EEG など様々なモダリティにわたってベンチマークを正常に再現し、ハイパーパラメータ調整なしで適切なアウト・オブ・ザ・ボックスベースラインを提供しました。

意義

PyHealth 2.0 は、アクセス可能で再現性のある医療 AIのためのオープンソース基盤を確立します。生データ処理から複雑な評価までのモデリングパイプライン全体を統合することにより、歴史的に臨床 AI 研究を妨げてきた技術的および計算上の障壁を低下させます。このツールキットは、臨床 AI での作業能力を民主化し、研究者がインフラ管理ではなくモデル開発に集中できるようにすることを目指しています。さらに、標準化され再現可能なコードを通じて技術的実装と臨床的関連性のギャップを埋めることで、運用可能なモデルの共有を促進し、AI 研究者と臨床専門家との協力を育むことを意図しています。本論文は、この基盤が、研究プロトタイプから展開可能で信頼性の高い臨床ツールへと医療 AI を進展させるために不可欠であると結論付けています。