第 6 抽出、変換、ロード

チャプターリード: Clair Blacketer & Erica Voss

6.1 はじめに

ネイティブ/生データからOMOP共通データモデル（CDM）に移行するためには、抽出、変換、ロード（ETL）プロセスを作成する必要があります。このプロセスでは、データをCDMに再構築し、標準化された語彙へのマッピングを追加します。これは通常、一連の自動化スクリプト、例えばSQLスクリプトとして実装されます。このETLプロセスは、ソースデータが更新されたときに再実行できるよう、再現可能であることが重要です。

ETLの作成は通常、大規模な取り組みとなります。長年にわたり、私たちは以下の4つの主要なステップからなるベストプラクティスを開発しました：

  1. データの専門家とCDMの専門家が共同でETLを設計する。
  2. 医学的知識を持つ人がコーディングのマッピングを作成する。
  3. 技術者がETLを実装する。
  4. 全員が品質管理に関与する。

この章では、これらのステップそれぞれについて詳細に議論します。OHDSIコミュニティによっていくつかの支援ツールが開発されており、これらについても議論します。この章を締めくくるにあたり、CDMとETLのメンテナンスについても議論します。 ## ステップ 1: ETLの設計

ETLの設計と実装を明確に分けることが重要です。ETLの設計にはソースデータとCDMの両方に関する広範な知識が必要です。一方、ETLの実装は通常、ETLを計算効率的に行うための技術的専門知識に依存します。両方を同時に行おうとすると、細かい点に気を取られてしまうことが多く、全体像に集中できなくなることがあります。

ETL設計プロセスを支援するために密接に統合された2つのツールが開発されました：White RabbitとRabbit-in-a-Hatです。

6.1.1 White Rabbit

データベースでETLプロセスを開始するためには、データ（テーブル、フィールド、内容）を理解する必要があります。これがWhite Rabbitの役割です。White Rabbitは、縦断的な医療データベースをOMOP CDMにETLするための準備を支援するソフトウェアツールです。White Rabbitはデータをスキャンし、ETLの設計を開始するために必要なすべての情報を含むレポートを作成します。全てのソースコードとインストール手順、およびマニュアルへのリンクはGitHubで入手可能です16。

範囲と目的

White Rabbitの主な機能は、ソースデータをスキャンし、フィールドに出現するテーブル、フィールド、値に関する詳細な情報を提供することです。ソースデータは、カンマ区切りのテキストファイルやデータベース（MySQL、SQL Server、Oracle、PostgreSQL、Microsoft APS、Microsoft Access、Amazon Redshift）に保存できます。スキャンによって、ETL設計時に参考として使用できるレポートが生成されます。例えば、Rabbit-In-a-Hatツールと一緒に使用することができます。White Rabbitは標準的なデータプロファイリングツールと異なり、生成された出力データファイルに個人識別情報（PII）を表示しないようにします。

プロセス概要

ソフトウェアを使用してソースデータをスキャンする一般的な手順：

  1. 結果をエクスポートするローカルデスクトップコンピュータの作業フォルダを設定します。
  2. ソースデータベースまたはCSVテキストファイルに接続し、接続をテストします。
  3. スキャン対象のテーブルを選択し、テーブルをスキャンします。
  4. White Rabbitがソースデータに関する情報をエクスポートします。

作業フォルダの設定

White Rabbitアプリケーションをダウンロードしてインストールした後、最初に行うべきことは作業フォルダを設定することです。White Rabbitが作成するすべてのファイルはこのローカルフォルダにエクスポートされます。図6.1に示されている「Pick Folder」ボタンを使用して、スキャンドキュメントを配置するローカル環境をナビゲートします。

White Rabbitアプリケーションの作業フォルダを指定するための「Pick Folder」ボタン。

図 6.1: White Rabbitアプリケーションの作業フォルダを指定するための「Pick Folder」ボタン。

データベースへの接続

White Rabbitは区切りテキストファイルとさまざまなデータベースプラットフォームをサポートします。各フィールドにマウスカーソルを置くと、必要な情報が表示されます。詳細についてはマニュアルをご覧ください。

データベース内のテーブルをスキャン

