Databricks Lakebase 上での FHIR ネイティブ ヘルス データ プラットフォームの構築

医療データは、EHR、請求、検査、薬局、SDoHなど、数十のシステムに存在し、それぞれ独自のフォーマット、コード、重複があります。この断片化された状況を、統一され、FHIR標準化され、信頼できるデータ基盤に転換することは、より良い成果、よりスマートな運用、規制対応に向けた重要なステップです。このブログでは、Health SamuraiとDatabricksが、オープンスタンダード上で、あらゆる規模のデータ基盤を構築するためのテクノロジーをどのように提供するかを説明します。

今日、インテリジェントなヘルスケアアプリケーションは、ビジネスの最前線にあるだけではありません。それらはビジネスを動かしています。ケアのギャップを積極的に埋めることから、リアルタイムのメンバーエンゲージメントを強化し、設計による規制遵守を確保することまで。しかし、これらのアプリケーションには、ほとんどの医療組織が構築に苦労してきたデータ基盤が必要です。それは、標準化され、ガバナンスされ、システム間でデータを移動することなく、スタック内のすべてのツールからアクセス可能なものです。

運用上のインテリジェンスと分析機能が統合され、真に相互運用可能になり、同じ洞察を推進できたらどうなるでしょうか？

課題：断片化されたデータ、断片化されたガバナンス

医療のデータランドスケープは、特異的に複雑です。患者情報は、HL7v2メッセージ、C-CDAドキュメント、X12トランザクション、および独自のフォーマットに分散しており、各システムは同じ臨床概念を異なる方法でエンコードしています。単一の診断が、複数のボキャブラリーにわたって複数のコードで表示される場合があります。単一の患者が、複数のシステムにわたって複数のレコードとして存在する場合があります。

このデータを統合するための従来の​​アプローチには、相互運用性のためのFHIRサーバー、分析のための別個のデータウェアハウス、およびそれらを接続するETLパイプラインのネットワークを構築することが含まれます。各システムは、独自のアクセス制御、監査証跡、およびコンプライアンス体制を維持します。

この重複はコストがかかります。同じ臨床データが、FHIRサーバー、ウェアハウス、および複数のステージングレイヤーに複製されます。それぞれがストレージ、コンピューティング、および運用オーバーヘッドを追加します。一方、FHIRサーバー自体がボトルネックになることがよくあります。ほとんどの実装は、トランザクションユースケース（ドキュメント交換、ポイントルックアップ、規制API）のために設計されており、何百万ものリソースを効率的にスキャンする必要がある最新の分析、MLパイプライン、またはAIエージェントのアクセスパターンには対応していません。

その結果、組織はトレードオフを強いられます。パフォーマンスを維持するためにFHIRインフラストラクチャを過剰にプロビジョニングするか、またはデータを利用可能にするために別のシステムにデータを抽出するかです。

結果は予測可能です。データの移動が遅く、ガバナンスが断片化し、AIイニシアチブが停滞します。モデルが、必要な場所で、クリーンで信頼性が高く、適切にガバナンスされたデータに確実にアクセスできないためです。コストが増加し、柔軟性が低下します。サイロ化され、一貫性がなく、ガバナンスの不十分なデータの上にインテリジェントなケアアプリケーションを構築することはできません。

ビジョン：1つのデータセット、すべてのツール、データ移動なし

臨床データが入力時にFHIRに標準化される単一のプラットフォームを想像してみてください。その同じデータが、移動や変換なしに、Spark分析、MLモデル、AIエージェント、およびBIダッシュボードですぐに利用可能になります。コンプライアンスが個別のワークストリームではなく、アーキテクチャの自然な特性となる場所。EHRからデータサイエンティストのノートブックまで、すべてのツールが同じガバナンスされた信頼できるデータを確認できる場所。

これは、Health SamuraiとDatabricksが共に構築したものです。

仕組み：Health Samurai

集約と標準化

データ品質の最初の1マイルが、洞察の最後の1マイルを決定します。Health Samuraiは、多様なソースからデータを収集し、統一されたFHIRネイティブのデータ基盤に標準化するためのテクノロジーと専門知識を提供します。

このレイヤーのすべては、相互運用性を念頭に置いて構築されています。データフォーマットとAPIは、HL7およびX12に基づいています。これには、FHIR R4/R5、HL7 v2、C-CDA、およびX12が含まれます。臨床的な意味は、LOINC、SNOMED CT、RxNorm、およびICD-10などの広く採用されているコードシステムを使用して表現されます。特定のユースケースへの準拠は、US Core、CARIN Blue Button、Da Vinci PDex、およびmCODEなどのFHIR実装ガイドを通じて定義され、規制やパートナーの要件が進化するにつれて、追加のコードシステムとIGが組み込まれます。

これは意図的なアーキテクチャ上の選択であり、チェックボックスではありません。オープンスタンダードは、データモデルが単一のベンダーにロックインされないことを保証することを意味します。今日、相互運用性を強化するのと同じFHIRリソースは、再作業なしで分析、AI、および将来のアプリケーションをサポートできます。ツールの切り替えでデータモデリングをやり直す必要があってはなりません。

