前回の話を読んで、「Biomedical Conceptって、結局のところSDTMマッピング仕様書の細かいものじゃないの？」と思われた方がいるのではないでしょうか？実際のところ、これは真っ当な意見だと考えます。そして、それはBiomedical Conceptの開発の経緯を鑑みると、自然なことだと思います。

BCの歴史1：データの性質を図で示す

（個人的に）初期のBiomedical Conceptは、治療領域別標準(TAUG)にたびたび登場していたConcept Mapであると考えています。どんなものか、以下にクローン病TAUGの事例を示します。

こちらはクローン病の治療薬（この場合、治験開始前に投与されていた薬剤）が打ち切られる場面を想定した図です。治療薬の投与中止を検討する段階があり（導入期・維持期）、打ち切り理由によっては、それを裏付ける観察結果があることを示しています。

このConcept Mapの目的は、「SDTMにマッピングしたいお題目」（例：前治療薬の調査）があったときに、「どんな種類のデータ」が発生し、「データ間にどんな関係があるのか」を図示することでした。

文章と比べると、この図はSDTMのデータモデリングの背景を説明する上では便利でした。TAUGの作成者が、SDTMマッピングにあたって頭の中を整理するのにも利用できたでしょうし、読者にとっても全体を把握する上で役に立つ仕組みです。しかし、この時点では、かなりハイレベル（大雑把なレベル）で情報をまとめるにとどまっていて、具体的なデータマッピングを示そうとはしていませんでした。

BCの歴史2：TAUG開発と混迷期

2010年代の半ばになると、TAUG開発時に様々なツールが使用されるようになります。手弁当で作られていたTAUG作成プロセスを整理するとともに、開発時に作成された情報をCDISC SHARE（現、CDISC Library）に掲載することが目的でした。

CDISC Interchange Japanの資料を見直すと、2016年時点で「BCmap」というTAUG開発ツールが紹介されています。面白いことに、この時代には既に今のBiomedical Conceptによく似たデータが生成されています（個々の検査項目のレベルでの定義があります）。

一方で、上で紹介したConcept Mapと同レベルの概要図も作成され続けます（例：2021年リリースのすい臓がんTAUG）。Interhangeの発表資料を見ても、年度によっては「概要レベルの図」をBiomedical Conceptとしてスライドに表示するケースもあり、粒度が一定していません。概要レベルから詳細レベルまで、色々なサイズでBiomedical Conceptが作成されていることが分かります。

同時にBiomedical Conceptの表現形式が見直されており、開発が一筋縄ではいかないことが伝わってくるようです。

BCの歴史3：Code Table Mapping

これと並行してControlled Terminology(CT)の分野でちょっとした資料が作成されだすようになります。ご存じの通りCTは非常に数が多く、その中から正しいものを選択することが難しくなっていました。特に難しいのが、コードリストを超えて正しい組み合わせを見つけることです。分かりにくいので、まずは「問い」を整理しましょう。

1. がん領域においては色々な検査項目があります。検査はコードリストONCRTSに列挙されています

2. 検査結果に対して、適切なコードリストはあるでしょうか？Yes/Noの回答が得られるなら「NY」というコードリストが適します。検査内容によっては別のコードリストを選ぶべきです。検査項目に対応した正しいコードリストを選べるでしょうか？

3. 検査結果のコードリストを選択したとしても、その中には膨大な用語があります。どれを使うべきでしょう？

では、ここで具体例で見てみましょう。

1. RSTEST=Bone Marrow Responseのとき、結果データに使えるコードリストは何でしょうか？NYでしょうか？ONCRSRでしょうか？それとも別のコードリストでしょうか？

2. コードリスト「ONCRSR」を使うとして、Bone Marrow Response検査に対して有効な用語は何でしょうか？（ONCRSRの中には、CR/PDといった値もありますが、STABLE/NEGATIVEといった値も存在します）

この問い答えるのは骨が折れる仕事です。専門家であればある程度の目途が立つかもしれませんが、専門家ゆえの落とし穴に落ちる危険性もあります。このような問題を解決するためにCodeTable Mappingという資料が作られています。これはコードリスト間の関係を示したものです。

先ほどの例でいえば、Bone Marrow Response検査に対してはコードリスト「ONCRSR」を利用し、候補として「CR/PR/SD/PD/NE」の値があることが分かります。また、Bone Marrow Response Indicator検査にはコードリスト「NY」が想定されているようです。

CTの選択（コードリストの選択 and/or 用語の選択）には暗黙的な知識が求められます。Code Table Mappingが存在する理由は、この暗黙知を明確にするためです。この暗黙知は前回の記事で紹介した「血糖測定のSDTMへのモデリング例」と類似しています。由来・視野の大きさこそ違いますが、ここでもBiomedical Concept的なものが生まれていることが分かるでしょうか？

BCの歴史4：第二世代型BC

ここまでイマイチ安定感のないBiomedical Conceptですが、2020年代に入ると構成が大きく変化します。CDISCは「CRF自動作成」「SDTM作成の自動化」「EHR等の外部データの直接取り込み」といった自動化・省力化に向けた実証実験を開始します。この実験において、詳細なレベルのBiomedical Concept（例：収縮期血圧のBiomedical Concept）は強力なツールとなり、仕組みが変更されています。

主な変更点は次の2つです。

(1) 概念層の登場
他の世界との情報連結を可能にするための仕組みとして「型」のようなBiomedical Conceptが登場しました。
臨床試験において、外部データを（EDCなどに）直接取り込む場合、連携先との「間違いのない意思疎通」が課題になります。SDTＭ側が、カルテデータベースに対して「収縮期血圧データ(VSTEST = SYSBP) をください」といったところで、その言葉が通じる保証はありません（というより多分通じません）。違う土台・違う言葉の世界で動作しているシステム同士で会話が成立するような舞台が必要です。
概念層では具体的な実装を想定しない「概念」のままで情報の構造が構成されています。これを元にして、FHIR形式やSDTM形式で組み立てたときの仕様がSpecialized Biomedical Conceptとして出来上がります。同じ「概念」モデルを元に設計されたもの同士であれば、データ交換はいくばくか容易くなるでしょう

(2) Specializationの登場
先ほどの「型」とは対照的に、具体的な仕様を想定して組み立てられたBiomedical Conceptです。例えば、SDTMデータセット作成を想定して『使用変数・適用するべきコードリスト・特定の値の割り当て』などの情報を含めたものです。もちろん、他の仕様を元にしても構いません。FHIR形式へのSpecializationや、CRFデザイン用のSpecializationなどを作成できます（但し、2024年3月現在では構想にとどまる点も多い）

BCの歴史5：これからどうなるのか？

Biomedical Conceptの（個人的な勝手な解釈に基づいて捏造された）歴史を見てきました。まだまだ発展途中で、今後も変化し続けるのだろうな～と思っています。