データベースに接続した後、含まれるテーブルをスキャンできます。スキャンによってETLの設計に役立つ情報を含むレポートが生成されます。図6.2に示されたスキャンタブを使用して、「Add」（Ctrl + マウスクリック）をクリックすることで、選択されたソースデータベース内の個々のテーブルを選択するか、データベース内のすべてのテーブルを自動選択する「Add all in DB」ボタンをクリックできます。

White Rabbit スキャンタブ。

図 6.2: White Rabbit スキャンタブ。

スキャンにはいくつかの設定オプションもあります：

  • 「フィールド値をスキャン」をチェックすると、WhiteRabbitは列に表示される値を調査します。
  • 「最小セル数」はフィールド値のスキャン時のオプションです。デフォルトでは5に設定されており、ソースデータで5回未満表示された値は報告に表示されません。個別のデータセットには、この最小セル数に関する独自のルールがある場合があります。
  • 「テーブルあたりの行数」はフィールド値のスキャン時のオプションです。デフォルトでは、White Rabbitはテーブル内の100,000行をランダムに選択してスキャンします。

すべての設定が完了したら、「テーブルをスキャン」ボタンを押します。スキャンが完了すると、レポートが作業フォルダに書き込まれます。

スキャンレポートの解釈

スキャンが完了すると、スキャンされた各テーブルと概要タブを含むExcelファイルが選択されたフォルダに生成されます。概要タブにはスキャンされたすべてのテーブル、各テーブルの各フィールド、各フィールドのデータ型、フィールドの最大長、テーブル行数、スキャンされた行数、および各フィールドが空である頻度が一覧表示されます。図6.3.に示されたサンプル概要タブ。

スキャンレポートのサンプル概要タブ。

図 6.3: スキャンレポートのサンプル概要タブ。

各テーブルのタブには、各フィールド、各フィールド内の値、および各値の頻度が表示されます。各ソーステーブル列は、Excelに2つの列を生成します。1つの列には、スキャン時に設定された「最小セル数」を超えるすべての固有値がリストされます。固有値のリストが切り捨てられた場合、リストの最後の値は「リスト切り捨て」と表示されます。これは、「最小セル数」で入力した数より少ない頻度で表示される1つ以上の追加の固有ソース値が存在することを示します。各固有値の横には、その値がサンプルに出現する頻度（発生回数）を含む2番目の列もあります。これらの2つの列（固有値と頻度）は、ワークブック内のプロファイリングされたテーブルのすべてのソースカラムについて繰り返されます。

単一列のサンプル値。

図 6.4: 単一列のサンプル値。

レポートはソースデータを理解するために強力であり、存在するものを強調します。例えば、図6.4に示された結果がスキャンされたテーブルの「Sex」列に戻された場合、2つの一般的な値（1と2）がそれぞれ61,491回と35,401回出現したことが分かります。White Rabbitは1を男性、2を女性として定義することはなく、データホルダーが通常、ソースシステムに固有のソースコードを定義する必要があります。しかし、これらの2つの値（1と2）はデータに存在する唯一の値ではなく、このリストが切り捨てられたことが確認できます。これらの他の値は非常に低い頻度で出現し（「最小セル数」で定義）、しばしば不正確または非常に疑わしい値を表しています。ETLを生成する際には、高頻度のジェンダーコンセプト1と2を処理するだけでなく、この列に存在する他の低頻度の値にも対応するよう計画する必要があります。例えば、これらの低頻度のジェンダーが「NULL」であれば、そのデータを処理し、その状況に対処する方法をETLが知っていることを確認したいです。

6.1.2 Rabbit-In-a-Hat

White Rabbitスキャンを手にしたら、ソースデータの全体像が掴めます。次に、これをCDMに変換するためのロジックを定義する必要があります。この設計作業には、ソースデータとCDMの両方に関する深い知識が必要です。White Rabbitソフトウェアと共に提供されるRabbit-in-a-Hatツールは、これらの分野の専門家チームをサポートするように特別に設計されています。典型的な設定では、ETL設計チームが一緒に部屋に集まり、Rabbit-in-a-Hatがスクリーンに投影されます。最初のラウンドでは、テーブル間のマッピングが共同で決定され、その後、フィールド間のマッピングが設計され、値をどのように変換するかのロジックが定義されます。

範囲と目的

