調査日：2026-10-18。状態：R2 の資料比較と検証候補の選定を完了。実装の採用、実データでの性能検証、利用条件の確定は未完了。
この調査の主な対象は、移行支援・意味差分の監査という中間用途です。プロジェクトの最終目標は 将来の変化に原理的に耐えるコード体系の確立 です。以下の一次比較だけでは、その拡張原理や永続性を評価したことにはなりません。基礎原理の調査結果は R2b に整理しました。
1. 結論
共通モデル、概念合成、論理的な意味差分には先行例があります。 これらの知見を、変化に耐える体系の設計へどう取り込むかを調べます。臨床文脈・情報源・比較不能を含む移行監査は、その一部を検証する中間用途です。体系の実現方法、再利用する範囲、原理上の性質と優位性は未検証です。
今回の選定は次のとおりです。D02 の検証候補を選定し、採用判断は R5 に残します。
| 項目 | 選定 | 理由 |
|---|---|---|
| 比較基準 | 人が作成した、方向・用途・版・意味関係・条件を持つ FHIR ConceptMap による直接対応 | 単純な辞書より強い既存方式と比べ、独自部分の効果を過大評価しないため |
| 次に検証する基盤 1 | HAPI FHIR | 対応表の管理・変換操作・版指定を調べるため |
| 次に検証する基盤 2 | ROBOT と、その対応推論器 | OWL の含意・整合性・導出根拠を使える範囲を調べるため |
| 情報モデルの参照 | openEHR、FHIR の臨床リソース | 概念、記録文脈、臨床テンプレートを分ける設計を比較するため |
| 独自に検証する部分 | 両側の意味定義を根拠に、項目・関係ごとの喪失・追加・矛盾・比較不能を報告する契約と処理 | 既存の対応表の返却結果から、必要な監査結果まで何を補うか確かめるため |
HAPI FHIR と ROBOT は中間用途の実験候補です。今回の選定は、体系の基礎や表現能力の選定、両方の導入・組み合わせの確定を意味しません。
2. 調査範囲と証拠の読み方
R1 の用途と架空例 を基準に、分類・用語データ、対応仕様、実行基盤、臨床情報モデル、推論・検証、先行研究を比較しました。地域差の観察は、日本の病名マスター、米国の ICD-10-CM、ドイツの ICD-10-GM、英国等の SNOMED CT 国別版を対象にしました。世界各国の採用状況や全診療行為コードの網羅調査ではありません。
- 資料確認：公式仕様・原著・公式実装の文書に記載された内容。
- ソース確認：後述の固定コミットで、一部の実装・テストを読んだ内容。テストは実行していません。
- 設計上の判断：MedDSL の用途への適合性についての解釈。
- 未確認：今回調べていないこと。機能がないという断定には使いません。
FHIR は比較のため R5 / 5.0.0 に固定します。最新版という意味ではありません。実装と対象版の適合は別に確認します。文献は探索的な選定であり、網羅的レビューではありません。検索方法と確認箇所は 出典・調査記録 にあります。
3. 体系の母体と役割を整理する
この表で挙げた対象は、比較上 7 群に整理しました。世界の体系数ではありません。ICD-10 の国別修正版は同じ群とし、ICD-11 は別世代の接続対象として分けます。対応表があることだけでは、同じ母体に属するとは数えません。
| 群 | 対象・地域差 | 確認できた役割と、監査に向けた論点 |
|---|---|---|
| ICD-10 系 | WHO 系列、米 ICD-10-CM、独 ICD-10-GM | CM は ICD-10 に基づく臨床修正版。国・版が違うコードを同一視しない。CDC、BfArM 2026 |
| ICD-11 | Foundation、MMS、複合表現 | Foundation の概念参照と線形化のコードを区別する。組み合わせられる軸にも制約がある。WHO API、組み合わせの説明 |
| SNOMED CT | 国際版と米・英等の国別版 | 合成文法があり、国別版は国際版のモジュールと拡張を組み合わせる。利用する版と依存モジュールが必要。合成文法、国別版 |
| MEDIS の病名マスター | 日本 | ICD10 対応標準病名マスターとして公開され、傷病名マスターとも連携する。病名側と分類側の識別子・意味を分けて確認する。公式案内、FAQ |
| LOINC | 検査・観察の項目 | 六つの主軸で項目を区別する。検査項目の定義と患者の結果値・実施時刻を同じものにしない。公式構造説明 |
| RxNorm | 米国の薬剤用語 | 成分・含量・剤形等を組み合わせた名称と概念間の関係がある。患者への投与指示・実施の文脈は別途扱う案を検討する。NLM |
| ATC | 薬剤の分類 | 五段階の分類を持つ。RxNorm と同じ薬剤領域でも、同じ母体や同等の表現とはみなさない。WHO |
MEDIS 全体を一つの単一コード体系として扱う趣旨ではありません。この群は病名マスターの比較上の区分です。また、FMA と TA2 は解剖学の参照候補として別に調べます。名称の対応から、両者が同じ論理モデルを持つとは推定しません。FMA の今回の本文確認は未完了、TA2 は公式の前付けの検索取得テキストを確認した段階で、本体は未取得です。TA2 前付け
国内のレセプト電算、JLAC、手術・処置、各国の償還規則は、初期の意味差分の設計に必要な範囲を選んで後続調査に回します。これらの互換性や実用上の採用を確認済みとはしません。
4. 同じ観点で比べた結果
表中の「追加が必要」は今回の用途への設計判断です。標準や製品の一般的な優劣ではありません。
| 候補と種類 | 意味・合成 | 文脈・情報源 | 喪失・追加の監査で利用できる部分 | 追加定義・確認が必要な部分 |
|---|---|---|---|---|
| FHIR ConceptMap：対応仕様 | 方向、意味関係、条件、複数候補、独自プロパティ | 用途・版と条件を記録できる | 人が確認した対応と条件の交換 | 任意の二つのコードの意味を分解して差分を生成する規則。仕様 |
| OHDSI/Athena：統合語彙 | 標準概念への対応、複数対応、観察値への対応 | CDM には原情報を保持する項目がある | 共通語彙、元コードの保持、損失の整理を参考にできる | 個々の属性の残差、任意方向の変換、採用語彙・版の実データ検証。語彙の構築、CDM 5.4 |
| UMLS：概念統合 | 同じ概念の異なる名称・語彙を結ぶ | 収録元の語彙に依存する | 異なる名称と概念の照合の入口 | CUI の一致だけで、用途や文脈まで含む変換の妥当性を確定しない。NLM |
| SNOMED CT：用語・合成・制約 | 合成文法と MRCM の属性・値域・個数等の制約 | 表現と臨床記録の組み合わせを要検討 | 合成の構文・制約検証を参考にできる | 対象国別版、他体系との意味の接続、記録側との責務分担。MRCM |
| openEHR：臨床情報モデル | 参照モデル、臨床内容、用途別テンプレートを分離 | 記録構造や版を扱う | 臨床ライブラリと安定した基盤を分ける設計 | コード間の差分計算、各接続先の業務・会計規則、操作不変の実証。構造の説明 |
| FHIR の臨床リソース：交換モデル | 記録の種類とコードを分ける | Condition の確度・経過・時点、Provenance の由来 | AI に渡す記録文脈と出典の表現候補 | 本プロジェクトの観察・導出・生成候補・確認状態を表すプロファイル。Condition、Provenance |
| OWL 2：意味・推論 | 概念・関係・公理と含意 | 文脈は明示的なモデル化が必要 | 明記のない帰結と、含意の差を比較する基礎 | 論理の範囲、知識の整合性、計算負担、患者記録との橋渡し。Primer |
| SHACL：制約検証 | データと制約グラフを照合する | 検証箇所と結果を報告できる | 必須項目、値の型、関係の制約を検証する候補 | 定義された制約への適合と医学的正しさを分ける。意味差分は別途設計。仕様 |
| PROV：由来のモデル | 生成・導出・活動・主体を表す | 原情報と変換過程の由来を記録する | 追加情報や AI 出力の情報源を追う候補 | 出典の内容の正しさ、臨床的な確認権限、確認状態の規則。概要 |
既存体系は静的な辞書だけではありません。特に OHDSI の文書は対応における損失を明示的に説明しています。MedDSL の比較対象は、条件と損失を扱うこうした方式です。
5. 先行研究から得たこと
| 文献と確認範囲 | 確認できた内容 | 今回の構想との関係・限界 |
|---|---|---|
| Cimino, 1998, Desiderata for Controlled Medical Vocabularies in the Twenty-First Century。抄録・本文の検索取得断片を確認 | 概念の持続性、意味を埋め込まない識別子、複数粒度、文脈、発展への対応等を論じる | 設計原則の先行提案。MedDSL の実用性を示す実験結果ではない。原著 |
| Rector, 1999, Clinical terminology: why is it so hard?。書誌・抄録を確認 | 利用者とソフトウェアの要求差、規模、実運用での検証を論じる | 人が扱いやすい層を分ける設計の調査入口。本文と現在の後続評価は未確認。PMID 10805008 |
| Rector ほか, 2003, OpenGALEN: Open Source Medical Terminology and Tools。短報本文を確認 | 共通参照モデル、動的な拡張、分類器、用語サーバーを提案 | 共通モデルを介する構想の先行例。現在の保守・運用実績をこの歴史的報告から推定しない。原著 |
| Konev, Ludwig, Walther, Wolter, 2012, The Logical Difference for the Lightweight Description Logic EL。書誌・抄録を確認 | 語彙と問い合わせの種類を指定し、答えの変化を論理差分として扱う。CEX2 と SNOMED CT 等への適用を報告 | 「何が導けなくなったか」の直接の先行研究。限定された論理・問い合わせでの結果を全表現へ一般化しない。証明・実験表の再検証は未実施。著者論文・JAIR 書誌 |
| Gonçalves, Parsia, Sattler, 2013, Comparing ontologies with ecco。4ページの本文・例の記述を確認 | 公理の追加・削除のうち論理的効果のある変化を区別し、失われる／得られる含意と影響する概念を説明する | 意味差分と根拠の報告に近い先行例。主対象はオントロジーの変更で、患者記録の変換監査へそのまま適用できるとはしない。会議短報 |
この結果から、「意味差分そのものが新しい」という主張は採りません。最終目標に向けては、これらの既存設計がどの変化を受け止め、どの性質を保てるかの基礎調査が必要です。移行という中間用途では、意味の接続、文脈と情報源の保持、比較できる範囲を検証します。
6. R1 の架空例に既存方式を当てた検討
以下は資料に基づく設計上の机上検討です。サーバーや推論器で動かした結果ではありません。臨床コードの正しい対応表を作った扱いにもしていません。
| R1 の例 | ConceptMap を比較基準にした場合 | 意味の比較で追加する必要があるもの |
|---|---|---|
| 右側の骨折 → 骨折 | 入力が出力より狭いという意味関係を人が付けられる | 「右側が失われた」を得るための両側の定義と比較観点 |
| 骨折 → 右側の骨折 | 入力が出力より広い関係、必要条件を表せる | 原入力に右側の根拠がないことと、定義を解釈できない状態の区別 |
| 補助情報で右側を確認して追加 | 条件付き対応を記述する入口がある | 補助情報の情報源、入力時点、確認状態、条件を満たした根拠 |
| P は Q の下位概念、出力に Q を明記 | 対応の記録は可能 | 採用した含意の規則で Q を導き、情報追加と区別する処理 |
| 右側 → 左側 | 人が不適切な対応として記録することは可能 | 同一事象の同じ時点であること、左右の排他性、矛盾の根拠 |
| 未解釈のコード同士 | 対応が見つからない場合や対応なしの記録を扱える | 未解釈・未実装・根拠不足・明示的に対応なしという状態の区別 |
| A→B で左右が消え、その後 B→C | 各方向の対応を記録できる | 途中の喪失履歴と、原情報を利用して復元した場合の由来 |
ConceptMap の独自プロパティや拡張に、人が作成した項目別差分を格納する方法も比較対象に残します。「格納できること」と「意味定義から計算できること」を分け、事前に記述する作業量と自動化の効果を測ります。
7. 機械的な意味差分に必要な条件
実装仕様を確定する前に、比較する問いを固定する必要があります。作業案は、例えば「この事象は右側か」「これは本人の現在の確定した病態か」という有限の評価観点を用意し、入力側と出力側で何を裏付けられるかを比べることです。前節の論理差分研究は、その発想の参考になります。
- 問いの対象・時点・用途と、語彙・意味規則・版をそろえる。
- 両側で裏付けられる内容、入力側だけの内容、出力側だけの内容を分ける。
- 出力側だけの内容には、補助情報の裏付けと情報源を照合する。
- 反対の内容を裏付けられる場合と、単に裏付けられない場合を分ける。
- 定義不足、未対応の論理、計算の打ち切り、整合性の問題は比較不能として記録する。
これは MedDSL の検討案で、OWL や特定の推論器の採用決定ではありません。比較観点の外側にある差を検出したとは主張せず、「その観点・知識・規則での差分」として報告します。患者の実際の状態そのものを証明するものでもありません。
また、次の二つは別の処理です。
| 比較対象 | 目的 |
|---|---|
| コード定義・知識モデルの版の比較 | 同じコードの意味や含意が更新でどう変わったか調べる |
| 個別記録の変換前後の比較 | 原記録の主張が出力でも保たれるか、何が付加されたか調べる |
前者の既存研究を後者の解決済みの証拠にはしません。共通モデルへ取り込む際の近似を含めて検証します。
8. 実行基盤の候補と D02
今回確認したのは文書と一部ソースです。以下のコミットは参照位置を記録したもので、動作確認済み・採用済みの版ではありません。ローリング文書の内容が当該コミットの全機能と一致するかも、実行時に確認します。
| 基盤 | 確認したこと | 次に確認すること・選定判断 |
|---|---|---|
| HAPI FHIR | 用語・対応表の版管理が文書化されている。変換サービスと R5 の基本変換テストをソースで確認 | 任意に定義した例で、版、条件、複数候補、対応なし、独自プロパティをどこまで扱えるか。検証候補に選定。公式文書、変換サービス、R5 のテスト |
| ROBOT | 推論、含意の説明、構造的な公理の差分の文書を確認。diff 単体を論理差分の完成機能と扱わない |
対象論理、根拠の出力、未知・不整合の扱い、同じ問いを両側で評価する方法。検証候補に選定。推論、説明、差分、参照コミット |
| Snowstorm | FHIR API、SNOMED CT 向け API、ECL、複数拡張や履歴を扱うという文書を確認 | 初期体系が未選定で、SNOMED の実データへの依存を先に固定しないため初回候補から保留。表現検証・変換の対象版ごとの適合は未確認。公式 README |
| WHO ICD API | ICD の概念・線形化を取得する API と対象版の指定方法を確認 | R3 で対象版・認証・取得範囲・対応リソースを確認。汎用的な体系間変換エンジンの候補とは分け、外部資料への接続候補とする。API 文書 |
HAPI FHIR の基本テストを読めたことから、条件付き対応や全 R5 機能まで動作すると推定しません。実行環境・依存関係・ライセンスとデータの利用条件は R3〜R6 に持ち越します。
D02 の選定理由は、交換・対応管理と、意味・推論の責務を分けて検証できることです。対象資料が使えない、必要な条件を実装が扱えない、定義作成・運用負担が大きい場合に見直します。独自のコンパイラや包括的オントロジーを今作る決定はしていません。
9. 長期構想に対する設計上の示唆
openEHR の層の分離を参考に、安定させる情報モデル、専門領域の概念・制約、用途別のテンプレート、接続先固有の変換を分けて検討します。臨床ライブラリを標準化する対象には、名称だけでなく、操作の意味、入力情報、状態遷移、版、適合性を含める案です。これは今回の設計判断であり、操作不変を実証した結論ではありません。
AI 利用では、概念定義だけでなく「誰について、いつ、誰がどう判断したか」を扱う記録モデルが必要という要件を維持します。FHIR の Condition・Provenance、PROV を参照候補とし、AI の生成候補・導出根拠・人による確認状態をどこで表すかは R5 で決めます。JSON 化や用語コードの統一だけで性能が改善したとは主張しません。
体系そのものの設計では、どの役割を分け、何を不変とし、新しい概念や関係をどう追加できるかを検討します。移行支援や AI 向けの情報整形は、その設計を検証する応用です。移行実験で必要な独自定義の量を測ることと、普遍性の原理を確立することを分けて評価します。
10. 未解決事項と次の段階
| 未解決事項 | 次の段階で行うこと |
|---|---|
| 変化に耐える体系の原理をどう定めるか | R2b で変化・不変条件・設計候補を整理済み。原理の採用は R5 |
| 最初の体系・版・方向に必要な資料を使えるか | R3：WHO・MEDIS 等の資料、公式対応表、取得方法、予定用途での利用条件を整理 |
| 外部コードの意味がどこまで機械的に定義されているか | R3：標本を確認し、名称だけの項目と形式的な定義・制約を区別 |
| どの領域なら喪失・追加を人が確認できるか | R4：領域候補の例と確認体制を比較 |
| 論理差分を個別記録の監査へどう適用するか | R4〜R5：有限の比較観点と評価例を固定し、意味の取り込みの近似も検証 |
| 体系の設計で何を再利用し、何を設計するか | R5：原理の要求に対して既存モデルと設計案を比較し、中間用途でも実証 |
| 新しい体系や AI 利用に対して拡張しやすいか | 後続評価：設計で使わなかった体系・版と文脈の例で、変更量・情報保持・確認負担を測る |
- 主要な候補を役割別に整理し、同じ観点で比較した。
- 共通母体・国別拡張・単なる対応関係を区別した。
- 先行文献の確認範囲と、今回の構想との距離を記録した。
- R1 の全7例について、既存方式で表せる部分と追加定義を机上で検討した。
- 比較基準を一つ、次に検証する基盤を二つ選定した。
- 実装未検証・資料未確認と、確認できた事実を区別した。
中間用途についての R2 の一次比較は完了です。続く R2b の基礎調査、R3 の資料・条件確認 も整理しました。R3 の選定材料と取り込みを保留する範囲を基に、R4 の評価設計へ進めます。