OMOP Odyssey - FHIR® から OMOP への ETL（カリプソの島編）

プロフェッショナルな FHIR® から OMOP への変換

「プロフェッショナル」という言葉の使用に焦点を当て、それをある文脈に置いて考えてみましょう。これは業界の専門家によって書かれており、サポートと、動作に貢献する柔軟なオプションに対してガードレールをいくつか備えた有料サービスとしてまとめられているということです。オープンソースまたは自社開発のソリューションと比較して、（同じ機能を果たすかもしれませんが）拡張性やミッションクリティカルな価値の提供が検討材料となる点に重要な違いがあると感じます。OHDSI コミュニティは、OMOP データベースへの ETL というテーマに関して総合的な能力を備えており、たとえば WhiteRabbit は OMOP データベースを分析し、Rabbit in a Hat は ETL の設計に役立ちます。提供内容を改良するためにコミュニティツールが InterSystems の変換スタックに適用されたということに、株を空売りしてでも賭けるでしょう。

ここでは、データ変換におそらく情熱を注ぐコミュニティにとって興味深いものにしようと考えてはいますが、絶対に、OHDSI コミュニティの入り口にたどり着き、自分の（または他の人の）ヘルスケアデータに関して意味のある大規模な分析を行うための豊富な情報と「大量ソリューションの武器」を手っ取り早く得るための第一歩にはなるでしょう。

Bulk FHIR

パイプラインの取り込み標準は Bulk FHIR Export です。InterSystems が Bulk FHIR Coordinator をどのように実装しているかご覧ください。生成されるエクスポートのペイロードは 1 行ごとに FHIR リソースを含む ndjson を格納した zip ファイルです。

これは、プログラム内で使用できる例として、json でエクスポートされた単一のリソース ファイルを使用すると自分で実行できます...

cd hospitals/
jq -c . hospital*.json > hospitals.ndjson
zip -r hospitals.zip hospitals.ndjson

または単純化して、Synthea と GitHub にある @Dmitry Zasypkin のソリューションを使用して合成ペイロードを生成することもできます。これにより、👣🔫 が処理され、Synthea と一部の FHIR サーバー間の参照の不一致が修正されます。

では、指示に従って、OMOP Database に着地する 10 人の患者で構成される小さな母集団を生成し、サービスをハイライトしましょう。

git clone https://github.com/dmitry-zasypkin/synthea-ndjson
cd synthea-ndjson
docker build . -t synthea
docker run --rm -v ./output:/synthea/output -it synthea -p 10
chmod +x patch-synthea-ndjsons.sh
sudo chmod -R 777 output # may need this
./patch-synthea-ndjsons.sh output/fhir
zip -j fhir1.zip output/fhir/*.*

すべてがうまくいけば、現在の作業ディレクトリに `fhir1.zip` という Bulk FHIR Export の zip ファイルが表示されます。

ここで注意しておきたいことは、Bulk FHIR Export は実際に `synthea.properties` でサポートされているエクスポートオプションであるということです。

exporter.fhir.bulk_data=true

では、実際にやってみましょう。前回セットアップしたバケット `arn:aws:s3:::omop-fhir` を覚えていますか？早速ペイロードをアップロードして OMOP データベースをロードしましょう。



作業内容を確認します。

変換の検査

InterSystems OMOP Cloud ポータルで、パネル内の「メトリクス」に移動し、変換の結果を検査してみましょう。

変換の完了には 1 分もかかっていませんが、実際に完了しています。実行をハイライトすると、データのインポートに統計とレポートが表示されます。異なる 2 つの状況が起き、エラーと警告が出ているようです。

OMOP テーブルを検査すると、着地した「人」の数は 15 で、13 件のリソースにエラーにより ETL に到達しなかったことが確認できます。何が起こったのかを確認するために、OMOP サービスの InterSystems ポータルで「エラー」ナビゲーション項目に移動します。OMOP データベースを確認する方法としては絶対に快適ではありませんが、SQL ブラウザを使って 15 件の Patients（OMOP の人）がデータベースに含まれることを確認しましょう。



上部のペインで実行をハイライトすると、下にデータのエラーと警告の 2 つのテーブルが表示されます。エラーと警告に関する詳細な説明については、私が説明するよりも InterSystems OMOP ドキュメントを確認する方がよいでしょう。


変換（OMOP データモデル経由）に重要な概念 IDE が欠落しているようです。テーブル参照に必要なフィールドは CDM documentation for Procedure で素早く確認できます。




また、変換を行おうとした際に location を 2 回送信したように見えますが、実際には行っていません。

警告については、Synthea が quantity フィールドに文字列を入力したようですが、リソースはそのまま `{#}` で通しています

理解できるように内部のマッピングを探している場合は、InterSystems ドキュメントに記載されています（このリンクであれば目で見る方が理解しやすいでしょう）。

変換のオプション

構成タブ（またプロビジョニング前）には、変換の制御に関して確認するオプションがいくつかありました。最初の 2 つのオプションはソースデータのマッピングのオプションで、FHIRPath 式を使用して、マッピングを制御できます。FHIR resource json で FHIRPath をマイニングするには、fhirpath.js demo での学習が役立つと思いました。

Person Id オプション

これらのオプションは合成データを使用する際に重要ですが、値を見るのが困難です。 FHIR resource json は絶対に変化しない ID であり、リソースそのものを特定するものであるため、医療上での意味はありませんが、FHIR サーバーの運用には巡洋です。HealthShare Patient Index とドメイン競合の概念を理解しているなら、patient が一意であるかどうかを特定する際にソースシステムも同様に重要です。これらのオプションでは、OMOP Database での重複の抑制と意味のある識別子の使用を制御できます。

フィルタリング

OMOP CDM データベースはすでに仮名化データベースとして分類されていますが、一部のデータがそれに送信されることに問題があると考える組織があります。フィルタリングのオプションは、テーブル全体か、テーブル内のフィールドのいずれかをビットバケットに送信します。

用語のマッピング

InterSystems OMOP デプロイメントの S3 構成に指定されたバケットキーに CSV をアップロードすると、OMOP データモデルの語彙と概念を拡張できます。ドキュメントには説明と CSV 形式の仕様が豊富に記載されているため、そちらをご覧ください。

https://docs.intersystems.com/services/csp/docbook/DocBook.UI.Page.cls?K...

ロードしましょう！

データを InterSystems OMOP CDM にロードし、州あたり約 100～200 人の患者のランダム化された母集団を使って、米国のすべての州の実行をシミュレーションしましょう。タイミングは週ごとに約 5 分程度で、使用可能な最低仕様（トライアル版）で実行します。

OHDSI に戻り、RStudio のデータを確認しましょう。

この OMOP CDM は完全に機能するデススターです！