Rabbit-In-a-HatはWhite Rabbitスキャンドキュメントを読み取り、表示するように設計されています。White Rabbitはソースデータに関する情報を生成し、Rabbit-In-a-Hatはその情報を使用して、グラフィカルユーザーインターフェイスを通じてソースデータをCDMのテーブルおよびカラムに接続することを可能にします。Rabbit-In-a-HatはETLプロセスのドキュメントを生成しますが、ETLを作成するコードは生成しません。

プロセス概要

このソフトウェアを使用してETLのドキュメントを生成する一般的な手順：

  1. White Rabbitのスキャン結果を完了させます。
  2. スキャン結果を開くと、インターフェースにソーステーブルおよびCDMテーブルが表示されます。
  3. ソーステーブルを対応するCDMテーブルに接続します。
  4. 各ソーステーブルからCDMテーブルへの接続について、ソース列からCDM列への詳細を定義します。
  5. Rabbit-In-a-Hatの作業内容を保存し、MS Wordドキュメントにエクスポートします。

ETLロジックの記述

White RabbitスキャンレポートをRabbit-In-a-Hatで開いたら、ソースデータをOMOP CDMに変換する方法のロジックを設計し、記述する準備が整います。次のセクションでは、Synthea17データベースのいくつかのテーブルが変換中にどのように見えるかを例示します。

ETLの一般的なフロー

CDMは人中心のモデルであるため、まずPERSONテーブルをマッピングすることが常に良い考えです。すべての臨床イベントテーブル（CONDITION_OCCURRENCE、DRUG_EXPOSURE、PROCEDURE_OCCURRENCEなど）は、person_idを介してPERSONテーブルを参照しているため、最初にPERSONテーブルのロジックを解決すると、後で簡単になります。PERSONテーブルの後は、OBSERVATION_PERIODテーブルを次に変換するのが良いルールです。CDMデータベースの各人物には少なくとも1つのOBSERVATION_PERIODがあり、一般的に、人物のほとんどのイベントはこの期間内に発生します。PERSONおよびOBSERVATION_PERIODテーブルが完了したら、次は通常、PROVIDER、CARE_SITE、およびLOCATIONなどの次元テーブルを変換します。臨床テーブルの前に処理すべき最後のテーブルロジックはVISIT_OCCURRENCEです。これはしばしばETL全体で最も複雑なロジックであり、最も重要なものの1つです。人物の患者の旅の過程で発生するほとんどのイベントは訪問中に発生します。これらのテーブルが完了したら、どのCDMテーブルを変換し、その順序を選択できます。

ETLの一般的なフローと、最初にマッピングするテーブル。

図 6.5: ETLの一般的なフローと、最初にマッピングするテーブル。

CDM変換中に中間テーブルを作成する必要があることがよくあります。これは、イベントに正しいVISIT_OCCURRENCE_IDを割り当てるため、またはソースコードを標準コンセプトにマッピングするため（このステップをオンザフライで行うことはしばしば非常に遅い）です。中間テーブルは100％許可され推奨されています。ただし、変換が完了した後にこれらの中間テーブルを永続化し、それらに依存することは推奨されません。

マッピング例：Personテーブル

Syntheaデータ構造にはpatientsテーブルに20のカラムがありますが、図6.6. に示されているように、すべてがPERSONテーブルを埋めるために必要ではありませんでした。これは非常に一般的であり、心配する必要はありません。この例では、Synthea patientsテーブルの多くのデータポイントはCDM PERSONテーブルで使用されなかったため、患者名、運転免許証番号、パスポート番号などの追加識別子でした。

Synthea PatientsテーブルからCDM PERSONテーブルへのマッピング。

図 6.6: Synthea PatientsテーブルからCDM PERSONテーブルへのマッピング。

表??には、Synthea patientsテーブルをCDM PERSONテーブルに変換するために課されたロジックが示されています。『Destination Field』（目的フィールド）は、CDMのどこにデータがマッピングされるかを示しています。『Source field』（ソースフィールド）は、CDMカラムを埋めるために使用されるソーステーブル（この場合はpatients）のカラムを強調します。最後に、『Logic & comments』（ロジックとコメント）カラムには、ロジックの説明が記載されています。

表：(＃tab:syntheaEtlPerson) Synthea PatientsテーブルをCDM PERSONテーブルに変換するためのETLロジック

