この規格 プレビューページの目次
※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。
3 用語と定義
この文書の目的上、次の用語と定義が適用されます。
ISO と IEC は、標準化に使用する用語データベースを次のアドレスで維持しています。
注ISO 1087-1 から選択された用語は、第 3 項の用語および定義の背景として付録 A に記載されています。
3.1 一般用語
3.1.1
コンセプト
特徴のユニークな組み合わせによって作成された知識の単位
注記 1: 非公式には、「概念」という用語は、「概念の表現」を意味する場合によく使用されます。ただし、正確な意味が必要な場合、これは混乱を引き起こします。概念は、周囲の世界についての人間の個人的および社会的な概念化から生じます。概念表現は、シンボルで構築された成果物です。
注記 2:概念表現は、必ずしも特定の言語に拘束されるわけではありません。ただし、それらは使用の社会的または文化的背景の影響を受け、異なる分類につながることがよくあります。
[出典:ISO 1087‑1:2000, 3.2.1, 修正済み]
3.1.2
学期
特定の主題分野における概念の言語表現
[出典:ISO 1087‑1:2000, 3.4.3, 修正済み]
3.1.3
特性
オブジェクトまたはオブジェクトのセットのプロパティの抽象化
[出典:ISO 1087‑1:2000, 3.2.4]
3.1.4
識別子用語
用語集内の用語を一意に識別できる文字、数字、または記号のシーケンス
注記 1:用語識別子は、用語リソース内で一意であるものとする。
3.1.5
概念識別子
用語リソース内の概念を一意に識別できる 正規表現 (3.3.5) 、または一連の文字、数字、または記号。
注記 1:概念識別子は用語リソース内で一意でなければならないため、多義性が存在する場合に備えて、用語はここでの目的に使用されないものとします。
3.1.6
コード
一連の文字、数字、または記号で表される識別子
注記 1:コードは、 コーディングシステム (3.4.4) で使用される場合、 概念識別子 (3.1.5) です。
3.1.7
用語上のリソース識別子
情報交換に使用する 用語リソースの一意の永続的な識別子 (3.4.1)
注記 1:これは、コーディングシステムの登録に関する EN 1068:2005 の Healthcoding Scheme Designator に相当します。
注記 2: この目的には、 OID, UUID, URI などのグローバルに固有のスキームが使用される場合があります。
3.1.8
用語上のリソースのバージョン識別子
バージョン識別子
用語リソース (3.4.1) が 公開または更新されるバージョンに割り当てられた識別子
3.1.9
コーディングスキーム
1 つのセットである「コード化セット」の要素を 2 番目のセットである「コード セット」の要素にマッピングするルールのコレクション
注記 1: 2 つのセットはコーディング方式の一部ではありません。
[出典:ISO 17115:2007, 2.7.2, 修正済み]
3.1.10
複合特性
特性の表現 (3.1.3)
例：
原因菌がある。場所 = 肺の上葉の左。
注記 1:通常、 意味論的リンク (3.2.5) および 特徴付け概念 (3.1.11) によって表現されます。
[出典:ISO 17115:2007, 2.2.1]
3.1.11
特徴的なコンセプト
複合特性 (3.1.10) 内の セマンティックリンク (3.2.5) によって参照される概念
例：
「細菌を引き起こした病気」という構成要素の「細菌」。 「黄色の皮膚病変」という構成要素の「黄色」。
[出典:ISO 17115:2007, 2.2.2]
3.1.12
一般的な概念を特徴づける
特徴的なカテゴリー
価値領域
ドメイン制約 (3.1.14) による特殊化が、特定のコンテキストでの 特徴付け概念 (3.1.11) として使用できる形式的なカテゴリー
例 1:
<INFECTIOUS_ORGANISM> ={細菌、ウイルス、寄生虫}、「原因 INFECTIOUS_ORGANISM を持つ感染」のコンテキスト。
例 2:
原因菌がある。場所 = 肺の上葉の左。
注記 1: コンテキストには上位概念と意味的リンクが含まれます。
[出典:ISO 17115:2007, 2.3.3]
3.1.13
認可された特性
特性のタイプの正式な表現 (3.1.3)
例 1:
<INSTRUMENT> を使用して実行されます。 hasLocation <埋め込み型デバイスの本体部分>。
例 2:
「炎症の原因は{細菌、ウイルス、寄生虫、自己免疫、化学的、物理的} に設定できます」ここで, 「できる」はセマンティック リンクであり、「炎症の原因は{細菌、ウイルス、寄生虫、自己免疫、化学的、物理的}」に設定できます。特徴的な一般概念です。
注記 1: 認可特性は通常 、意味論的リンク (3.2.5) と 特徴付け一般概念 (3.1.12) の組み合わせで構成され、 ドメイン制約 (3.1.14) で使用できます。
[出典:ISO 17115:2007, 2.3.1]
3.1.14
ドメイン制約
特定の主題分野における概念を専門化するために有効な一連の 認可された特性 (3.1.13) を規定する認可ルール
例：
「感染は骨格構造の位置に存在する可能性がある」とは、特定の状況における感染が一種の骨格構造に位置する可能性があることを示します。
注記 1:このルールは、 意味論的リンク (3.2.5) とそれが リンクする特徴的な一般概念 (3.1.12) を組み合わせることによって、場合によっては特徴的な一般概念内の概念を列挙することによって、潜在的な特性のセットを記述します。
注記 2:さまざまなレベルの制裁が可能である (例: 考えられる、慎重な、通常の、通常は状況に応じて、必要な)
[出典:ISO 17115:2007, 2.3.2]
3.2 概念間の関係
3.2.1
一般的な関係
一般化と専門化の関係
2 つの概念間の関係でwhere 一方の概念の意図が他方の概念の意図と少なくとも 1 つの追加の区切り特性を含む場合
注記 1: 「単語」と「代名詞」、「乗り物」と「自動車」、「人」と「子供」という概念の間には、一般的な関係が存在する。
注記 2:この関係は、「親子」または「is-a」関係と同等です。子概念は親概念と同じ意図を持ち、少なくとも 1 つの追加の境界特性を持ちます。 X 'is-a' Y でも同様です。
注記 3: 英語の観点から見た「関係」という用語の使用は、これが関係ではなく概念 (つまり、この概念が別の概念の一般的な関係である) を説明していることを意味します。ただし、ここでの「一般関係」とは概念ではなく関係そのものを意味します。
[出典:ISO 1087‑1:2000, 3.2.21, 修正済み]
3.2.2
部分的な関係
全体関係
2 つの概念間の関係でwhere 一方の概念が全体を構成し、もう一方の概念が全体の一部を構成する場合
注記 1: 「週」と「日」、「分子」と「原子」という概念の間には部分的な関係が存在します。
注記 2:この関係は、 一般的な関係 (3.2.1) とは異なります。たとえば、日は週の一部ですが、週を特化したものではありません。つまり、週の一種ではありません。
[出典:ISO 1087‑1:2000, 3.2.22, 修正済み]
3.2.3
上下関係
2 つの概念間の関係 。一般的関係 (3.2.1) または 部分的関係 (3.2.2) のいずれかです。
例：
「胃」↔「臓器」、「胃」↔「身体」といった関係は上下関係であるが、前者は上位関係、後者は部分関係である。
注記 1: 部分関係 (3.2.2) には、「構成部分」、「地域部分」、「グループ化」などのいくつかのサブタイプがあり、これらも階層タイプの関係です。
注記 2: 用語リソース内で明示的に識別される特性は、階層を決定するために使用される場合があり、これには方向性の宣言が含まれます。このような特性が複数ある場合、用語リソースは「多階層」であると言えます。特性は、階層を決定するために比較できる関係の両端の 2 つの概念に値を持っている必要があります。
[出典:ISO 1087‑1:2000, 3.2.20, 修正済み]
3.2.4
連想関係
実用的な関係
経験に基づく非階層的なテーマ上のつながりを持つ 2 つの概念間の関係
例：
病気「X」とウイルス「Y」の関係は、階層的なものではなく、連想的な関係となっています。この関係は、特定の関心のあるテーマ (例: 「病気とその原因物質」) の下に存在し、経験によって明確に認識されます。
[出典:ISO 1087‑1:2000, 3.2.23, 修正済み]
3.2.5
セマンティックリンク
2 つの概念間の有向 結合関係 (3.2.4) or 部分関係 (3.2.2) の形式的表現
例：
hasCause (逆 isCauseOf を使用)
注記 1: これには、 一般関係 (3.2.1) を除くすべての関係が含まれます。
注記 2: セマンティック リンクには常に逆方向、つまり反対方向の別のセマンティック リンクがあります。
[出典:ISO 17115:2007, 2.2.3]
3.3 形式的な概念表現
3.3.1
公理的な概念表現
原子概念の表現
形式的な（概念表現）システム内で他のより単純な概念表現から構成されていない概念表現（3.4.7）
例：
「肝臓」「切開行為」「痛み」
注記 1:多くの場合、公理的な概念表現は、哲学者が「自然の種類」と呼ぶものに対応します。このようなエンティティを意味のあるように分解することはできません。これらはすべての概念表現の基礎を形成する必要があります。
注記 2: コーディングシステムには、公理的な概念表現だけでなく、さまざまな使用事例に必要な構成概念表現も含まれる場合があります。
[出典:ISO 17115:2007, 2.4.2, 修正済み]
3.3.2
構成概念の表現
複合概念表現
区切り特性として 1 つ以上の 複合特性を使用する概念の内包的定義 (3.1.10)
注記 1: 複合特性 ( 3.1.10) 内の各特徴概念 ( 3.1.11) は 、公理的概念表現 (3.3.1) または別の構成概念表現である場合があります。
注記 2: これにより、 形式的な (概念表現) システム (3.4.7) 内での包含の推論が可能になります。それは、記述論理などの形式主義で表現されることがよくあります。
注記 3:構成的概念表現は 、調整前の概念表現 (3.3.3) と 調整後の概念表現 (3.3.4) にさらに分類できます。
[出典:ISO 17115:2007, 2.4.1, 修正済み]
3.3.3
事前に調整されたコンセプトの表現
形式的（概念表現）システム（3.4.7） 内で事前に定義された、同等の単一の一意の概念識別子を持つ構成概念表現 （3.3.2）
例：
SNOMED CT では、「結腸がん」は事前定義されており、単一の一意の識別子を持っています。これは、SNOMED CT にとって、「結腸がん」が「単一」の概念を表すことを意味します。ただし、SNOMED CTでは「結腸」は「結腸構造」と同義であり、「がん」は「悪性腫瘍性疾患」と同義です。したがって、「結腸がん」は、構成概念表現に分解できるため、非原子的です（例：「結腸がん」=「悪性腫瘍性疾患」<Finding_Site:「結腸構造」>）。
[出典:ISO 17115:2007, 2.4.6, 修正済み]
3.3.4
調整後のコンセプト表現
構成概念表現（3.3.2） 、これは事前に調整されていないため、構成システム内または構成システム外のメカニズムを使用して組み合わせた、1 つまたは複数の構成システム（3.4.5）からの複数の概念を使用して表現されます。
例 1:
問題.Main = 骨折、問題.場所 = 大腿骨 (問題の説明のテンプレート内)
例 2:
言語タグの IETF BCP-47 などの一部の共通用語リソースは、言語、文字、地域などの異種コーディング システムから調整後の概念表現を明示的に構築します。
注記 1: 同じ概念に対して構成概念表現を形成するにはさまざまな方法があるため、異なる用語の概念を組み合わせると、概念の重複や矛盾に関する問題が発生する可能性があります。通常、異種の用語リソースにわたって構成的な概念表現を作成するためのメカニズムは、情報モデルで指定されます (たとえば、特定の種類の概念のテンプレートとして)
[出典:ISO 17115:2007, 2.4.7, 修正済み]
3.3.5
正規表現
コンセプト名
用語体系 (3.4.2) 内で概念を一意に指定する用語 (3.1.2)
例 1:
機械可読: <細菌を引き起こす肺感染症> の代わりに、<炎症を引き起こす細菌が位置する肺>> (セマンティック リンクの後に構成特性がアルファベット順にソートされる)
例 2:
一般用語: 原因となる細菌を伴う肺感染症ではなく、原因となる細菌が存在し、肺に位置する炎症 (意味的リンクの後にアルファベット順にソートされた構成的特徴を持つ)
注記 1:これはシステム内で一意であり、明確です。
[出典:ISO 17115:2007, 2.4.4, 修正済み]
3.3.6
カテゴリ構造
主題分野の 用語体系 (3.4.2) を表現するための ドメイン制約の最小セット (3.1.14)
[出典:ISO 17115:2007, 2.4.5, 修正済み]
3.4 用語リソース（健康分野）
3.4.1
用語リソース
健康ドメインにおける制御された用語セット (3.1.2)
注記 1:通常、データ入力、集計、検索、分析など、健康分野における特定の目的でコンピュータで使用するために設計および制御されます。したがって、第 4 項に記載されているように、健康領域におけるユーザビリティ特性を備えています。
注記 2: これは、以下のタイプ (3.4.2 から 3.4.7) と一般的な関係があります。
3.4.2
用語体系
用語
概念表現システム
<health> 健康の概念と関係を人間と機械が読み取り可能な構造化表現
注記 1:すべての用語体系は 、階層関係 (3.2.3) および/または 結合関係 (3.2.4) によって編成されます。通常、ほとんどの用語体系は階層関係によって構成されています。
注記 2: すべての用語体系には、人間が読みやすいように健康概念の用語表現がなければなりません。
注記 3: これは、健康状態や医療活動などの健康概念を説明するために直接的または間接的に使用され、その後の分析のための検索を可能にします。
3.4.3
分類システム
統計的分類
分類
特定の目的のために事前に規定された専門レベルまでデータを集約するための、相互排他性と網羅性の特性を備えた用語リソース
注記 1: 2 つの追加特性は両方とも、データ集約機能 (5.4) を提供するために不可欠であり、したがって、統計分析とデータ集約の使用例に適合します。
注記 2: 通常、これには 階層関係 (3.2.3)、 定義および使用規則が含まれますが、性別の単純な分類例 (男性、女性) のように含まれない場合もあります。
注記 3: これは、必ずしも相互に排他的なカテゴリの事前定義された網羅的なセットで構成されているわけではありません。一部の分類システムには、相互排他性を可能にする明示的なルールがある場合があります。
3.4.4
コーディングシステム
一連の概念（コード化された概念）（3.1.1）、一連の コード（3.1.6） 値、およびコード値をコード化された概念にマッピングする少なくとも 1 つの コーディング スキーム（3.1.9） の組み合わせ
注記 1:コード化された概念は通常、用語によって表されますが、他の表現を持つこともできます。コード値は通常、数値または英数字です。
注記 2:国コードの ISO 3166-1 など、階層関係および/または結合関係による組織化のないコーディングシステムは、用語体系ではありません。
[出典:ISO 17115:2007, 2.7.3, 修正済み]
3.4.5
構成システム
構成用語
構成概念 表現 (3.3.2) の作成をサポートする用語 体系 (3.4.2)
注1：この定義は、「事後調整能力を有する用語体系」に相当する。構成システムが公理的で事前に調整された概念を含むことを妨げるものではありません。
注記 2: 事前定義された概念には公理的な概念が含まれる可能性があるため、構成システム内の事前定義された概念は、必ずしも 構成概念表現 (3.3.2) として表されるわけではありません。
[出典:ISO 17115:2007, 2.5.2, 修正済み]
3.4.6
命名法
事前に確立された命名規則に従って体系的に構造化された 構成システム (3.4.5)
例 1:
接頭辞または接尾辞における「-ane」、「-ene」、「ハロ-」、「ヒドロキシル-」などの分子ファミリーの命名規則は、組成概念の作成において事前に確立された命名規則の例です。
例 2:
SNOMED CT では、「完全指定名」では、事前に確立された多数の命名規則が使用されます。
[出典:ISO 1087‑1:2000, 3.5.3, 修正済み]
3.4.7
形式（概念表現）システム
対象分野における機械処理可能な一連の定義を含む 構成システム (3.4.5)
注記 1:事前定義概念の各定義は 、公理概念表現 (3.3.1) 、 構成概念表現 (3.3.2) 、または形式的拡張定義でなければなりません。
[出典:ISO 17115:2007, 2.5.1, 修正済み]
参考文献
| 1 | ISO 704, 用語作業 — 原則と方法 |
| 2 | ISO 1087-1:2000, 用語作業 — 語彙 — Part 1: 理論と応用 |
| 3 | ISO 17115:2007, 健康情報学 — 構成用語体系の語彙 |
| 4 | ISO/TS 17117:2002, 医療情報学 — 管理された健康用語 — 構造と高レベルの指標 |
| 5 | ISO 23185, 用語リソースの評価とベンチマーク - 一般概念、原則、要件 |
| 6 | CEN/ISSS eHealth 標準化フォーカス グループからのレポート (2005) eHealth ドメインにおける現在および将来の標準化問題: 相互運用性の達成 http://www.centc251.org/FocusGroup/ |
| 7 | 国家人口健康統計委員会、2000) 患者の医療記録情報の統一データ標準に関する米国保健福祉省長官への報告書 https://www.ncvhs.hhs.gov/wp-content/uploads/ 2014/08/hipaa000706.pdf |
| 8 | A.院長、臨床用語：なぜそんなに難しいのですか？ Methods Inf. Med. 1999, 38 (4) pp. 239–252 |
| 9 | Ingenerf J.、Pöppl SJ, 生物医学用語 – 差別化の要求。スタッドヘルステクノロジーInform. 2007, 129 (Pt 1) pp. 610–615 |
| 10 | Cornet R.、De Keizer NF, Abu-Hanna A.、用語体系を特徴付けるためのフレームワーク。 Methods Inf. Med. 2006, 45 pp. 253–266 |
| 11 | 溝口 R.、砂川 E.、小崎 K.、北村 Y.、オントロジー開発ツール内の役割のモデル: Hozo.応用オントロジージャーナル。 2007, 2 (2) pp. 159–179 |
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
NOTE Selected terms from ISO 1087-1 are given in Annex A as background to the terms and definitions in Clause 3.
3.1 General terms
3.1.1
concept
unit of knowledge created by a unique combination of characteristics
Note 1 to entry: Informally, the term ‘concept’ is often used when what is meant is ‘concept representation’. However, this leads to confusion when precise meanings are required. Concepts arise out of human individual and social conceptualizations of the world around them. Concept representations are artefacts constructed of symbols.
Note 2 to entry: Concept representations are not necessarily bound to particular languages. However, they are influenced by the social or cultural context of use often leading to different categorizations.
[SOURCE:ISO 1087‑1:2000, 3.2.1, modified]
3.1.2
term
linguistic representation of a concept in a specific subject field
[SOURCE:ISO 1087‑1:2000, 3.4.3, modified]
3.1.3
characteristic
abstraction of a property of an object or of a set of objects
[SOURCE:ISO 1087‑1:2000, 3.2.4]
3.1.4
term identifier
sequence of letters, numbers or symbols, capable of uniquely identifying a term within the terminological resource
Note 1 to entry: Term identifier shall be unique within the terminological resource.
3.1.5
concept identifier
canonical expression (3.3.5) , or sequence of letters, numbers or symbols, capable of uniquely identifying a concept within the terminological resource
Note 1 to entry: Concept identifier shall be unique within the terminological resource, so terms shall not be used for the purpose here in case polysemy exists.
3.1.6
code
identifier expressed by a series of letters, numbers, or symbols
Note 1 to entry: A code is a concept identifier (3.1.5) when used in a coding system (3.4.4) .
3.1.7
terminological resource identifier
unique permanent identifier of a terminological resource (3.4.1) for use in information interchange
Note 1 to entry: This is equivalent to Health Coding Scheme Designator in EN 1068:2005 for registration of coding systems.
Note 2 to entry: Globally unique schemes such as OIDs, UUIDs, and URIs may be used for this purpose.
3.1.8
terminological resource version identifier
version identifier
identifier assigned to a version under which a terminological resource (3.4.1) is published or updated
3.1.9
coding scheme
collection of rules that maps the elements in one set, the “coded set”, onto the elements in a second set, “the code set”
Note 1 to entry: The two sets are not part of the coding scheme.
[SOURCE:ISO 17115:2007, 2.7.2, modified]
3.1.10
composite characteristic
representation of a characteristic (3.1.3)
EXAMPLE:
has Cause Bacteria; Location = LeftUpperLobeOfLung.
Note 1 to entry: Typically expressed by a semantic link (3.2.5) and a characterizing concept (3.1.11) .
[SOURCE:ISO 17115:2007, 2.2.1]
3.1.11
characterizing concept
concept that is referenced by a semantic link (3.2.5) in a composite characteristic (3.1.10)
EXAMPLE:
“Bacterium” in the construct “Disease that has Cause Bacterium”; “Yellow” in the construct “Skin Lesion that has Colour Yellow”.
[SOURCE:ISO 17115:2007, 2.2.2]
3.1.12
characterizing generic concept
characterizing category
value domain
formal category whose specialization by a domain constraint (3.1.14) is allowed to be used as characterizing concept (3.1.11) in a particular context
EXAMPLE 1:
<INFECTIOUS_ORGANISM> ={bacterium, virus, parasite}, in the context of “infection that has Cause INFECTIOUS_ORGANISM”.
EXAMPLE 2:
has Cause Bacteria; Location = LeftUpperLobeOfLung.
Note 1 to entry: The context includes a superordinate concept and a semantic link.
[SOURCE:ISO 17115:2007, 2.3.3]
3.1.13
sanctioned characteristic
formal representation of a type of characteristics (3.1.3)
EXAMPLE 1:
performed Using <INSTRUMENT>; hasLocation <BodyPartOfImplantedDevice>.
EXAMPLE 2:
“Cause Of Inflammation can Be set{bacteria, virus, parasite, autoimmune, chemical, physical}” ここで, “can Be” is the semantic link, and “set{bacteria, virus, parasite, autoimmune, chemical, physical}” is the characterizing generic concept.
Note 1 to entry: A sanctioned characteristic is typically made up of a combination of a semantic link (3.2.5) and a characterizing generic concept (3.1.12) , and can be used in domain constraints (3.1.14) .
[SOURCE:ISO 17115:2007, 2.3.1]
3.1.14
domain constraint
sanction rule prescribing the set of sanctioned characteristics (3.1.13) that are valid to specialize a concept in a certain subject field
EXAMPLE:
“Infection possibly has Location Skeletal Structure” describes that an infection in a certain context can be located in a structure that is a kind of skeletal structure.
Note 1 to entry: The rule describes the set of potential characteristics by combining the semantic link (3.2.5) and the characterizing generic concept (3.1.12) it links to, possibly by enumeration of the concepts in the characterizing generic concept.
Note 2 to entry: Different levels of sanctioning are possible (e.g. conceivable, sensible, normal, usually In The Context Of, necessary).
[SOURCE:ISO 17115:2007, 2.3.2]
3.2 Relations between concepts
3.2.1
generic relation
generalization-specialization relation
relation between two concepts where the intension of one of the concepts includes that of the other concept and at least one additional delimiting characteristic
Note 1 to entry: A generic relation exists between the concepts ‘word’ and ‘pronoun’, ‘vehicle’ and ‘car’, ‘person’ and ‘child’.
Note 2 to entry: This relation is equivalent to ‘parent-child’ or ‘is-a’ relation. The child concept has the same intension as the parent concept and at least one additional delimiting characteristic. Also the same in X ‘is-a’ Y.
Note 3 to entry: The use of the term ‘relation’ from an English perspective means that this is describing the concept (i.e. this concept is a generic relation of another concept) not the relationship. However, the ‘generic relation’ here means the relationship itself, not a concept.
[SOURCE:ISO 1087‑1:2000, 3.2.21, modified]
3.2.2
partitive relation
whole-part relation
relation between two concepts where one of the concepts constitutes the whole and the other concept a part of that whole
Note 1 to entry: A partitive relation exists between the concepts ‘week’ and ‘day’, ‘molecule’ and ‘atom’.
Note 2 to entry: This relation is different from generic relation (3.2.1) . For example, a day is part of a week, but is not a specialization of a week, i.e. it is not a type of week.
[SOURCE:ISO 1087‑1:2000, 3.2.22, modified]
3.2.3
hierarchical relation
relation between two concepts which may be either a generic relation (3.2.1) or a partitive relation (3.2.2)
EXAMPLE:
Relations such as ‘stomach’ ↔ ‘organ’ and ‘stomach’ ↔ ‘body’ are hierarchical relations, but the former is a generic relation and the latter is a partitive relation.
Note 1 to entry: Partitive relations (3.2.2) have several sub-types, such as “constitutional part of”, “regional part of”, “grouped by”, and so on, which are also hierarchical types of relations.
Note 2 to entry: A characteristic which is explicitly identified in the terminological resource may be used to determine a hierarchy, and includes declaration of directionality. There may be more than one such characteristic in which case the terminological resource can be said to have “poly-hierarchy”. The characteristic must have a value in the two concepts at either end of the relation which can be compared to determine the hierarchy.
[SOURCE:ISO 1087‑1:2000, 3.2.20, modified]
3.2.4
associative relation
pragmatic relation
relation between two concepts having a non-hierarchical thematic connection by virtue of experience
EXAMPLE:
The relation between disease “X” and virus “Y” is not a hierarchical but an associative relation. The relation exists under a certain theme of interest (e.g. “a disease and its causative agent”) and explicitly recognized by virtue of experience.
[SOURCE:ISO 1087‑1:2000, 3.2.23, modified]
3.2.5
semantic link
formal representation of a directed associative relation (3.2.4) or partitive relation (3.2.2) between two concepts
EXAMPLE:
hasCause (with inverse isCauseOf).
Note 1 to entry: This includes all relations except the generic relation (3.2.1)
Note 2 to entry: A semantic link always has an inverse, i.e. another semantic link with the opposite direction.
[SOURCE:ISO 17115:2007, 2.2.3]
3.3 Formal concept representation
3.3.1
axiomatic concept representation
atomic concept representation
concept representation that is not composed of other simpler concept representations within a formal (concept representation) system (3.4.7)
EXAMPLE:
‘Liver’, ‘Incision act’, ‘Pain’
Note 1 to entry: In many cases, axiomatic concept representations will correspond to what philosophers call “natural kinds”. Such an entity cannot be meaningfully decomposed. These should form the basis of all concept representations.
Note 2 to entry: A coding system may include axiomatic concept representations as well as compositional concept representations required for different use cases.
[SOURCE:ISO 17115:2007, 2.4.2, modified]
3.3.2
compositional concept representation
composite concept representation
intensional definition of a concept using as delimiting characteristics one or more composite characteristics (3.1.10)
Note 1 to entry: Each characterizing concept (3.1.11) in a composite characteristic (3.1.10) may be axiomatic concept representation (3.3.1) or another compositional concept representation.
Note 2 to entry: This allows inference of subsumption within a formal (concept representation) system (3.4.7) . It is often expressed in a formalism, such as description logic.
Note 3 to entry: Compositional concept representation can be further divided into pre-coordinated concept representation (3.3.3) and post-coordinated concept representation (3.3.4) .
[SOURCE:ISO 17115:2007, 2.4.1, modified]
3.3.3
pre-coordinated concept representation
compositional concept representation (3.3.2) predefined within a formal (concept representation) system (3.4.7) , with an equivalent single unique concept identifier
EXAMPLE:
In SNOMED CT, “cancer of colon” is predefined and has a single unique identifier, which means to the SNOMED CT that it represents a “single” concept. However, “colon” is a synonym for “colon structure” and “cancer” is a synonym for “malignant neoplastic disease” in SNOMED CT. Therefore, “colon cancer” is non-atomic as it can be broken down into compositional concept representation (e.g. “cancer of colon” = “malignant neoplastic disease” < Finding_Site: “colon structure”>.).
[SOURCE:ISO 17115:2007, 2.4.6, modified]
3.3.4
post-coordinated concept representation
compositional concept representation (3.3.2) , which is not pre-coordinated and therefore shall be represented using more than one concept from one or many compositional systems (3.4.5), combined using mechanisms within or outside the compositional systems
EXAMPLE 1:
Problem.Main = Fracture, Problem.Location = Femur (within a template for a problem description).
EXAMPLE 2:
Some common terminological resources, such as IETF BCP-47 for language tags, explicitly construct post-coordinated concept representations from disparate coding systems for language, script, region, and so on.
Note 1 to entry: Combining concepts from disparate terminologies can cause problems with overlapping and/or conflicting concepts, because there might be various ways to form compositional concept representations for the same concept. Typically, the mechanisms for making compositional concept representations across disparate terminological resources are specified in an information model (e.g. as templates for a certain type of concept).
[SOURCE:ISO 17115:2007, 2.4.7, modified]
3.3.5
canonical expression
concept name
term (3.1.2) which uniquely designates a concept within a terminological system (3.4.2)
EXAMPLE 1:
Machine readable: <Inflammation that <hasCause Bacteria hasLocation Lung>>(with compositional characteristics sorted alphabetically after semantic link) instead of <pulmonaryInfection that hasCause Bacteria>
EXAMPLE 2:
General language: Inflammation that has cause bacteria and has location lung (with compositional characteristics sorted alphabetically after semantic link) instead of pulmonary infection that has cause bacteria.
Note 1 to entry: It is unique within the system and unambiguous.
[SOURCE:ISO 17115:2007, 2.4.4, modified]
3.3.6
categorial structure
minimal set of domain constraints (3.1.14) for representing terminological systems (3.4.2) in a subject field
[SOURCE:ISO 17115:2007, 2.4.5, modified]
3.4 Terminological resources (in health domain)
3.4.1
terminological resource
controlled set of terms (3.1.2) in health domain
Note 1 to entry: Usually designed and controlled for use with computers for a specific purpose in the health domain, such as data entry, aggregation, retrieval and analysis. Accordingly, it has usability characteristics in health domain as described in Clause 4.
Note 2 to entry: It has a generic relation to the following types (3.4.2 to 3.4.7).
3.4.2
terminological system
terminology
concept representation system
<health> structured human and machine-readable representation of health concepts and relationships
Note 1 to entry: Every terminological system shall be organized by hierarchical relations (3.2.3) and/or associative relations (3.2.4) . Typically, most terminological systems are organized by hierarchical relations.
Note 2 to entry: Every terminological system shall have term representations of health concepts for human-readability.
Note 3 to entry: It is used directly or indirectly to describe health concepts such as health conditions and healthcare activities, and allow their subsequent retrieval for analysis.
3.4.3
classification system
statistical classification
classification
terminological resource which has characteristics of mutual exclusiveness and exhaustiveness to aggregate data to a pre-prescribed level of specialization for a specific purpose
Note 1 to entry: Both of the two additional characteristics are indispensable to provide data aggregation function (5.4), and accordingly, to suit the use case for statistical analysis and data aggregation.
Note 2 to entry: It usually includes hierarchical relations (3.2.3) as well as definitions and rules for use but might not, as in the example simple classification of gender: Male, Female.
Note 3 to entry: It does not necessarily consist of a pre-defined exhaustive set of mutually exclusive categories. Some classification systems may have explicit rules to enable mutual exclusiveness.
3.4.4
coding system
combination of a set of concepts (coded concepts) (3.1.1), a set of code (3.1.6) values, and at least one coding scheme (3.1.9) mapping code values to coded concepts
Note 1 to entry: Coded concepts are typically represented by terms, but can have other representation. Code values are typically numeric or alphanumeric.
Note 2 to entry: Coding systems without organization by hierarchical relations and/or associative relations, such as ISO 3166-1 for country codes, are not terminological systems.
[SOURCE:ISO 17115:2007, 2.7.3, modified]
3.4.5
compositional system
compositional terminology
terminological system (3.4.2) that supports the creation of compositional concept representation (3.3.2)
Note 1 to entry: The definition is equivalent to “a terminological system that has an ability of post-coordination.” It does not preclude that a compositional system also includes axiomatic and pre-coordinated concepts.
Note 2 to entry: Pre-defined concepts in a compositional system are not necessarily represented as compositional concept representation (3.3.2) , since pre-defined concepts may include axiomatic concepts.
[SOURCE:ISO 17115:2007, 2.5.2, modified]
3.4.6
nomenclature
compositional system (3.4.5) structured systematically according to pre-established naming rules
EXAMPLE 1:
Naming rules for a family of molecules such as ‘—ane’, ‘—ene’, ‘halo—‘, ‘hydroxyl—‘ in prefix or suffix is an example of pre-established naming rules in the compositional concept creation.
EXAMPLE 2:
In SNOMED CT, “fully specified names” use a number of pre-established naming rules.
[SOURCE:ISO 1087‑1:2000, 3.5.3, modified]
3.4.7
formal (concept representation) system
compositional system (3.4.5) with a set of machine processable definitions in a subject field
Note 1 to entry: Each definition of a pre-defined concept shall be an axiomatic concept representation (3.3.1) , a compositional concept representation (3.3.2) or a formal extensional definition.
[SOURCE:ISO 17115:2007, 2.5.1, modified]
Bibliography
| 1 | ISO 704, Terminology work — Principles and methods |
| 2 | ISO 1087-1:2000, Terminology work — Vocabulary — Part 1: Theory and application |
| 3 | ISO 17115:2007, Health informatics — Vocabulary of compositional terminological systems |
| 4 | ISO/TS 17117:2002, Health informatics — Controlled health terminology — Structure and high-level indicators |
| 5 | ISO 23185, Assessment and benchmarking of terminological resources — General concepts, principles and requirements |
| 6 | Report from the CEN/ISSS eHealth Standardization Focus Group (2005) Current and future standardization issues in the eHealth domain: Achieving interoperability http://www.centc251.org/FocusGroup/ |
| 7 | NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS, 2000) Report to the Secretary of the U.S. Department of Health and Human Services on Uniform Data Standards for Patient Medical Record Information https://www.ncvhs.hhs.gov/wp-content/uploads/2014/08/hipaa000706.pdf |
| 8 | Rector A., Clinical terminology: why is it so hard? Methods Inf. Med. 1999, 38 (4) pp. 239–252 |
| 9 | Ingenerf J., Pöppl S.J., Biomedical vocabularies–the demand for differentiation. Stud. Health Technol. Inform. 2007, 129 (Pt 1) pp. 610–615 |
| 10 | Cornet R., De Keizer N.F., Abu-Hanna A., A framework for characterizing terminological systems. Methods Inf. Med. 2006, 45 pp. 253–266 |
| 11 | Mizoguchi R., Sunagawa E., Kozaki K., Kitamura Y., The model of roles within an ontology development tool: Hozo. Journal of Applied Ontology. 2007, 2 (2) pp. 159–179 |