主な機能は次のとおりです。

• オープンソースのHL7v2、C-CDA、およびX12コンバーターは、レガシーデータを医療相互運用性のための最新標準であるFHIRに変換します。
• FHIRネイティブの用語サーバーは、ボキャブラリー間のコードを正規化し、ソースシステムに関係なく、1つの診断が1回カウントされることを保証します。
• MDM/MPI（マスターデータ管理/マスター患者インデックス）は、患者レコードを重複排除し、1人の患者が1つのゴールデンレコードに相当するようにします。
• FHIR実装ガイドと検証は、事後ではなく、入力時にデータ品質と準拠を強制します。

結果は、患者ごとに単一のゴールデンレコードを持つ、クリーンで標準化されたFHIRデータです。品質と透明性は、事後的なアプローチではなく、基盤となります。

Health Samuraiは、各組織の特定のデータランドスケープに合わせてこれらのパイプラインとツールを構成するのに役立ちます。

どこからでもアクセス — ETL不要

ここでアーキテクチャが変革的になります。Health SamuraiのFHIRサーバーおよびデータベースであるAidboxは、Databricks Lakebase上でネイティブに実行されます。

Lakebaseは、Databricks Data Intelligence Platformに統合された、完全に管理されたサーバーレスPostgresデータベースです。AidboxはLakebase上で直接実行されるため、FHIRデータはETLなしで、Databricksツールキット全体で即座に利用可能になります。

データは、運用フォーマットと分析フォーマット間のリアルタイム同期エンジンであるMoonlinkを介して、ETLなしで複製されます。これにより、FHIRデータは分析レイヤーにシームレスに流れ込み、パイプライン、変換、または遅延の依存関係が排除されます。

これにより、単一のデータセットから2つの補完的なアクセスパターンが作成され、どちらも分析と運用ワークロードを強化します。

1. Databricksネイティブアクセス：分析、データサイエンス、AIのためのSpark、SQL、ML、AI/BI
2. 標準ベースのアクセス：FHIR API、SMART on FHIR、およびSQL on FHIR ViewDefinitions（分析のためにネストされたFHIRリソースをテーブル形式のビューにフラット化する新しいHL7標準）

構築できるもの

統合されたFHIRデータと、Health SamuraiおよびDatabricksの組み合わせたパワーにより、組織は特定の課題に柔軟に対応できます。

EHRの最適化と価値ベースのケア

Databricks AIを搭載した臨床および管理上の意思決定支援は、SMART on FHIRおよびCDS Hooksを介してEHRおよび請求ワークフローに接続されます。これにより、以下が可能になります。

• HEDIS/STARSスコアリングと品質測定
• リスク調整とHCCキャプチャの最適化
• 契約分析と共有利益の追跡
• 事後ではなく、ケアのギャップを積極的に埋めるエージェンティックAI

FHIRネイティブの基盤は、洞察がケアのポイントで、既存のワークフローに組み込まれた形で、臨床医に直接流れることを意味します。

大規模なメンバーエンゲージメント

以下を通じて、患者やメンバーとの有意義な関係を構築します。

• FHIR APIをバックボーンとする患者ポータル — 設計上標準に準拠
• Databricks上のプロペンシティモデルを使用した大規模なパーソナライズされたアウトリーチ — 数百万人のメンバーに最適なチャネル、メッセージ、タイミングを決定します
• 患者アクセスAPI — アーキテクチャの自然な特性として含まれています

コンプライアンス — 後付けではなく、組み込み

FHIRを基盤とすることで、組織はCMS-0057（相互運用性と患者アクセス）やONCの要件のような指令を、アーキテクチャの自然な特性として満たすことができます。

• 患者アクセスルールへの準拠
• 支払者間データ交換
• ONCヘルスIT認定への対応

コンプライアンスは独立したプロジェクトではなく、正しいことを行うことの副産物です。

なぜ今これが重要なのか

CMSとONCの規制期限は急速に迫っており、AIはパイロットから本番稼働へと移行していますが、それは信頼され、管理されたデータ上でのみ可能です。従来の、別個のFHIRサーバー、別個の分析プラットフォーム、そしてそれらを接続するETLパイプラインを維持するというアプローチは、現代のヘルスケアの要求には遅すぎ、高すぎ、そして脆すぎます。

Lakebaseは、相互運用性への投資を将来にわたって保護します。FHIRサーバーは、データインテリジェンスプラットフォーム上で実行されます。臨床業務と分析は、情報のための同じ信頼できる情報源を共有します。Unity Catalogは、運用データから洞察、AIまで、すべてを管理します。そして、オープンスタンダードは、ベンダーロックインのない柔軟性を意味します。

はじめに

Health SamuraiとDatabricks — ヘルスデータプラットフォームのためのオープンテクノロジー。

• Databricks Lakebaseについてさらに詳しく
• Health SamuraiのAidboxを探る
• ヘルスデータプラットフォーム戦略についてご相談ください

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事