目的フィールド ソースフィールド ロジックとコメント
PERSON_ID 自動生成。 PERSON_IDは実装時に生成されます。これは、ソースのid値がvarchar値であり、PERSON_IDは整数であるためです。 ソースのidフィールドは、その値を保持し、必要に応じてエラーチェックを行うためにPERSON_SOURCE_VALUEとして設定されます。
GENDER_CONCEPT_ID gender 性別が「M」の場合、GENDER_CONCEPT_IDは8507、性別が「F」の場合は8532に設定します。不明な性別を持つ行は削除します。これらの2つの概念は、性別ドメインの唯一の標準概念であるため選ばれました。不明な性別の患者を削除するかどうかの決定は、通常、サイトに基づいて行われますが、性別のない人々は分析から除外されるため、削除することを推奨します。
YEAR_OF_BIRTH birthdate 生年月日から

6.2 ステップ2: コードマッピングの作成

OMOPボキャブラリには時間とともにますます多くのソースコードが追加されています。これは、CDMにデータを変換する際のコーディングシステムが既に含まれており、マッピングされている可能性があることを意味します。含まれているボキャブラリを確認するために、OMOPボキャブラリのVOCABULARYテーブルをチェックしてください。非標準のソースコード（例：ICD-10CMコード）から標準コンセプト（例：SNOMEDコード）へのマッピングを抽出するには、relationship_id =「Maps to」を持つCONCEPT_RELATIONSHIPテーブルのレコードを使用できます。例えば、ICD-10CMコード「I21」（「急性心筋梗塞」）の標準コンセプトIDを見つけるためには、次のSQLを使用します：

SELECT concept_id_2 AS standard_concept_id
FROM concept_relationship
INNER JOIN concept AS source_concept
  ON concept_id = concept_id_1
WHERE concept_code = 'I21'
  AND vocabulary_id = 'ICD10CM'
  AND relationship_id = 'Maps to';
STANDARD_CONCEPT_ID
312327

残念ながら、ソースデータがボキャブラリに含まれていないコーディングシステムを使用している場合もあります。この場合、ソースコーディングシステムから標準コンセプトへのマッピングを作成する必要があります。コードマッピングは特にソースコーディングシステムに多くのコードが含まれている場合、気が遠くなる作業です。作業を楽にするために以下のことを行うことができます：

  • 最も頻繁に使用されるコードに焦点を当てる。本当に使用されていないか、ほとんど使用されていないコードに労力を割く価値はありません。
  • 可能な限り既存の情報を活用する。例えば、多くの国の薬品コーディングシステムはATCにマッピングされています。ATCは多くの目的には詳細でないかもしれませんが、ATCとRxNormのコンセプトの関係を使って適切なRxNormコードを推測することができます。
  • Usagiを使用。

6.2.1 Usagi

Usagiはコードマッピングを手動で作成するプロセスを支援するツールです。コード記述のテキスト類似性に基づいたマッピングを提案できます。ソースコードが外国語でしか利用できない場合、Google Translate18は驚くほど良い翻訳を提供することがわかっています。Usagiは自動提案が正しくない場合に適切なターゲットコンセプトを検索する機能を提供します。最終的に、ユーザーはそのマッピングがETLで使用される許可がされていることを示すことができます。UsagiはGitHubで入手可能です19。

6.2.1.1 範囲と目的

マッピングが必要なソースコードはUsagiにロードされます（コードが英語でない場合は追加の翻訳列が必要です）。用語の類似性アプローチを使用してソースコードをボキャブラリコンセプトに接続します。ただし、これらのコード接続は手動で見直す必要があり、Usagiはこれを支援するインターフェースを提供します。Usagiはボキャブラリで標準コンセプトとしてマークされているコンセプトのみを提案します。

6.2.1.2 プロセス概要

このソフトウェアを使用する一般的な手順は次のとおりです：

  1. マッピングしたいソースシステムからソースコードをロードします。
  2. Usagiは用語の類似性アプローチを実行してソースコードをボキャブラリコンセプトにマッピングします。
  3. Usagiのインターフェースを利用して、自動提案の正しさを確認し、必要に応じて改善します。コードシステムと医療用語に精通した個人によるレビューが推奨されます。
  4. ボキャブラリのSOURCE_TO_CONCEPT_MAPにマッピングをエクスポートします。

6.2.1.3 ソースコードをUsagiにインポート

ソースコードをCSVまたはExcel (.xlsx) ファイルにエクスポートします。これには、ソースコードと英語のソースコード記述が含まれている必要がありますが、追加の情報（例：投与単位、元の言語の説明（翻訳された場合））も持ち込むことができます。さらに、コードの頻度も持ち込むことが望ましく、これによりどのコードに最も労力をかけるべきかを優先的に決定するのに役立ちます（例：1,000個のソースコードがあっても、システム内で本当に使用されるのは100個だけかもしれません）。英語に翻訳する必要がある場合は、Google Translateを使用します。

注意事項: ソースコードの抽出はドメインごとに分けて行い、1つの大きなファイルにまとめないでください（例：薬物、手順、状態、観察）。

ソースコードはFile → Import codesメニューからUsagiにロードされます。ここでは「Import codes …」が表示される（図6.7）。この図では、ソースコード用語がオランダ語で、英語に翻訳されたものも含まれています。Usagiは英語の翻訳を利用して標準ボキャブラリにマッピングします。

Usagiコード入力画面。

図 6.7: Usagiコード入力画面。

「Column mapping」セクション（左下）では、インポートされたテーブルをUsagiに対してどのように使用するかを定義します。ドロップダウンメニューにマウスを合わせると、それぞれの列の定義が表示されるポップアップが表示されます。Usagiは「Additional info」列をソースコードとボキャブラリコンセプトコードを関連付けるための情報として使用しませんが、この追加の情報はソースコードマッピングを確認する個々人を支援するのに役立ちますので、含めるべきです。

また、「Filters」セクション（右下）で、Usagiがマッピングする際の制限を設定できます。例えば、図6.7では、ユーザーはソースコードをConditionドメインのコンセプトにマッピングしています。デフォルトでは、Usagiは標準コンセプトにしかマッピングしませんが、「Filter standard concepts」をオフにすると、Usagiは分類コンセプトも考慮します。各フィルターについて詳細を知るためには、異なるフィルターにマウスをホバーさせてください。

特別なフィルターとして「Filter by automatically selected concepts / ATC code」があります。制限する情報がある場合、Auto concept ID列（セミコロンで区切られた）にCONCEPT_IDsまたはATCコードのリストを提供することで検索を制限できます。例えば、薬物の場合、既に各薬剤にATCコードが割り当てられているかもしれません。ATCコードは単一のRxNorm薬物コードを特定しませんが、ボキャブラリ内のATCコードに該当するコンセプトのみを検索することで検索範囲を制限するのに役立ちます。ATCコードを使用するには、以下の手順に従います：

  1. Column mappingセクションで、“Auto concept ID column”から”ATC column”に切り替える
  2. Column mappingセクションで、ATCコードの列を”AT ## ステップ 3: ETLの実装

設計とコードマッピングが完了したら、ETLプロセスをソフトウェアで実装することができます。ETLの設計段階では、ソースデータとCDMに詳しい人が共同で作業することをおすすめしました。同様に、ETLを実装する際には、大量のデータを扱う経験があり、ETLの実装経験がある人を使うことが望ましいです。これは、あなたのグループ外の個人と協力することや、実装を担当する技術顧問を雇うことを意味するかもしれません。また、これは一度きりの費用ではないことにも注意が必要です。今後もETLの維持と運用を担当するために、少なくとも一部の時間を捧げる個人やチームがいることが望ましいです（詳細はセクション 6.5 を参照してください）。

実装の具体的な内容はサイトごとに異なり、インフラ、データベースの規模、ETLの複雑さ、利用可能な技術専門知識など多くの要因に依存します。そのため、OHDSIコミュニティはETLの最適な実装方法について正式な推奨を行っていません。シンプルなSQLビルダー、SAS、C#、Java、およびKettleを使用するグループもいます。それぞれに長所と短所があり、技術に精通している人がいなければどれも使えません。

様々なETLの例をいくつか挙げます（複雑さの順に記載）：

複数回の独立した試みの後、ユーザーフレンドリーな”究極の”ETLツールの開発を断念しました。このようなツールはETLの80%にはうまく機能しますが、残りの20%のETLには、ソースデータベース固有の低レベルのコードを書く必要があります。

技術者が実装を開始する準備ができたら、ETL設計文書を彼らと共有するべきです。ドキュメントには開発を開始するための十分な情報が含まれているはずですが、開発プロセス中にETL設計者が質問に応じることができるようにすることが重要です。設計者には明確な論理も、データやCDMに不慣れな実装者にはわかりにくいことがあります。実装フェーズはチーム全体の努力として維持されるべきです。実装者と設計者の間で、CDMの作成とテストのプロセスを繰り返し行い、両グループがすべての論理が正しく実行されたことに同意するまで進行することが受け入れられた慣行とされています。

6.3 ステップ 4: 品質管理

抽出、変換、ロードプロセスでは品質管理が反復的です。一般的なパターンは、ロジックの記述->ロジックの実装->ロジックのテスト->ロジックの修正・記述です。CDMをテストする方法はいくつもありますが、以下は何年にもわたるETL実装を通じてコミュニティ全体で開発された推奨ステップです。

  • ETL設計文書、コンピュータコード、およびコードマッピングのレビュー。1人の人がミスをすることは常にあるので、必ず他の1人以上が行ったことをレビューするべきです。
    • コンピュータコードにおける最大の問題は、ネイティブデータのソースコードが標準概念にどのようにマッピングされるかに起因します。特に日付特有のコード（NDCなど）の場合、マッピングは難しくなることがあります。どの領域でもマッピングが行われる場合は、正しいソース語彙が適切な概念IDに変換されているかを必ず再確認してください。
  • ソースデータとターゲットデータのサンプルに関する情報を手動で比較します。
    • 最大のユニークなレコード数を持つ理想的な1人のデータを追跡するのが役立つことがあります。1人のデータを追跡することで、CDMのデータが合意されたロジックに基づいて期待されるように見えない場合に問題が浮かび上がります。
  • ソースデータとターゲットデータの全体的なカウントを比較します。
    • 特定の問題にどのように対処するかによって、カウントに期待される差異があるかもしれません。たとえば、NULL性別の人々を解析から完全に除外する協力者がいます。また、CDMの訪問がネイティブデータの訪問やエンカウンターと異なるように構築されることもあります。そのため、ソースデータとCDMデータ間の全体的なカウントを比較する際には、これらの違いに留意し、期待する必要があります。
  • ソースデータで既に行われた研究をCDMバージョンで再現します。
    • これはソースデータとCDMバージョンとの間の主要な違いを理解するための良い方法ですが、少し時間がかかります。
  • ETLで対処する必要があるソースデータのパターンを再現するユニットテストを作成します。たとえば、性別情報のない患者が削除されるべき場合、性別がない個人のユニットテストを作成し、ビルダーがどのように処理するかを評価します。
    • ユニットテストは、ETL変換の品質と正確性を評価する際に非常に便利です。通常、変換元データの構造を模倣する非常に小さいデータセットを作成します。このデータセット内の各個人またはレコードは、ETL文書に記載されている特定のロジックをテストします。この方法では、問題を特定し、失敗したロジックを特定するのが簡単になります。小さいサイズはコンピュータコードの実行が非常に速くなり、反復とエラーの特定を迅速に行えます。

これらは、ETLの観点から品質管理にアプローチする高レベルの方法です。OHDSIコミュニティ内で進行中のデータ品質への取り組みの詳細については、Chapter 15 を参照してください。

6.4 ETLの慣行とTHEMIS

データをCDMに変換するグループが増えるにつれ、特定の状況でETLがどのように対処すべきかを指定する必要があることが明らかになりました。たとえば、出生年が欠けている個人記録の場合、ETLはどうすべきでしょうか？CDMの目標はヘルスケアデータを標準化することですが、各グループが特定のデータシナリオを異なる方法で処理すると、ネットワーク全体でデータを体系的に使用することが難しくなります。

OHDSIコミュニティは、一貫性を向上させるために慣行を文書化し始めました。OHDSIコミュニティが合意したこれらの定義された慣行は、CDM Wikiで見つけることができます20。各CDMテーブルには、ETLを設計する際に参照できる独自の慣行セットがあります。たとえば、出生月や日が欠けている個人は許可されますが、出生年が欠けている場合、その個人は削除する必要があります。ETLを設計する際には、コミュニティと一貫性のある設計決定を行うために慣行を参照してください。

すべてのデータシナリオを文書化し、発生した場合に何をするかをドキュメント化することは不可能ですが、共通のシナリオを文書化しようとしているOHDSIの作業グループがあります。THEMIS21は、コミュニティ内で慣行を収集し、それを明確にし、コミュニティと共有し、最終的な慣行をCDM Wikiに文書化する個人で構成されています。Themisは、古代ギリシャの神であり、秩序、公平さ、法、自然法、慣習を司るタイタネスであり、このグループの任務にふさわしいものでした。ETLを実行する際に、どのように処理すべきか判断に迷うシナリオがあった場合、THEMISはそのシナリオについてOHDSIフォーラムに質問を投げかけることをお勧めします22。おそらく、質問がある場合、他のコミュニティのメンバーも同じ質問を抱えている可能性があります。THEMISはこれらの議論、作業グループの会議、フェイス・トゥ・フェイスのディスカッションなどを利用して、他に文書化する必要がある慣行について情報を収集します。

6.5 CDMおよびETLのメンテナンス

ETLを設計し、マッピングを作成し、ETLを実装し、品質管理措置を構築することは容易な作業ではありません。残念ながら、この努力はそこで終わりではありません。最初のCDMが構築されると、ETLメンテナンスのサイクルが継続的に行われます。メンテナンスが必要となる一般的なトリガーは以下の通りです：ソースデータの変更、ETLのバグ、新しいOMOP語彙のリリース、またはCDM自体の変更や更新です。これらのトリガーが発生すると、ETLドキュメント、ETLを実行するソフトウェアプログラミング、テストケースや品質管理の更新が必要になる場合があります。

医療データソースは常に変化し続けることがよくあります。新しいデータが利用可能になるかもしれません（例：データに新しい列が追加される）。存在しなかった患者のシナリオが突然現れるかもしれません（例：生まれる前に死亡記録がある新しい患者）。データの理解が向上するかもしれません（例：請求処理の方法により、入院出産に関する記録の一部が外来として処理されること）。すべてのソースデータの変更がETL処理の変更を引き起こすわけではありませんが、最低限、ETL処理を中断する変更は対処する必要があります。

バグが見つかった場合、それに対処する必要があります。しかし、すべてのバグが同じ重要性を持っているわけではないことを忘れないでください。例えば、COSTテーブルではcost列が整数に丸められていたとしましょう（例：ソースデータに$3.82があったのに、CDMで$4.00になっている）。データを使用して主に患者の薬物曝露や状態の特徴付けを行う研究者が多い場合、このようなバグは重要ではなく、将来的に対処することができます。しかし、データを使用する主要な研究者に健康経済学者も含まれていた場合、これは直ちに対処する必要がある重大なバグとなります。

OMOP語彙もまた、ソースデータと同様に常に変化しています。実際、語彙は1ヶ月に何度も更新されることがあります。各CDMは特定の語彙バージョンで実行されており、新しい改善された語彙で実行すると、標準化された語彙にソースコードがマッピングされる方法が変わる可能性があります。語彙の違いはしばしば些細なものですが、新しい語彙がリリースされるたびに新しいCDMを構築することは不要です。しかし、年間に1回か2回程度、新しい語彙を採用することが良いとされています。この場合、CDMを再処理する必要があります。新しいバージョンの語彙の変更がETLコード自体の更新を必要とすることはまれです。

CDMまたはETLのメンテナンスが必要となる最後のトリガーは、共通データモデル自体の更新時です。コミュニティが成長し、新しいデータ要件が見つかると、これがCDMに追加データを保存することにつながるかもしれません。これは、以前はCDMに保存されていなかったデータが新しいCDMバージョンに保存場所を持つ可能性があることを意味します。既存のCDM構造の変更は頻繁ではありませんが、可能性はあります。例えば、CDMが元のDATEフィールドからDATETIMEフィールドを採用したことで、ETL処理にエラーが発生する可能性があります。CDMバージョンは頻繁にはリリースされず、サイトは移行するタイミングを選択できます。

6.6 ETLに関する最終的な考え

ETLプロセスにはさまざまな理由で困難があります。その中でも、私たちが処理しているソースデータの独自性により、「1つの解決策がすべてに適合する」という解決策を作成するのが難しいことが最大の理由の1つです。しかし、過去数年で以下のような貴重な教訓を得ました。

  • 80/20のルール。可能な限り、ソースコードを手動で概念セットにマッピングするのに過度に時間を費やさないようにしましょう。理想的には、大多数のデータをカバーするソースコードをマッピングしてください。これで十分であり、将来のユースケースに基づいて残りのコードに対処することができます。
  • 研究の質に見合わないデータを失うことを恐れなくても良い。それらはしばしば分析を開始する前に破棄されるレコードであり、私たちはETLプロセス中にそれらを削除します。
  • CDMはメンテナンスが必要です。ETLが完了したからといって、再び触らないということではありません。生データが変更されるかもしれませんし、コードにバグがあるかもしれません。新しい語彙やCDMの更新があるかもしれません。これらの変更に対応するためのリソースを計画しておくことで、ETLが常に最新の状態に保たれるようにしましょう。
  • OHDSI CDMの開始、データベースの変換、分析ツールの実行のサポートが必要な場合は、実施者フォーラム23をご覧ください。

6.7 まとめ

  • ETLにアプローチするための一般的に合意されたプロセスが存在します

    • データ専門家とCDM専門家が協力してETLを設計
    • 医療知識を持つ人々がコードマッピングを作成
    • 技術者がETLを実装
    • すべての関係者が品質管理に関与

  • OHDSIコミュニティはこれらのステップを促進するためにツールを開発しており、これらは自由に使用できます

  • ガイドとして使用できる多くのETL例や合意された慣習があります

6.8 演習

演習 6.1 ETLプロセスのステップを適切な順序に並べてください：

  1. データ専門家とCDM専門家が協力してETLを設計
  2. 技術者がETLを実装
  3. 医療知識を持つ人々がコードマッピングを作成
  4. すべての関係者が品質管理に関与

演習 6.2 選択したOHDSIリソースを使用して、表6.1に示すPERSONレコードに関する4つの問題点を指摘してください（表はスペースのため省略されています）：

表: (#tab:exercisePersonTable) PERSONテーブル。

列 値
PERSON_ID A123B456
GENDER_CONCEPT_ID 8532
YEAR_OF_BIRTH NULL
MONTH_OF_BIRTH NULL
DAY_OF_BIRTH NULL
RACE_CONCEPT_ID 0
ETHNICITY_CONCEPT_ID 8527
PERSON_SOURCE_VALUE A123B456
GENDER_SOURCE_VALUE F
RACE_SOURCE_VALUE WHITE
ETHNICITY_SOURCE_VALUE 提供されていない

演習 6.3 VISIT_OCCURRENCEレコードを生成してみましょう。以下はSyntheaのために書かれた一部のロジックです： PATIENT、START、ENDを昇順で並べ替えます。その後、PERSON_IDごとに、前の行のENDと次の行のSTARTの間に1日以内の時間がある限り、請求行をまとめます。まとめられた入院請求ごとに1つの入院訪問と見なし、以下を設定します：

  • MIN(START)をVISIT_START_DATEとして設定
  • MAX(END)をVISIT_END_DATEとして設定
  • “IP”をPLACE_OF_SERVICE_SOURCE_VALUEとして設定

ソースデータに図6.8に示されるような訪問セットがある場合、CDMで生成されるVISIT_OCCURRENCEレコードはどのようになると予想しますか？

例のソースデータ。

図 6.8: 例のソースデータ。

提案された回答は付録23.3に見つけることができます。

  1. https://github.com/OHDSI/WhiteRabbit.↩︎

  2. SyntheaTMは実際の患者をモデル化することを目的とした患者ジェネレーターです。データはアプリケーションに渡されたパラメータに基づいて作成されます。データの構造については、こちらをご覧ください。↩︎

  3. https://translate.google.com/↩︎

  4. https://github.com/OHDSI/Usagi↩︎

  5. https://github.com/OHDSI/CommonDataModel/wiki↩︎

  6. https://github.com/OHDSI/Themis↩︎

  7. http://forums.ohdsi.org/↩︎

  8. https://forums.ohdsi.org/c/implementers↩︎