diff --git a/CommonDataModel.Rmd b/CommonDataModel.Rmd index 7b7d9d8..adac693 100644 --- a/CommonDataModel.Rmd +++ b/CommonDataModel.Rmd @@ -1,201 +1,208 @@ # (PART) Uniform Data Representation {-} -# 공통 데이터 모델 {#CommonDataModel} +# The Common Data Model {#CommonDataModel} -*Chapter leads: Clair Blacketer* +*Chapter lead: Clair Blacketer* -관찰 데이터는 환자가 진료를 받는 동안 어떤 일들이 일어나는지를 보여준다. 전 세계적으로 점점 더 많은 수의 환자에 대한 데이터가 빅 데이터라고 불리는 형태로 수집 및 저장되고 있다. 이러한 수집의 목적은 다음과 같은 세 가지로 설명할 수 있다. (i) 직접적으로 (많은 경우에 설문 조사 및 레지스트리 정보를 활용한) 연구를 용이하게 하기 위해, (ii) 의료 행위 수행을 지원하기 위해 (이를 보통 전자 의무 기록(Electronic Health Records, EHR)이라고 함), 또는 (iii) 의료비 지불 관리를 위함 (청구 데이터). 세 가지 목적 모두 임상 연구에 보편적으로 사용되나, 두 번째 세 번째 항목은 이차적인 목적으로 사용된다. 위 세가지 모두 일반적으로 고유한 내용의 형식 및 인코딩으로 이루어져 있다. \index{Common Data Model} \index{CDM |see {Common Data Model}} \index{relational data model|see {Common Data Model}} +観察データは、医療を受けている間に患者に何が起こっているかを見ることができます。データは、世界中のますます多くの患者のために収集・保存され、ビッグヘルスデータと呼ばれるものが生み出されています。これらの収集の目的は3つあります。(i) 研究を直接促進するため（多くの場合、調査やレジストリデータの形で）、(ii) ヘルスケアの実施を支援するため（通常、EHR - Electronic Health Recordsと呼ばれる）、(iii) 診療の支払いを管理するため（通常、クレームデータと呼ばれる）である。この3つはいずれも臨床研究に日常的に利用されており、後者の2つは二次利用データとして利用されており、一般的には3つとも独自のフォーマット化と内容の符号化が行われている。\index{CDM |参照 {Common Data Model}} \index{relational data model|参照 {Common Data Model}} -관찰형 의료 데이터(Observational healthcare data)에 공통 데이터 모델이 필요한 이유는 무엇일까? -일차적인 목적에 의해 모든 임상적인 사건들을 동일하게 포착하는 관찰형 데이터베이스(Observational database)는 없다. 따라서, 여러 다른 데이터 출처에서 연구 결과를 도출하고 데이터를 포착하는 과정에서 발생하는 잠재적 비뚤림(bias)의 영향을 이해하기 위해 이를 비교 및 대조해야 한다. 또한 통계적 검증력을 갖춘 결론을 도출하려면 많은 수의 관찰 환자가 필요하다. 이는 여러 데이터 출처를 동시에 평가하고 분석해야 할 필요성을 설명한다. 그러기 위해서는 데이터를 공통 데이터 표준(common data standard)으로 화합할 필요가 있다. 게다가 환자 데이터는 높은 수준의 보안이 필요하다. 기존에 그래왔듯이 분석을 목적으로 하는 데이터 추출은 엄격한 데이터 사용 계약 및 복잡한 접근 제어 방식이 필요하다. 공통 데이터 표준은 추출 단계를 생략하고 기본 환경의 데이터에 대해 표준화된 분석을 실행할 수 있도록 하여 이러한 필요성을 줄여 줄 수 있다 - 분석환경으로 데이터가 오는게 아니고 데이터가 있는 장소로 분석환경이 오는 것. +なぜ観察医療データのための共通データモデルが必要なのか？ -이러한 표준은 공통 데이터 모델(Common Data Model, CDM)에 의해 제공된다. CDM은 표준화된 내용을 기반으로 (\@ref(StandardizedVocabularies)장 참조) 연구 방법들이 효과적으로 비교 가능하고 재현 가능한 결과를 얻을 수 있게 체계적으로 활용되게 한다. 이 장에서는 데이터 모델을 비롯한 디자인, 규칙 및 테이블 선택에 대한 논의를 제공하고자 한다. +主なニーズにもよりますが、どの観察データベースもすべての臨床イベントを等しく把握しているわけではありません。そのため、研究結果は多くの異種データソースから得られ、潜在的な捕捉バイアスの影響を理解するために比較対照しなければなりません。さらに、検定力を持った結論を出すためには、大量の観察患者が必要です。そのため、複数のデータソースを同時に評価し、分析する必要があることを説明しています。そのためには、データを共通のデータ標準に調和させる必要があります。また、患者データには高いレベルでの保護が必要です。従来のように分析目的でデータを抽出するには、厳格なデータ利用契約と複雑なアクセス制御が必要です。共通データ標準は、抽出ステップを省略し、標準化された分析をネイティブな環境で実行できるようにするー分析者にデータを提供するのではなく、データ上で分析を実行できるようにすることで、この必要性を軽減することができます。 -CDM내의 모든 테이블에 대한 개요는 그림 \@ref(fig:cdmDiagram) \index{Common Data Model!data model diagram}에서 살펴볼 수 있다. +この標準は、Common Data Model (CDM)によって提供されます。CDMは、その標準化された内容と組み合わせることで（\@ref(StandardizedVocabularies)章参照）、研究方法を体系的に適用して、意味のある比較可能で再現性のある結果を生み出すことができるようになります。本章では、データモデル自体の概要、デザイン、規約、および選択された表について説明します。 -```{r cdmDiagram, fig.cap="CDM 6.0 버전의 모든 테이블에 대한 개요. 테이블 간의 모든 관계가 표시된 것은 아님.",echo=FALSE, out.width="100%"} +CDMのすべてのテーブルの概要は、図 \@ref(fig:cdmDiagram) に掲載されています。\index{Common Data Model!data model diagram} + +```{r cdmDiagram, fig.cap="Overview of all tables in the CDM version 6.0の全てのテーブルの概容.全てのリレーションシップが提示されていないことに留意。",echo=FALSE, out.width="100%"} knitr::include_graphics("images/CommonDataModel/cdmDiagram.png") ``` -## 설계 원리 +## Design Principles + +CDMは\index{Common Data Model!design principles}の典型的な観測研究目的に最適化されています。 -CDM은 다음과 같은 목적의 전형적인 관찰 연구에 최적화되어 있다.\index{Common Data Model!design principles} +* 特定の医療介入（薬物曝露、処置、医療政策の変更など）とその結果（状態、処置、他の薬物曝露など）を持つ患者集団を特定すること +* 人口統計学的情報、病歴、医療提供、利用とコスト、罹患率、治療法、一連の治療などの様々なパラメータについて、これらの患者集団の特性化を行うこと +* 個々の患者におけるこれらの転帰の発生を予測すること-\@ref(PatientLevelPrediction)章を参照のこと。 +* これらの介入が集団に与える効果を推定すること-\@ref(PopulationLevelEstimation)章を参照のこと。 -* 특정한 의료 행위의 개입 (약물 노출, 시술(procedure), 의료 정책 변경 등)이 있거나 의료 관련 결과 (질환, 시술, 기타 약물 노출에 대한)를 포함하는 환자 집단 확인. -* 인구 통계학적 정보, 질병의 자연사, 의료 서비스 전달, 활용 및 비용, 병적 상태, 치료 및 치료 과정 등과 같은 다양한 매개 변수에 대한 환자 집단의 특성 확인. -* 개별 환자에서 결과의 발생 예측 - \@ref(PatientLevelPrediction)장 참고, -* 앞서 설명한 의료 행위의 개입이 인구에 미치는 영향 추정 - \@ref(PopulationLevelEstimation)장 참고, +この目的を達成するために、CDMの開発は以下の設計方針に従っています。 + - **目的の適合性**: CDMは、医療提供者や支払者の運用ニーズに対応することを目的とするのではなく、分析に最適な方法で整理されたデータを提供することを目的とします。\index{Common Data Model!suitability for purpose} + - **データ保護**: 患者さんの氏名、正確な生年月日など、患者さんの身元や保護に危険を及ぼす可能性のあるデータはすべて制限されています。乳幼児の研究のための正確な生年月日など、研究でより詳細な情報が必要な場合は例外となります。 + - **ドメインの設計**:ドメインは人物中心のリレーショナル・データ・モデルでモデル化されており、各レコードについて、人物の身元と日付が最低限の情報として取得されています。ここでいうリレーショナル・データ・モデルとは、データが主キーと外部キーでリンクされたテーブルの集合として表現されるものです。 + - **ドメインの根拠**: ドメインは、分析のユースケース（症状など）があり、ドメインが他に適用できない特定の属性を持っている場合、エンティティ-リレーションシップモデルで識別され、個別に定義されます。 他のすべてのデータは、エンティティ-属性-値構造の観測テーブルの観測として保存することができます。\index{Common Data Model!domains} + - **標準化された用語集**: 記録の内容を標準化するために、CDMは、必要かつ適切な対応する標準的な医療概念をすべて含んだ標準用語集に依存しています。 + - **既存の用語集の再利用**: 国立医学図書館、退役軍人局、疾病管理予防センターなど、国や業界の標準化や用語集を定義する組織やイニシアティブを活用します。 + - **ソースコードの管理**: すべてのコードが標準用語にマッピングされているにもかかわらず、モデルは情報が失われないように元のソースでのコードも保存します。\index{Common Data Model!Source Codes} \index{Common Data Model!data loss prevention} + - **技術的中立性**: CDMは特定の技術を必要としません。Oracle, SQL Serverなどのリレーショナルデータベースでも、SASの分析データセットでも実現可能です。 + - **スケーラビリティ**: CDMは、数億人規模の患者や数十億規模の臨床観察など、あらゆる規模のデータソースに対応できるよう、データ処理や計算解析のために最適化されています。\index{Common Data Model!scalability}: + - **下位互換性**: 以前のCDMからの変更点はすべてgithubリポジトリ[(https://github.com/OHDSI/CommonDataModel)](https://github.com/OHDSI/CommonDataModel)に明記されています。古いバージョンのCDMは、現在のバージョンから簡単に作成することができ、以前に存在していた情報が失われることはありません。\index{Common Data Model!backwards compatibility} -이러한 목표를 달성하기 위해서 CDM의 개발은 다음과 같은 설계 요소를 따른다: + +## Data Model Conventions - - - **목적에 대한 적합성**: CDM은 의료 서비스 제공이나 보험청구 업무를 해결하기 위한 목적 보다는 분석에 최적화된 방식으로 구성된 데이터를 제공하는 것을 목표로 한다. \index{Common Data Model!suitability for purpose} - - **데이터 보호**: 이름, 생년월일 등 환자의 신원 및 안전을 위협할 수 있는 모든 데이터는 제한되어 있다. 영아에 대한 연구를 위한 정확한 생년 월일과 같은 보다 자세한 정보가 명시적으로 필요한 경우에는 예외가 가능하다.\index{Common Data Model!data protection} - - **도메인 설계**: 도메인은 개인 중심 관계형 데이터 모델(person-centric relational data model)로 모델링 되며 각 기록마다 개인의 신원과 날짜 정보가 최소한으로 수집된다. 여기서 관계형 데이터 모델은 데이터가 기본 키와 외래 키로 연결된 테이블들로 표현되는 모델이다. - - **도메인의 이론적 근거**: 개체-관계 모델(entity-relationship model)에서 도메인은 분석 이용 사례가 있는지 (예를 들면, 질환(conditions)) 그리고 달리 적용 가능한 방안이 없는 특정한 속성(attributes)이 있는지에 따라서 별도로 정의된다. 다른 모든 데이터는 개체-속성-값 구조(entity-attribute-value structure)를 가진 Observation 테이블에 관찰 데이터로 저장할 수 있다. \index{Common Data Model!domains} - - **표준화된 어휘**: 기록을 표준화하기 위해, CDM은 필수적이고 적절한 표준 건강 관리 Concept을 포함하는 표준 어휘에 의존한다. - - **기존 어휘 재사용**: 이러한 개념은 국립 의학 도서관, 재향 군인 담당 부서, 질병 통제 및 예방 센터 등과 같은 국가 및 산업 표준화 또는 용어 정의 주도 기관이나 협회에서 만든 어휘를 재사용하기도 한다. - - **원본 코드 유지 관리**: 모든 코드가 표준화된 어휘에 매핑되어 있더라도 정보가 소실되지 않도록 원본 코드도 저장한다. \index{Common Data Model!Source Codes} \index{Common Data Model!data loss prevention} - - **기술 중립성**: CDM은 특정 기술만을 채택하지 않는다. Oracle, SQL Server 등과 같은 관계형 데이터베이스 또는 SAS 분석 데이터 세트로도 구현될 수 있다. \index{Common Data Model!technology neutrality} - - **확장성**: CDM은 데이터 처리 및 컴퓨터를 이용한 분석에 최적화되어 있기 때문에 수 십 억 건에 달하는 임상 관찰을 비롯하여 수 억 명이 포함된 데이터베이스 등 다양한 크기의 원천 데이터를 수용할 수 있다. \index{Common Data Model!scalability} - - **이전 버전과의 호환성**: 이전 CDM로부터의 모든 변경 사항은 github 저장소 [(https://github.com/OHDSI/CommonDataModel)](https://github.com/OHDSI/CommonDataModel)에 명확하게 서술되어 있다. CDM의 이전 버전은 현재 버전을 이용해 쉽게 만들 수 있으며, 이전에 있었던 정보는 손실되지 않는다. \index{Common Data Model!backwards compatibility} +CDMで採用されている暗黙的規約と明示的規約がいくつかあります。CDMに対して実行されるメソッドの開発者は、これらの規約を理解する必要があります。 \index{Common Data Model!conventions} -## 데이터 모델 규칙 +### General Conventions of the Model{#model-Conv} -CDM에 채택된 많은 묵시적 혹은 명시적인 규칙이 있다. 따라서, CDM에 관련된 메소드 개발자들은 이러한 규칙을 잘 이해하고 있어야 한다. \index{Common Data Model!conventions} +CDM は「個人指向(person-centric)」モデルと考えられており、すべての臨床イベントテーブルが PERSON テーブルにリンクされています。これによって日付や開始日とともに、すべての医療関連イベントを個人別に縦断的に閲覧できるようになっています。この規則の例外は、標準化された医療システムのデータテーブルであり、さまざまなドメインのイベントに直接リンクされています。 -### 모델의 일반적인 규칙{#model-Conv} +### General Conventions of Schemas -CDM은 “개인 중심”의 모델로서, 모든 임상적인 사건에 대한 테이블이 PERSON 테이블을 중심으로 연결되어 있다. 시작 날짜 및 기타 날짜 정보들과 더불어 이는 모든 의료 관련 사건에 대해 각 사람별로 종적 관찰이 가능하도록 한다. 이 규칙에 예외적으로, 표준화된 의료체계 데이터 테이블(standardized health system data tables)은 다양한 도메인의 사건에 직접 연결되어 있다. +スキーマ、またはいくつかのシステムにおけるデータベースユーザーは、読み取り専用テーブルと読み取り書込みテーブルを分離することができます。臨床イベントと用語集テーブルは "CDM "スキーマにあり、エンドユーザーや分析ツールにとっては読み取り専用とみなされます。Webベースのツールやエンドユーザーが操作する必要のあるテーブルは「Results」スキーマに格納されます。Results」スキーマの2つのテーブルは、COHORTとCOHORT_DEFINITONです。これらのテーブルは、ユーザーが定義する可能性のある関心のあるグループを記述することを意図しており、\@ref(Cohorts)章で詳しく説明しています。これらのテーブルは書き込めるので、実行時にCOHORTテーブルにコホートを格納することができます。すべてのユーザに対して1つの読み書きスキーマしかないので、複数のユーザのアクセスをどのように組織化して制御するかはCDMの実装次第です。 -### 스키마의 일반적인 규칙 +### General Conventions of Data Tables -스키마 또는 데이터베이스 사용자는 읽기 전용 테이블과 읽기/쓰기 테이블을 분리할 수 있다. 임상 사건 및 어휘 테이블은 “CDM” 스키마에 저장되어 있으며 최종 사용자 또는 분석 도구에서는 읽기 전용으로 이용된다. 웹 기반 도구 및 최종 사용자가 조작할 필요가 있는 테이블은 “Outcome” 스키마에 저장된다. "Outcome" 스키마의 두 테이블은 COHORT와 COHORT_DEFINITON이다. 이 테이블들은 \@ref(Cohorts)장에 자세히 설명되어 있는 것처럼 사용자가 정의할 수 있는 관심 그룹을 설명하기 위한 것이다. 이는 분석 중에 테이블이 작성될 수 있음을, 즉 새로 생성한 코호트가 COHORT 테이블에 저장될 수 있다는 것을 의미한다. 모든 사용자를 위한 읽기-쓰기 스키마는 단 하나뿐이므로, 여러 사용자 접근이 어떻게 구성되고 제어되는지는 CDM의 구현에 달려 있다. +CDMはプラットフォームに依存しません。データ型は、ANSI SQLデータ型（VARCHAR、INTEGER、FLOAT、DATE、DATETIME、CLOB）を使用して一般的に定義されています。精度はVARCHARのみに提供されます。これは、最低限必要な文字列の長さを反映していますが、具体的なCDMのインスタンス内で拡張することができます。CDM は、date と datetime のフォーマットを規定していません。CDMに対する標準的なクエリは、ローカル・インスタンスと日付/日付時間構成のために異なるかもしれません。 -### 데이터 테이블의 일반적인 규칙 +*注*: データモデル自体がプラットフォーム非依存である一方、それを使用するために構築されたツールの多くは、特定の環境を必要とします。この詳細は、\@ref(OhdsiAnalyticsTools)章を参照してください。 -CDM은 플랫폼에 비의존적이다. 데이터 유형은 일반적으로 ANSI SQL 데이터 유형(VARCHAR, INTEGER, FLOAT, DATE, DATETIME, CLOB)을 사용하여 정의된다. VARCHAR에서만 정밀도가 제공된다. 이는 필요한 최소 문자열 길이를 반영하지만 구체적인 CDM 인스턴스 내에서 확장할 수 있다. CDM은 날짜 및 날짜시간 형식을 규정하지 않는다. CDM에 대한 표준 쿼리는 로컬 인스턴스 및 날짜/시간 구성에 따라 달라질 수 있다. +### General Conventions of Domains{#domains} -*참고*: 데이터 모델 자체는 플랫폼에 독립적이지만, 데이터 모델과 함께 작동하도록 구축된 여러 도구는 특정 사양이 요구된다. 이에 대한 자세한 내용은 \@ref(OhdsiAnalyticsTools)장 참조. +異なる性質のイベントは、ドメインに編成されます。これらのイベントは、ドメイン固有のテーブルとフィールドに格納され、標準化された用語集で定義されたドメイン固有の標準概念によって表現されます。各標準概念は、どのテーブルに記録されるかを定義する独自のドメイン割り当てを持っています。正しいドメインの割り当てについてコミュニティで議論されていますが、この厳密なドメイン-テーブル-フィールド対応規則により、どのようなコードや概念にも常に格納すべき場所が明確になっていることが保証されています。例えば、徴候、症状、診断の概念はConditionドメインのものであり、CONDITION_OCCURRENCEテーブルのCONDITION_CONCEPT_IDに記録されます。いわゆる処置薬(Procedure Drugs)は、通常、ソースデータの処置テーブルにおいて処置コードを用いて記録されます。CDMでは、これらのレコードはDRUG_EXPOSUREテーブルに記録されています。表 \@ref(tab:domains)に示されているように、合計30のドメインがあります。 -### 도메인의 일반적인 규칙{#domains} +Table: (\#tab:domains) それぞれのドメインに所属する標準概念の個数 -서로 다른 성격의 사건들은 도메인 별로 정리되어 있다. 이러한 사건들은 도메인별로 테이블과 필드에 저장되고, 표준화된 어휘에 정의되어 있는 대로 도메인별 표준 Concept으로 표현된다 (\@ref(conceptDomains)절 참조). 각 표준 Concept에 고유한 도메인이 할당되는데, 이는 어떤 테이블에 기록되어야 하는지를 정의한다. 정확한 도메인 할당은 커뮤니티내에서 항상 논의의 대상이 되지만, 엄격한 도메인-테이블-필드간 대응 규칙은 어떠한 코드나 Concept에 대해서도 항상 정확성을 보장한다. 예를 들어, 증상 및 진단 Concept은 Condition 도메인에 속하며 Condition_OCCURRENCE 테이블의 CONDITION_CONCEP_ID로 기록된다. 소위 말하는 시술시 사용되는 약품은 일반적으로 원천 데이터에서는 Procedure 테이블에 Procedure 코드로 기록되지만, CDM에서는 이러한 정보는 매핑된 표준 Concept이 약물 도메인에 할당 되어있기 때문에 DRUG_EXPOSURE 테이블에 저장한다. 표 \@ref(tab:domains)과 같이 총 30개의 도메인이 있다. +|Concept Count|Domain ID|Concept Count|Domain ID +|:---------- |:---------------------------- |:---------- |:---------------------------- +|1731378|Drug|183|Route +|477597|Device|180|Currency +|257000|Procedure|158|Payer +|163807|Condition|123|Visit +|145898|Observation|51|Cost +|89645|Measurement|50|Race +|33759|Spec Anatomic Site|13|Plan Stop Reason +|17302|Meas Value|11|Plan +|1799|Specimen|6|Episode +|1215|Provider Specialty|6|Sponsor +|1046|Unit|5|Meas Value Operator +|944|Metadata|3|Spec Disease Status +|538|Revenue Code|2|Gender +|336|Type Concept|2|Ethnicity +|194|Relationship|1|Observation Type -Table: (\#tab:domains) 각 도메인에 속하는 표준 Concept의 수. +### Representation of Content Through Concepts -Concept Count|Domain ID|Concept Count|Domain ID -:---------- |:---------------------------- |:---------- |:---------------------------- -1731378|Drug|183|Route -477597|Device|180|Currency -257000|Procedure|158|Payer -163807|Condition|123|Visit -145898|Observation|51|Cost -89645|Measurement|50|Race -33759|Spec Anatomic Site|13|Plan Stop Reason -17302|Meas Value|11|Plan -1799|Specimen|6|Episode -1215|Provider Specialty|6|Sponsor -1046|Unit|5|Meas Value Operator -944|Metadata|3|Spec Disease Status -538|Revenue Code|2|Gender -336|Type Concept|2|Ethnicity -194|Relationship|1|Observation Type - -### Concept을 통한 내용 표현 +CDMデータテーブルでは、各レコードの内容は完全に正規化され、概念によって表現されます。概念は、一般的な参照テーブルとして機能するCONCEPTテーブルへの外部キーであるCONCEPT_ID値を持つイベントテーブルに格納されます。すべてのCDMインスタンスは、概念への参照として同じCONCEPTテーブルを使用し、これは共通データモデルとともに相互運用性の鍵となるメカニズムであり、OHDSI研究ネットワークの基礎となっています。標準概念が存在しないか、または識別できない場合、CONCEPT_IDの値は0に設定され、存在しない概念、未知の値、またはマッピング不可能な値を表します。 -CDM 테이블에서는 각 정보의 내용이 완전히 정규화되어 Concept으로 저장된다. Concept은 CONCEPT 테이블의 외래 키 역할을 하는 각각의 CONCEPT_ID 값이 할당되어 사건 테이블에 저장된다. CDM의 모든 인스턴스는 (Concept에 대한 참고 자료로써 공통 데이터 모델과 함께 상호운용의 핵심 메커니즘이자 OHDSI 연구 네트워크의 기반인) 동일한 CONCEPT 테이블을 사용한다. 표준 Concept이 없거나 식별되지 않는 경우에는 CONCEPT_ID가 존재하지 않는 Concept이거나 알 수 없음 또는 매핑이 불가능함을 의미하는 0으로 설정된다 (즉, CONCEPT_ID = 0). +CONCEPTテーブルのレコードには、各概念に関する詳細な情報（名前、ドメイン、クラスなど）が含まれています。概念、概念の関係、概念の祖先、およびその他の概念に関する情報は、標準化された用語集の表に記載されています（\@ref(StandardizedVocabularies)章参照）。 -CONCEPT 테이블의 정보는 각각의 Concept에 대한 상세 정보 (이름, 도메인, 클래스 등) 를 포함하고 있다. Concepts, Concept Relationships, Concept Ancestors 및 다른 Concept과 관련 있는 정보들은 표준화된 용어에 포함되어 있다 (\@ref(StandardizedVocabularies)장 참조). -### 필드 명명 규칙 +### General Naming Conventions of Fields -모든 테이블의 변수명은 하나의 규칙을 따른다: +すべてのテーブルの変数名は、1つの規則に従います。: -Table: (\#tab:fieldConventions) 필드 명 규칙. +Table: (\#tab:fieldConventions) フィールド名の規則 |Notation|Description| |:------------------------------|:-------------------------------------------------------| -|[Event]_ID|각 행의 고유 식별자로, 사건 테이블간 관계를 설정하는 외래 키 역할을 한다. 예를 들어 PERSON_ID는 각 개인을 고유하게 식별한다. VISIT_OCCURRENCE_ID는 방문을 고유하게 식별한다.| -|[Event]_CONCEPT_ID|CONCEPT 참고 테이블의 표준 Concept에 대한 외래 키. 이는 모든 분석에 기반이 되는 사건의 주요 표현이다. 예를 들어 CONDITION_CONCEPT_ID = [31967](http://athena.ohdsi.org/search-terms/terms/31967)에는 SNOMED Concept인 “오심 Nausea”에 대한 참조 값을 포함하고 있다.| -|[Event]_SOURCE _CONCEPT_ID|CONCEPT 참고 테이블의 행에 대한 외래 키. 이 Concept은 원본 값(아래)과 동등하며, 이때 [EVENT_CONCEPT_ID]와 동일한 표준 개념이거나 또 다른 비-표준 concept일 수 있다. 예를 들어, Condition_SOURCE_CONCEPT_ID = [45431665](http://athena.ohdsi.org/search-terms/terms/45431665)는 READ 용어집의 "Nausea" 개념을 나타내며, 유사한 CONDITION_CONCEPT_ID는 표준 SNOMED-CT concept으로 [31967](http://athena.ohdsi.org/search-terms/terms/31967)이다. 표준 Concept만이 사건의 의미를 모호하지 않게 표현하므로 표준 분석에 응용 시 상호 운용성이 없는 원본 개념(SOURCE _CONCEPT)을 사용하는 것은 바람직하지 않다.| -|[Event]_TYPE_CONCEPT_ID|원본 정보의 출처를 나타내는 CONCEPT 참고 테이블(CONCEPT reference table)에 대한 외래 키. 이는 사건의 유형이나 concept의 유형을 나타내는 것이 아니라 이 기록를 생성한 메커니즘에 대한 정보를 수집하는 것을 의미한다. 예를 들면, DRUG_TYPE_CONCEPT_ID는 이 기록이 약국에서의 처방 (“Pharmacy dispensing”) 으로 부터 발생하였는지 혹은 전자 처방 신청서 (“Prescription written”) 로부터 발생하였는지를 구분한다.| -|[Event]_SOURCE_VALUE|이 사건이 원천 데이터에 표현되어 있는 방식 그대로 쓰여진 코드 혹은 자유서술 문자열이다. 이 원본 값들은 데이터 원본간에 통일되어 있지 않으므로 표준 분석 방식에 사용하는 것은 좋지 않다. 예를 들면, CONDITION_SOURCE_VALUE는 ICD-9 코드 787.02에 점을 제외하고 “78702”라는 기록를 포함할 수 있다.| +|[Event]_ID| 各レコードの一意の識別子で、イベントテーブル間の関係を確立するための外部キーとして機能します。例えば、PERSON_ID は各個人を一意に識別します。VISIT_OCCURRENCE_IDは来院を一意に識別します。| + +|[Event]_CONCEPT_ID|CONCEPT参照テーブルの標準コンセプトレコードへの外部キー。これはイベントの主な表現であり、すべての標準化された分析の基盤となります。例えば、CONDITION_CONCEPT_ID = [31967](http://athena.ohdsi.org/search-terms/terms/31967)にはSNOMEDコンセプトの「吐き気」への参照値が含まれています。| + +|[Event]_SOURCE _CONCEPT_ID|CONCEPT参照テーブル内のレコードへの外部キー。この概念はSource Value(下記)と同等のもので、たまたま標準概念になっている場合もあり、その場合は[Event]_CONCEPT_ID、または別の非標準概念と同一のものになります。例えば、CONDITION_SOURCE_CONCEPT_ID = [45431665](http://athena.ohdsi.org/search-terms/terms/45431665)は、Read用語集では "Nausea "の概念を表し、類似のCONDITION_CONCEPT_IDは、標準SNOMED-CT概念[31967](http://athena.ohdsi.org/search-terms/terms/31967)です。標準概念だけがイベントの意味的な内容を曖昧さのない方法で表現できるため、標準分析アプリケーションにおいて相互互換性のないソース概念を使用することは推奨されません。| -### concept과 원본 값과의 차이{#concepts-Sources} +|[Event]_TYPE_CONCEPT_ID | CONCEPT参照テーブルのレコードへの外部キーで、標準化された用語集の中で標準化されたソース情報の元となるレコードを表します。フィールド名にもかかわらず、これはイベントのタイプや概念のタイプではなく、このレコードを作成したキャプチャメカニズムを宣言していることに注意してください。例えば、DRUG_TYPE_CONCEPT_IDは、薬剤レコードが薬局での調剤イベント（"Pharmacy dispensing"）またはe-prescribingアプリケーション（"Prescription written"）から派生したものであるかを識別します。| -많은 테이블이 원본 값, 원본 concept, 표준 concept으로 다양한 위치에 동일한 정보를 포함하고 있다. +|[Event]_SOURCE_VALUE|このイベントがソースデータでどのように表現されたかを反映したコードまたはフリーテキスト文字列です。これらのソース値はデータソース間で調整されていないため、標準的な分析アプリケーションでは使用しないでください。たとえば、CONDITION_SOURCE_VALUEには、ドットを省略した表記で書かれたICD-9コード787.02に対応する「78702」のレコードが含まれている場合があります。| -* **Source Values** 은 원천 데이터에서의 사건 기록의 본래 표현이다. 이는 ICD9CM, NDC 또는 Read와 같은 널리 사용되는 공공 도메인의 코딩 시스템이나 CPT4, GPI 또는 MedDRA와 같이 독점적인 코딩 시스템, 혹은 남성은 M 여성은 F와 같이 원천 데이터에서만 사용되는 제한된 어휘의 코드일 수 있다. 또한 표준화 및 제어되지 않은 짧은 자유 텍스트 문구 일 수도 있다. 원본 값은 데이터 테이블의 [Event] _SOURCE_VALUE 필드에 저장된다. concept은 임상적 요소의 의미를 일반화하는 CDM 특이적인 개체이다. 대부분의 concept은 이미 의료계에 존재하는 공개되었거나 독점적인 코딩 체계를 기반으로 하고 있지만, 일부는 새롭게 생성되었다 (CONCEPT_CODE는 “OMOP”으로부터 시작됨). concept은 모든 도메인에 걸쳐 고유한 ID를 가지고 있다. -* **Concepts** 은 임상적 요소의 의미를 일반화하는 CDM 특이적인 개체이다. 대부분의 concept은 이미 의료계에 존재하는 공개되었거나 독점적인 코딩 체계를 기반으로 하고 있지만, 일부는 새롭게 생성되었다 (CONCEPT_CODE는 “OMOP”으로부터 시작됨). concept은 모든 도메인에 걸쳐 고유한 ID를 가지고 있다. -* **Source Concepts** 은 원 자료에서 사용된 코드를 나타내는 concept이다. 원본 concept은 OMOP기반의 concept이 아니라 기존에 존재하는 공개되었거나 독점적인 코딩 체계만을 위해 사용한다. 원본 concept은 데이터 테이블의 [Event] _SOURCE_CONCEPT_ID 필드에 저장된다. -* **Standard Concepts** 은 모든 데이터 베이스에서 고유하게 임상적인 개체의 의미를 정의하는 데에 사용되고 원본에서 사용한 코딩 체계와는 독립적인 concept이다. 표준 concept은 일반적으로 이미 공개되어 있거나 독점적인 용어 원본에서 가져온다. 표준 concept과 동일한 의미를 가진 비 표준 concept은 표준 용어의 표준 concept에 매핑되어 있다. 표준 concept은 데이터 테이블의 [Event] _CONCEPT_ID 필드에서 참조된다. +### Difference Between Concepts and Source Values{#concepts-Sources} -원본 값은 편의 및 품질 보증(Quality Assurance, QA) 목적으로만 제공된다. 여기에는 특정 데이터 원본의 맥락에서만 의미 있는 정보가 포함될 수 있다. 원본 값이나 원본 concept을 사용하는 것은 선택사항이지만, 원본 데이터가 코딩 시스템을 사용하는 경우 **강력하게 권장**된다. 하지만 표준 concept의 경우 **필수 사항**이다. 이 표준 concept을 필수적으로 사용하면 모든 CDM 인스턴스가 동일한 언어를 사용할 수 있다. 예를 들면 “Pulmonary Tuberculosis” (TB, 그림 \@ref(fig:pulmTubICD9)참조)의 condition은 TB에 대한 ICD9CM 코드가 011임을 나타낸다. +多くのテーブルは、ソース値、ソース概念、および標準概念として、複数の場所に同等な情報を保有しています。 -```{r pulmTubICD9, fig.cap="Pulmonary Tuberculosis의 ICD9CM 코드",echo=FALSE, out.width="75%", fig.align="center"} +* **ソース値**は、ソースデータ内のイベントレコードの元の表現です。ソース値は、ICD9CM、NDC、Read のようなパブリックドメインであることが多く広く使われているコーディング体系のコード、CPT4、GPI、MedDRA のような独自のコーディング体系、またはソースデータでのみ使用されている統制用語(女性の場合は F、男性の場合は M）のようなコードであることがあります。また、標準化されておらず管理されていない短いフリーテキストのフレーズでもよいです。ソース値はデータテーブルの[Event]_SOURCE_VALUE フィールドに格納されます。 +* **概念**は、臨床事実の意味を正規化するCDM固有のエンティティです。ほとんどの概念は、医療における既存の公的または独自のコーディング体系に基づいていますが、他のコンセプトは（CONCEPT_CODEは "OMOP "で始まる）一から作成されたものもあります。概念はすべてのドメインで一意のIDを持っています。 +* **ソース概念**は、ソースで使用されているコードを表す概念です。ソース概念は、既存の一般公開されたまたは独自のコーディング体系にのみ使用され、OMOPで作成された概念には使用されません。ソース概念は、データテーブルの [Event]_SOURCE_CONCEPT_ID フィールドに格納されます。 +* **標準概念**とは、すべてのデータベースにまたがる臨床エンティティの意味を一意に定義するために使用される概念であり、ソースで使用されるコーディング体系とは独立しています。標準概念は、通常、既存の公開または独自の用語集ソースから引用されます。標準概念と同等の意味を持つ非標準概念は、標準化された語彙の中で標準概念にマッピングされているます。標準概念は、データテーブルの[Event]_CONCEPT_IDフィールドで参照されます。 + +ソース値は、利便性と品質保証（QA）の目的のためにのみ提供されます。それらは、特定のデータ ソースのコンテキストでのみ意味を持つ情報を含んでいる場合があります。ソース値とソース概念の使用は任意ですが、ソース・データがコーディング・システムを使用している場合は***強く推奨**されます。ただし、標準概念は **必須** です。この標準概念の使用が必須なのは、すべての CDM インスタンスが同じ言語を話すことを可能にするためです。例えば、症状「肺結核」（TB, Figure \@ref(fig:pulmTubICD9))は、結核の ICD9CMコードが011であることを示しています。 + +```{r pulmTubICD9, fig.cap="肺結核のICD9CMコード",echo=FALSE, out.width="75%", fig.align="center"} knitr::include_graphics("images/CommonDataModel/pulmTubICD9.png") ``` -문맥이 없으면, 코드 011은 UB04 언어의 “Hospital Inpatient (Including Medicare Part A)”로 해석되거나, DRG 용어의 “Nervous System Neoplasms without Complications, Comorbidities”로 해석될 수 있다. 이것이 원본와 표준 모두의 concept ID가 중요한 이유이다. 011인 ICD9CM 코드를 나타내는 CONCEPT_ID 값은 [44828631](http://athena.ohdsi.org/search-terms/terms/44828631)이다. 이는 ICD9CM을 UBO4 및 DRG와 구별한다. ICD9CM의 TB 원본 concept은 그림 \@ref(fig:pulmTubMap)과 같이“OMOP (Non-standard to Standard Map)”관계를 통해 SNOMED 어휘에서 표준 concept [253954](http://athena.ohdsi.org/search-terms/terms/253954)로 매핑된다. 표준 SNOMED 개념을 참조하는 모든 연구가 지원되는 모든 원본 코드를 포함할 수 있도록 Read, ICD10, CIEL 및 MeSH 코드에도 동일한 매핑 관계가 존재한다. +文脈がなければ、コード011はUB04の用語集から "Hospital Inpatient (Including Medicare Part A) "と解釈されたり、DRGの用語集から "Nervous System Neoplasms without Complications, Comorbidities "と解釈されたりする可能性があります。ここで、ソース概念と標準概念の両方の概念IDが重要なものとなります。011 ICD9CMコードを表すCONCEPT_ID値は[44828631](http://athena.ohdsi.org/search-terms/terms/44828631)です。これは、ICD9CMをUBO4やDRGと区別するものです。ICD9CM TB Source Conceptは、図@ref(fig:pulmTubMap)に示すように、"Non-standard to Standard map (OMOP) "という関係を通じてSNOMED用語集の標準概念[253954](http://athena.ohdsi.org/search-terms/terms/253954)にマッピングされています。このようなマッピング関係は、Read、ICD10、CIEL、MeSHコードなどにも存在し、SNOMEDの標準概念を参照する研究では、サポートされているすべてのソースコードが含まれていることが確認されています。 -```{r pulmTubMap, fig.cap="Pulmonary Tuberculosis의 SNOMED 코드",echo=FALSE, out.width="100%", fig.align="center"} +```{r pulmTubMap, fig.cap="肺結核のSNOMED コード",echo=FALSE, out.width="100%"} knitr::include_graphics("images/CommonDataModel/pulmTubMap.png") ``` -표준 concept과 원본 concept의 관계를 보여주는 예가 표 \@ref(tab:conditionOccurrence)에 나와있다. +標準概念とソース概念の関係の例を表 \@ref(tab:conditionOccurrence)に示します。 -## 표준화된 CDM 테이블 +## CDM Standardized Tables \index{Common Data Model!standardized tables} -CDM에는 16개의 임상 사건 테이블, 10개의 어휘 테이블, 2개의 메타데이터 테이블, 4개의 보건 시스템 데이터 테이블, 2개의 보건 경제학 데이터 테이블, 3개의 표준화된 파생 요소 및 2개의 결과 스키마 테이블이 포함되어 있다. 이 테이블들은 CDM Wiki에 전체 명시되어 있다.[^cdmWikiUrl1] +CDMには、16個の臨床イベントテーブル、10個の用語集テーブル、2個のメタデータテーブル、4個の医療システムデータテーブル、2個の医療経済データテーブル、3個の標準化された派生要素、2個の結果スキーマテーブルが含まれています。これらのテーブルは CDM Wiki[^cdmWikiUrl1]で全て規定されています。 [^cdmWikiUrl1]: https://github.com/OHDSI/CommonDataModel/wiki -이러한 테이블들이 실제로 어떻게 사용되는지를 설명하기 위해, 한 사람의 데이터를 이 장의 나머지 부분에서 걸쳐 공통으로 사용할 것이다. +これらの表が実際にどのように使用されているかを説明するために、この章の残りの部分では、ある人物のデータを共通のスレッドとして使用します。 -### 실행 예제: 자궁내막증 +### Running Example: Endometriosis -자궁내막증은 보통 여성의 자궁 내 표피에 있는 자궁내막세포가 신체 다른 곳에서 생겨나는 고통스러운 질환이다. 심한 경우는 불임, 장, 방광 문제를 일으킬 수 있다. 해당 섹션에서는 한 환자의 이 질병에 대한 경험과 이 질병이 공통 데이터 모델로 어떻게 표현되는지를 상세하게 설명하고자 한다. +子宮内膜症は、通常は女性の子宮内膜にある細胞が体の他の場所に発生する痛みを伴う疾患です。重症化すると、不妊症、腸や膀胱の問題につながることがあります。以下のセクションでは、ある患者のこの疾患の経験と、それが共通データモデルでどのように表現されるかを詳述します。 ```{r Lauren1, echo=FALSE, out.width="50%", fig.align="center"} knitr::include_graphics("images/CommonDataModel/Lauren.jpg") ``` -> 나는 이 고통스러운 여정의 모든 과정마다 내가 얼마만큼의 고통을 받고 있는지를 모두에게 납득시켜야 했다. +> この痛みを伴う旅の一歩一歩において、私がどれほどの痛みを抱えているのかを皆に納得させなければなりませんでした。 + +ローレンさんは何年も前から子宮内膜症の症状を経験していましたが、診断を受ける前に卵巣の嚢胞が破裂してしまいました。ローレンさんについての詳細は、[https://www.endometriosis-uk.org/laurens-story](https://www.endometriosis-uk.org/laurens-story)で読むことができます。 + -Lauren은 수년 동안 자궁 내막증 증상을 겪어 왔다. 그러나 진단을 받기 전에 난소에서 낭종이 파열되었다. Lauren에 대한 자세한 내용은 [https://www.endometriosis-uk.org/laurens-story](https://www.endometriosis-uk.org/laurens-story)에서 확인할 수 있다. +### PERSON Table{#person} -### PERSON 테이블{#person} +#### What Do We Know About Lauren? {-} -#### Lauren에 대해서 우리가 알고 있는 것은? {-} +* 36歳の女性です。 +* 誕生日は1982年3月12日です。 +* 彼女は白人です。 +* 彼女はイギリス人です -* 그녀는 36세 여성이다 -* 그녀의 생년월일은 1982년 3월 12일이다 -* 그녀는 백인이다 -* 그녀는 영국인이다 +この情報を念頭におくと、彼女のPERSONのテーブルはこんな感じになるかもしれません。: +Table: (\#tab:person) The PERSON table. -이를 염두에 두면 PERSON 테이블을 다음과 같이 나타낼 수 있다: +|Column name|Value|Explanation +|:---------------------|:-----------|:-------------------------------------- +|PERSON_ID|1|PERSON_IDは、ソースから直接、またはビルドプロセスの一部として生成された整数値でなければなりません。| +|GENDER_CONCEPT_ID|8532|女性の性別を示す概念IDは[8532](http://athena.ohdsi.org/search-terms/terms/8532)です。| +|YEAR_OF_BIRTH|1982| | +|MONTH_OF_BIRTH|3| | +|DAY_OF_BIRTH|12| | +|BIRTH_DATETIME|1982-03-12 00:00:00|時間がわからない場合は深夜を使用します。| +|DEATH_DATETIME|　|　| +|RACE_CONCEPT_ID|8527|白人種族を指す概念IDは [8527](http://athena.ohdsi.org/search-terms/terms/8527)です。英語民族は[4093769](http://athena.ohdsi.org/search-terms/terms/4093769)です。 どちらが正しいかということになれば、後者が前者に収斂されます。ethnicityはここではRacesの一部として格納されており、ETHNICITY_CONCEPTには格納されていないことに注意してください。| -Table: (\#tab:person) PERSON 테이블. +|ETHNICITY_CONCEPT_ ID|38003564|これはヒスパニック系を区別するための米国的な表記です。民族（この場合は英語）はRACE_CONCEPT_IDに格納されています。米国外ではこれは使われていません。[38003564](http://athena.ohdsi.org/search-terms/terms/38003564) は "非ヒスパニック"を参照しています。| +|LOCATION_ID||彼女の住所は不明です。| +|PROVIDER_ID||彼女の主治医は不明です。| +|CARE_SITE||彼女のかかりつけ医療機関は不明です。| +|PERSON_SOURCE_ VALUE|1|典型的にはこれがソースデータにおける彼女の識別子になりますが、PERSON_IDと同じであることが多いです。| +|GENDER_SOURCE_ VALUE|F|ソースに表示されている性別の値がここに格納されています。| +|GENDER_SOURCE_ CONCEPT_ID|0|ソース内の性別の値がOHDSIがサポートするコーディングスキームを使用してコーディングされている場合、その概念はここに格納されます。例えば、彼女の性別が "sex-F "であり、それがPCORNet語彙概念[44814665](http://athena.ohdsi.org/search-terms/terms/44814665)にあると記述されていた場合は、このフィールドに入ります。| +|RACE_SOURCE_ VALUE|white|ソースに表示されている人種の値がここに格納されています。| +|RACE_SOURCE_ CONCEPT_ID|0|GENDER_CONCEPT_IDと同じ原理が適用されます。| +|ETHNICITY_SOURCE_ VALUE|english|ソースに表示されている，民族の値がここに格納されます。| +|ETHNICITY_SOURCE_ CONCEPT_ID|0|SGENDER_SOURCE_CONCEPT_IDと同じ原理が適用されます。| -Column name|Value|Explanation -:---------------------|:-----------|:-------------------------------------- -|PERSON_ID|1|PERSON_ID는 원본에서 직접적으로 생성되거나 빌드 과정의 일부분으로 생성된 정수여야 한다.| -|GENDER_CONCEPT_ID|8532|여성을 의미하는 concept ID는 [8532](http://athena.ohdsi.org/search-terms/terms/8532)이다.| -|YEAR_OF_BIRTH|1982|| -|MONTH_OF_BIRTH|3|| -|DAY_OF_BIRTH|12|| -|BIRTH_DATETIME|1982-03-12 00:00:00|시간을 정확히 알 수 없는 경우 자정으로 한다.| -|DEATH_DATETIME||| -|RACE_CONCEPT_ID|8527|백인을 의미하는 concept ID는 [8527](http://athena.ohdsi.org/search-terms/terms/8527)이다. 영국인이라는 민족성은 [4093769](http://athena.ohdsi.org/search-terms/terms/4093769)이다. 둘 다 해당할 경우 전자를 활용한다. 민족성은 ETHNICITY_CONCEPT_ID가 아닌 인종의 일부로써 여기에 저장된다.| -|ETHNICITY_CONCEPT_ ID|38003564|이는 히스패닉을 다른 사람들과 구분하기 위해 사용되는 전형적인 미국식 표기법이다. 이 경우 영국인인 민족성은 RACE_CONCEPT_ID에 저장된다. 미국 이외의 지역에서는 사용되지 않는다. [38003564](http://athena.ohdsi.org/search-terms/terms/38003564)는 “히스패닉이 아님”을 나타낸다.| -|LOCATION_ID||주소는 알려져 있지 않다.| -|PROVIDER_ID||일차 진료 제공자는 알려져 있지 않다.| -|CARE_SITE||일차 진료 장소는 알려져 있지 않다.| -|PERSON_SOURCE_ VALUE|1|대부분 PERSON_ID 와 동일 하지만 일반적으로 이는 원본 데이터에서의 그녀의 식별자가 될 것이다.| -|GENDER_SOURCE_ VALUE|F|원본에 나타난 성별에 대한 값이 여기에 저장되어 있다.| -|GENDER_SOURCE_ CONCEPT_ID|0|원본의 성별에 대한 값이 OHDSI에서 지원하는 코딩 체계를 사용한 경우 해당 concept이 여기에 해당한다. 예를 들어, 그녀의 성별이 원본에서 “sex-F”이고 PCORNet 어휘 concept에 있다고 언급되어 있다면 [44814665](http://athena.ohdsi.org/search-terms/terms/44814665)이 이 필드에 입력될 것이다.| -|RACE_SOURCE_ VALUE|white|인종 값이 원본에 있는대로 여기에 저장된다.| -|RACE_SOURCE_ CONCEPT_ID|0|GENDER_CONCEPT_ID와 같은 원리 적용.| -|ETHNICITY_SOURCE_ VALUE|english|민족성 값이 원본에 나와 있는대로 여기에 저장된다.| -|ETHNICITY_SOURCE_ CONCEPT_ID|0|GENDER_SOURCE_CONCEPT_ID와 같은 원리 적용.| +### OBSERVATION_PERIOD Table{#observationPeriod} -### OBSERVATION_PERIOD 테이블{#observationPeriod} +OBSERVATION_PERIODテーブルは、少なくとも患者の人口統計学、状態、処置、および医薬品において、妥当な感度と特異性を期待してソースシステムに記録される時間を定義するように設計されています。保険データの場合、これは通常、患者の登録期間となります。電子カルテ（EHR）では、ほとんどの医療システムが、どの医療機関や医療従事者を訪問しているかを判断しないため、より厄介です。次善の策として、システム内の最初の記録は観察期間の開始日とみなされ、最新の記録は終了日とみなされることが多いです。 -OBSERVATION_PERIOD 테이블은 최소한 환자의 인구통계, 질환, 시술 및 약물이 원본 시스템에 기록되는 시간을 민감성과 특수성을 고려하여 합리적인 예상을 통해 정의하도록 설계되었다. 보험 데이터의 경우 일반적으로 환자의 등록 시기이다. 대부분의 의료 시스템이 어떤 의료 기관이나 제공업체를 방문할지 결정해두지 않기 때문에 전자 의무 기록(EHR)에서는 더욱 까다롭다. 차선책으로서 시스템의 첫 번째 기록은 관측 기간의 시작일로 간주되고 마지막 기록은 종료일로 간주된다. +#### How Is Lauren's Observation Period Defined? {-} -#### Lauren의 Observation Period는 어떻게 정의될까? {-} -표 \@ref(tab:encounters)에 나타난 Lauren의 정보가 전자 의무 기록(EHR) 시스템에 기록되었다고 가정하자. 그녀의 관찰 기간에서 얻어진 방문기록은 다음과 같다: +ローレンさんの情報が表のようにEHRシステムに記録されているとします。観測期間から得られた彼女の来意履歴は下記のとおりでした。 -Table: (\#tab:encounters) Lauren의 의료 기관 방문. +Table: (\#tab:encounters) ローレンさんの来院履歴 -Encounter ID|Start date|Stop date|Type| -:--------|:-----|:------|:----------- +|Encounter ID|Start date|Stop date|Type| +|:--------|:-----|:------|:----------- |70|2010-01-06|2010-01-06|outpatient| |80|2011-01-06|2011-01-06|outpatient| |90|2012-01-06|2012-01-06|outpatient| @@ -203,223 +210,218 @@ Encounter ID|Start date|Stop date|Type| |101|2013-01-14|2013-01-14|ambulatory| |102|2013-01-17|2013-01-24|inpatient| -방문기록을 기반으로 했을 때 그녀의 OBSERVATION_PERIOD 테이블은 다음과 같을 것이다: +来院履歴に基づいて、彼女のOBSERVATION_PERIODテーブルは次のようになるかもしれません。 -Table: (\#tab:observationPeriod) OBSERVATION_PERIOD 테이블. +Table: (\#tab:observationPeriod) OBSERVATION_PERIODの表 -Column name|Value|Explanation -:----------------------|:----------|:-------------------------------------- -|OBSERVATION_ PERIOD_ID|1|이는 일반적으로 테이블의 각 기록에 대한 고유 식별자를 생성하는 자동으로 생성되는 값이다.| -|PERSON_ID|1|PERSON 테이블에서 Laura의 기록에 대한 외래 키이며 PERSON을 OBSERVATION_PERIOD 테이블에 연결한다.| -|OBSERVATION_PERIOD_ START_DATE|2010-01-06|이는 기록상 그녀의 가장 처음 방문했을 때 시작 날짜이다.| -|OBSERVATION_PERIOD_ END_DATE|2013-01-24|이는 기록상 그녀의 가장 마지막 방문했을 때 마지막 날짜이다.| -|PERIOD_TYPE_ CONCEPT_ID|44814725|concept의 클래스가 "Obs Period Type"인 어휘에서 가장 좋은 선택은 [44814724](http://athena.ohdsi.org/search-terms/terms/44814724)이며, 이는 "의료 관련 방문 기간(Period covering healthcare encounters)"을 나타낸다.| +|Column name|Value|Explanation +|:----------------------|:----------|:-------------------------------------- +|OBSERVATION_ PERIOD_ID|1|通常、テーブル内の各レコードに対して一意の識別子を作成する自動生成された値です。| +|PERSON_ID|1|これはPERSONテーブルのローラのレコードの外部キーであり、PERSONをOBSERVATION_PERIODテーブルにリンクします。| +|OBSERVATION_PERIOD_ START_DATE|2010-01-06|これは彼女のレコード上で最も早く遭遇した日の開始日です。| +|OBSERVATION_PERIOD_ END_DATE|2013-01-24|Tこれは記録上の彼女の最新の来院履歴の終了日です。| +|PERIOD_TYPE_ CONCEPT_ID|44814725|「Obs Period Type」という概念クラスを持つ語彙の中で最良の選択肢は[44814724](http://athena.ohdsi.org/search-terms/terms/44814724)で、 「医療来院履歴をカバーする期間("Period covering healthcare encounters")」の略です。 ### VISIT_OCCURRENCE{#visitOccurrence} -VISIT_OCCURRENCE에서는 환자의 의료 시스템에 방문한 정보에 대해 저장되어 있다. OHDSI 언어내에서 이를 Visit이라고 하며 주요한 사건로 간주한다. 의료 서비스가 제공될 수 있는 다양한 환경을 나타내는 광범위한 계층 구조를 가진 12 가지 주요 방문 카테고리가 있다. 가장 일반적인 Visit 기록는 입원(inpatient), 외래(outpatient), 응급실(emergency department) 및 비-의료 기관방문(non-medical institution Visits)이다. +VISIT_OCCURRENCE テーブルには、患者の来院履歴に関する情報が格納されています。OHDSIの用語では、これらは来院(Visit)と呼ばれ、目立たないイベントと考えられています。来院には12のトップカテゴリーがあり、医療が提供される可能性のある様々な状況が階層化されています。記録されている最も一般的な訪問は、入院、外来、救急部、非医療機関への訪問です。 -#### Lauren의 방문을 Visit으로 어떻게 표현할 수 있을까? {-} +#### How Are Lauren's Encounters Represented As Visits? {-} -예를 들어 VISIT_OCCURRENCE 테이블의 표 \@ref(tab:encounters)의 입원 환자 방문을 나타내어 보자. +例として、VISIT_OCCURRENCE テーブルの表 ＠ref(tab:encounter) で入院患者の遭遇を表現してみましょう。 -Table: (\#tab:visitOccurrence) VISIT_OCCURRENCE 테이블. +Table: (\#tab:visitOccurrence) VISIT_OCCURRENCEテーブルの内容 -Column name|Value|Explanation -:---------------------|:-----------|:-------------------------------------- -|VISIT_OCCURRENCE_ ID|514|이는 일반적으로 테이블의 각 기록에 대한 고유 식별자를 생성하는 자동으로 생성되는 값이다.| -|PERSON_ID|1|PERSON 테이블에서 Laura의 기록에 대한 외래 키이며 PERSON을 VISIT_OCCURRENCE에 연결한다.| -|VISIT_CONCEPT_ID|9201|입원 환자 방문을 나타내는 외래 키는 [9201](http://athena.ohdsi.org/search-terms/terms/9201)이다.| -|VISIT_START_DATE|2013-01-17|Visit의 시작 날짜.| -|VISIT_START_ DATETIME|2013-01-17 00:00:00|Visit의 날짜와 시간. 시간을 알 수 없기 때문에 자정으로 나타낸다.| -|VISIT_END_DATE|2013-01-24|Visit의 종료 날짜. 일일 방문이라면 이 값이 시작 날짜와 동일해야 한다.| -|VISIT_END_DATETIME|2013-01-24 00:00:00|Visit의 종료 날짜와 시간. 시간을 알 수 없기 때문에 자정으로 나타낸다.| -|VISIT_TYPE_ CONCEPT_ID|32035|이는 방문 기록의 보험 청구, 병원 청구, 전자 의무 기록(EHR)과 같은 제공처에 대한 정보를 제공한다. 해당 예에서는 방문 기록이 전자 의무 기록(EHR)과 유사하므로 concept ID [32035](http://athena.ohdsi.org/search-terms/terms/32035) ("Visit derived from EHR encounter record")이 사용되었다.| -|PROVIDER_ID*|NULL|방문 기록에 해당 제공자와 관련된 ID가 있을 경우 이 필드에 기록한다. 이는 PROVIDER 테이블의 PROVIDER_ID 필드의 내용이어야 한다.| -|CARE_SITE_ID|NULL|방문 기록에 치료 제공 장소와 관련된 ID가 있을 경우 이 필드에 기록한다. 이는 CARE_SITE 테이블의 CARE_SITE_ID 필드의 내용이어야 한다.| -|VISIT_SOURCE_ VALUE|inpatient|출처에 나와 있는 방문 값 그대로 여기에 입력한다. Lauren의 데이터에는 존재하지 않는다.| -|VISIT_SOURCE_ CONCEPT_ID|0|출처의 방문 값이 OHDSI에서 통용되는 용어를 사용하여 코딩 되어 있는 경우 원본 코드를 나타내는 CONCEPT_ID 값을 여기에 넣는다. Lauren의 데이터에는 존재하지 않는다.| -|ADMITTED_FROM_ CONCEPT_ID|0|환자가 어디에서부터 입원해 왔는지 알 수 있는 경우 이를 나타내는 concept을 포함하고 있다. 이 concept은 “Visit”의 도메인을 가지고 있어야 한다. 예를 들어 만약 환자가 집에서 병원으로 입원한 경우 [8536](http://athena.ohdsi.org/search-terms/terms/8536) ("Home")값일 것이다.| -|ADMITTED_FROM_ SOURCE_VALUE|NULL|환자가 어디에서부터 입원해 왔는지를 나타내는 원본 값이다. 위의 예를 활용하면 여기에는 “Home”이 들어가야 한다.| -|DISCHARGE_TO_ CONCEPT_ID|0|환자가 어디로 퇴원 되었는지 알 수 있는 경우 이를 나타내는 concept을 나타낸다. 이 concept은 “Visit” 도메인을 가지고 있어야 한다. 예를 들면, 만약 환자가 보조 생활 시설로 보내졌을 경우 concept ID는 [8615](http://athena.ohdsi.org/search-terms/terms/8615) ("Assisted Living Facility")일 것이다.| -|DISCHARGE_TO_ SOURCE_VALUE|0|환자가 퇴원 한 곳을 나타내는 원본 값이다. 위의 예를 활용하면“보조 생활 시설”이 된다.| -|PRECEDING_VISIT_ OCCURRENCE_ID|NULL|현재 Visit의 바로 이전의 방문을 나타낸다. ADMITTED_FROM_CONCEPT_ID와 달리 Visit Concept이 아닌 실제 Visit Occurrence 기록에 연결된다. 또한 Visit Occurrence에 따른 기록는 없으며 Visit Occurrence는 이 필드를 통해서만 연결되어 있다.| +|Column name|Value|Explanation +|:---------------------|:-----------|:-------------------------------------- +|VISIT_OCCURRENCE_ ID|514|通常、各レコードの一意の識別子を作成する自動生成された値です。| +|PERSON_ID|1|PERSONテーブルのローレンさんのレコードの外部キーであり、PERSONとVISIT_OCCURRENCEをリンクしています。| +|VISIT_CONCEPT_ID|9201|院患者の訪問を参照する外部キーは[9201](http://athena.ohdsi.org/search-terms/terms/9201)です。| +|VISIT_START_DATE|2013-01-17|来院開始日| +|VISIT_START_ DATETIME|2013-01-17 00:00:00|来院の日時です。時間が不明なので深夜を使用しています。| +|VISIT_END_DATE|2013-01-24|来院の終了日。これが一日の訪問であれば、終了日は開始日と一致しなければなりません。| +|VISIT_END_DATETIME|2013-01-24 00:00:00|来院終了の日時です。時間が不明なので深夜を使用しています。| +|VISIT_TYPE_ CONCEPT_ID|32034|来院記録の出所についての情報を提供します。保険請求書、病院請求書、電子カルテなどに由来します。この例では概念ID[32035](http://athena.ohdsi.org/search-terms/terms/32035) ("Visit derived from EHR encounter record(EHRの来院記録から導き出された来院)") が使用されています。| +|PROVIDER_ID*|NULL|来院レコードに医療機関が関連付けられている場合、その医療機関のIDがこのフィールドに入力されます。これはPROVIDERテーブルのPROVIDER_IDフィールドの内容でなければなりません。| +|CARE_SITE_ID|NULL|来院レコードにCare Siteが関連付けられている場合、そのCare SiteのIDがこのフィールドに入ります。これはCARE_SITEテーブルのCARE_SITE_IDでなければなりません。| +|VISIT_SOURCE_ VALUE|inpatient|ソースデータにある来院に関する値はここに入ります。ローレンさんのデータにはありませんでした。| +|VISIT_SOURCE_ CONCEPT_ID|0|ソースの来院に関する値がOHDSIで認識される用語を使用してコード化されている場合、ソースでのコードを表すCONCEPT_ID値はここに入ります。ローレンさんのデータにはそれがありません。| +|ADMITTED_FROM_ CONCEPT_ID|0|確認できる場合、これには患者がどこから入院したかを表す概念が含まれています。この概念は、ドメイン "Visit "を持つべきです。例えば、患者が自宅から入院した場合、[8536](http://athena.ohdsi.org/search-terms/terms/8536) ("Home")が含まれます。| +|ADMITTED_FROM_ SOURCE_CONCEPT_ID|NULL|患者がどこから入院したかを表すソースからの値です。この例では「自宅」となります。| +|DISCHARGE_TO_ CONCEPT_ID|0|確認できる場合、これは患者がどこに退院したかを表す概念を指します。この概念はドメイン "Visit "に所属するものであるべきです。例えば、患者が福祉施設に退院した場合、概念IDは[8615](http://athena.ohdsi.org/search-terms/terms/8615) ("Assisted Living Facility")となります。| +|DISCHARGE_TO_ SOURCE_VALUE|0|患者がどこに退院したかを表すソースデータにおける退院に関する値です。上記の例では、"Assisted living facility "となります。| +|PRECEDING_VISIT_ OCCURRENCE_ID|NULL|直前の来院を表します。ADMITTED_FROM_CONCEPT_IDとは対照的に、これはVisit Conceptではなく実際のVisit Occurrenceレコードにリンクしています。また、次の来院記録はないことに注意してください。| -* 환자는 입원하는 경우와 마찬가지로 한번 방문하는 동안 여러 의료 제공자와 상호 작용할 수 있다. 이러한 상호작용은 VISIT_DETAIL 테이블에 기록될 수 있다. 이 장에서는 자세히 다루지 않지만 [CDM wiki](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL)에서 VISIT_DETAIL 테이블에 대한 자세한 내용을 확인할 수 있다. +* 入院患者の場合によく見られるように、患者は1回の来院で複数の医療提供者を受診することがあります。これらのやり取りはVISIT_DETAILテーブルに記録できます。この章では詳しくは説明しませんが、VISIT_DETAILテーブルについては[CDM wiki](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL)をご覧下さい。 ### CONDITION_OCCURRENCE{#conditionOccurrence} -CONDITION_OCCURRENCE 테이블의 기록은 제공자가 관찰하거나 환자가 보고한 상태의 진단, 징후 또는 증상이다. +CONDITION_OCCURRENCEテーブルのレコードは、医療従事者が観察した、または患者から報告された状態の診断、徴候、または症状です。 -#### Lauren의 condition은 무엇일까? {-} +#### What Are Lauren's Conditions? {-} -그녀의 예로 돌아가자면 그녀는 다음과 같이 말한다: +彼女の主張を再びみてみましょう: -> 3년 정도 전쯤 그 동안 매우 통증이 심했던 월경이 점점 더 고통스러워지고 있다는 것을 알아챘다. 나는 내 대장 바로 옆에서 날카롭게 쑤시는 통증을 느끼기 시작했고 꼬리뼈와 아랫골반 부위가 따갑고 부풀어 오르는 것을 느꼈다. 내 월경이 너무 고통스러워져서 일을 한달에 하루 이틀 쉬었다. 진통제가 가끔 고통을 줄여 주긴 했지만 보통은 그렇지 않았다. +> 約3年前、私はまた、痛みを伴っていた私の生理が、ますます痛みを伴うようになっていたことに気付きました。私は、私の大腸のすぐそばに鋭い刺すような痛みを意識し始め、私の尾骨と骨盤の下の領域の周りに柔らかく、膨らみを感じるようになってきました。生理痛がひどくなり、月に1～2日仕事を休むこともありました。鎮痛剤で痛みを和らげることもありましたが、通常はあまり効果がありませんでした。 -월경통이라고 하는 고통스러운 월경 경련의 SNOMED 코드는 266599000이다. 표 \@ref(tab:conditionOccurrence)은 CONDITION_OCCURRENCE 테이블에 어떻게 표시되는 지를 보여준다: +月経困難症として知られる、痛みを伴う月経痛のSNOMEDコードは 266599000です。表@ref(tab:conditionOccurrence)は、CONDITION_OCCURRENCEテーブルでどのように表現されるかを示してます。 -Table: (\#tab:conditionOccurrence) CONDITION_OCCURRENCE 테이블. +Table: (\#tab:conditionOccurrence) CONDITION_OCCURRENCEテーブルの内容 -Column name|Value|Explanation -:---------------------|:-----------|:-------------------------------------- -|CONDITION_ OCCURRENCE_ID|964|이는 일반적으로 테이블의 각 기록에 대한 고유 식별자를 생성하는 자동으로 생성되는 값이다.| -|PERSON_ID|1|이는 PERSON 테이블에서 Laura의 기록에 대한 외래 키이며 PERSON을 CONDITION_OCCURRENCE에 연결한다.| -|CONDITION_ CONCEPT_ID|194696|SNOMED 코드 266599000을 나타내는 외래 키: [194696](http://athena.ohdsi.org/search-terms/terms/194696).| -|CONDITION_START_ DATE|2010-01-06|Condition의 인스턴스가 기록된 날짜이다.| -|CONDITION_START_ DATETIME|2010-01-06 00:00:00|Condition의 인스턴스가 기록된 날짜 및 시간이다. 시간을 알 수 없으므로 자정으로 입력한다.| -|CONDITION_END_ DATE|NULL|이는 인스턴스가 종료된 것으로 여겨지는 날짜지만 거의 기록되지 않는다.| -|CONDITION_END_ DATETIME|NULL|Condition의 인스턴스가 종료된 것으로 여겨지는 날짜 및 시간이 알려져 있을 경우 입력한다.| -|CONDITION_TYPE_ CONCEPT_ID|32020|이 열은 기록의 출처, 즉 보험 청구, 병원 청구 기록, 전자 의무 기록(EHR)등에서 얻어 졌다는 정보를 제공하기 위한 것이다. 해당 예에서는 방문 기록이 전자 의무 기록(EHR)과 유사하기 때문에 concept [32020](http://athena.ohdsi.org/search-terms/terms/32020) ("EHR encounter diagnosis")을 사용한다. 이 필드에 있는 concept은 “Condition Type”용어에 있는 것이여야 한다.| -|CONDITION_STATUS_ CONCEPT_ID|0|상황에 대해 알려진 것이 있을 경우 입력한다. 예를 들어, concept ID에 [4203942](http://athena.ohdsi.org/search-terms/terms/4203942)가 사용되었을 경우 Condition이 인정된 진단명일 수 있다.| -|STOP_REASON|NULL|Condition이 더 이상 존재하지 않는 이유가 알려져 있으면 원본 데이터에 있는대로 입력한다.| -|PROVIDER_ID|NULL|만약 condition 기록에 진단의 제공자가 수록되어 있으면 해당 제공자의 ID를 이 필드에 입력한다. 이는 방문 시 제공자를 나타내는 PROVIDER 테이블의 PROVIDER_ID의 내용이어야 한다.| -|VISIT_OCCURRENCE_ ID|509|Condition이 진단되었을 당시 Visit값(VISIT_OCCURRENCE 테이블의 VISIT_OCCURRENCE_ID에 대한 외래 키).| -|CONDITION_SOURCE_ VALUE|266599000|Conditions을 나타내는 원래의 원본 값. Lauren의 월경 곤란의 사례에서는 해당 Condition에 대한 SNOMED 코드가 여기에 저장되고 코드를 나타내는 Concept은 CONDITION_SOURCE_CONCEPT_ID로 이동했으며 이로부터 매핑된 표준 Concept은 CONDITION_CONCEPT_ID 필드에 저장된다.| -|CONDITION_SOURCE_ CONCEPT_ID|194696|원본의 질환 값이 OHDSI에서 활용하는 용어로 코드화되어 있을 경우 그 값을 나타내는 concept ID를 여기에 입력한다. 월경 곤란의 예에서는 그 원본 값이 SNOMED 코드 이므로 코드를 나타내는 Concept은 194696이다. 이 경우에서는 CONDITION_CONCEPT_ID 영역과 같은 값이다.| -|CONDITION_STATUS_ SOURCE_VALUE|0|원본의 질환의 상태 값이 OHDSI에서 지원하는 방식으로 코드화 되어 있을 경우 해당 concept을 여기에 입력한다.| +|Column name|Value|Explanation +|:---------------------|:-----------|:-------------------------------------- +|CONDITION_ OCCURRENCE_ID|964|PERSONテーブルのローレンさんのレコードの外部キーであり、PERSONとCONDITION_OCCURRENCEをリンクしています。| +|PERSON_ID|1|PERSONテーブルのローレンさんのレコードの外部キーであり、PERSONとCONDITION_OCCURRENCEをリンクしています。| +|CONDITION_ CONCEPT_ID|194696|SNOMEDコード266599000: [194696](http://athena.ohdsi.org/search-terms/terms/194696)を参照する外部キーです。| +|CONDITION_START_ DATE|2010-01-06|症状のインスタンスが記録された日付。| +|CONDITION_START_ DATETIME|2010-01-06 00:00:00|症状のインスタンスが記録された日時です。時間は不明なので深夜を使用しています。| +|CONDITION_END_ DATE|NULL|状態のインスタンスが終了したと判断された日付ですが、これが記録されることはほとんどありません。| +|CONDITION_END_ DATETIME|NULL|確認できる場合、症状のインスタンスが終了したとみなされた日時です。| +|CONDITION_TYPE_ CONCEPT_ID|32020|このカラムは、レコードの出所に関する情報を提供することを目的としています。この例では、来院が電子カルテの内容に類似しているため、概念[32020](http://athena.ohdsi.org/search-terms/terms/32020) ("EHR encounter diagnosis(電子カルテにおける来院時診断)")が使われ得ています。 このフィールドの概念は、"Condition Type "の用語集の中にあります。| +|CONDITION_STATUS_ CONCEPT_ID|0|確認出来る場合、これは状況や症状について記述します。例えば、ある症状は入院中の診断である可能性があり、その場合は概念ID[4203942](http://athena.ohdsi.org/search-terms/terms/4203942) が使われます。| +|STOP_REASON|NULL|確認できる場合は、ソースデータに示されているように、その症状が存在しなくなった理由を示します。| +|PROVIDER_ID|NULL|症状レコードに診断医師がリストされている場合、その医師のIDがこのフィールドに入ります。これはPROVIDERテーブルのPROVIDER_IDで、診察した医師を表しています。| +|VISIT_OCCURRENCE_ ID|509|VISIT(VISIT_OCCURRENCEテーブルのVISIT_OCCURRENCE_IDへの外部キー)で、症状が診断された訪問先。| +|CONDITION_SOURCE_ VALUE|266599000|症状を表す元のソース値です。ローレンさんの月経困難症の場合、その疾患のSNOMEDコードがここに格納されていますが、そのコードを表す概念はCONDITION_SOURCE_CONCEPT_IDに格納され、そこからマッピングされた標準概念はCONDITION_CONCEPT_IDフィールドに格納されています。| +|CONDITION_SOURCE_ CONCEPT_ID|194696|ソースからの症状に関する値がOHDSIで認識される用語を使ってコード化されている場合、その値を表す概念IDはここに格納されます。この例では、ソースでの値はSNOMEDコードなので、そのコードを表す概念IDは194696となります。この場合、CONDITION_CONCEPT_IDフィールドと同じ値になります。 +|CONDITION_STATUS_ SOURCE_VALUE|0|ソースからのCondition Status値がOHDSIがサポートするコーディングスキームを使用してコーディングされている場合、その概念はここに格納されます。| ### DRUG_EXPOSURE{#drugExposure} -DRUG_EXPOSURE 테이블은 환자에게 약물을 투여하고자 한 의도나 실제 투여에 대한 기록을 수집한다. 의약품에는 처방전이 필요한 전문의약품과 처방전 없이 구입할 수 있는 의약품, 백신 및 고분자 생물학적 제제를 포함한다. 약물 노출은 처방, 처방전, 약품 불출, 시술시 사용된 약품, 기타 환자가 보고한 정보와 같은 임상적인 사건에서 유추된다. - -#### Lauren의 약물 노출은 어떻게 나타낼 수 있을까? {-} - -월경통을 완화하기 위해 Lauren은 2010 년 1월 6일 방문하여 아세트아미노펜 375mg (일명 Paracetamol, 예를 들어, 미국에서 NDC 코드 69842087651로 판매되었다) 경구 제제 60알을 30일치 처방으로 받았다. 이는 DRUG_EXPOSURE 테이블에서 다음과 같이 나타난다: - -Table: (\#tab:drugExposure) DRUG_EXPOSURE 테이블. - -Column name|Value|Explanation -:---------------------|:-----------|:-------------------------------------- -|DRUG_EXPOSURE_ID|1001|이는 일반적으로 테이블의 각 기록에 대한 고유 식별자를 생성하는 자동으로 생성되는 값이다.| -|PERSON_ID|1|PERSON 테이블에서 Laura의 기록에 대한 외래 키이며 PERSON을 DRUG_EXPOSURE에 연결한다.| -|DRUG_CONCEPT_ID|1127433|의약품에 대한 개념. 아세트아미노펜에 대한 NDC 코드는 Concept [1127433](http://athena.ohdsi.org/search-terms/terms/1127433)으로 표시되는 RxNorm 코드 313782에 매핑된다.| -|DRUG_EXPOSURE_ START_DATE|2010-01-06|약물에 노출되기 시작한 날짜.| -|DRUG_EXPOSURE_ START_DATETIME|2010-01-06 00:00:00|약물에 노출되기 시작한 날짜 및 시각. 알 수 없을 경우 자정을 입력| -|DRUG_EXPOSURE_ END_DATE|2010-02-05|약물 노출이 종료되는 날짜. 서로 다른 출처에서 알려져 있는 날짜나 추정된 날짜 일 수 있으며 환자가 약물에 노출 지속된 날짜의 마지막 날을 의미한다. 해당 사례에서는 Lauren이 30일 동안 제공받았음을 알기에 이 날짜가 추론될 수 있다.| -|DRUG_EXPOSURE_ END_DATETIME|2010-02-05 00:00:00|약물 노출 종료 날짜 및 시간. DRUG_EXPOSURE_END_DATE와 비슷한 규칙이 적용된다. 알 수 없을 경우 자정을 입력.| -|VERBATIM_END_DATE|NULL|원본에서 실제 종료 날짜를 명시한 경우, 환자가 전체 날짜에 약물에 노출되었다고 가정하여 유추되어 결정된다.| -|DRUG_TYPE_ CONCEPT_ID|38000177|해당 열은 보험 청구, 처방 기록 등에서 비롯된 기록의 출처에 대한 정보를 제공하기 위해 작성이 되었다. 이 예에서는 Concept [38000177](http://athena.ohdsi.org/search-terms/terms/38000177) ("Prescription written")이 사용되었다.| -|STOP_REASON|NULL|T약물 투여가 중단된 이유. 요법 완료, 변경 제거 등이 이유에 포함된다. 이 정보가 수집되는 경우는 거의 없다.| -|REFILLS|NULL|대다수의 나라에서 처방 시스템의 일부인 초기 처방 이후 자동 재조제 횟수. 초기 처방은 세지 않고 NULL로 시작한다.Lauren의 아세트아미노펜의 경우 재조제되지 않았으므로 NULL이다.| -|QUANTITY|60|최초 처방전 또는 조제 기록에 기록된 약물의 양.| -|DAYS_SUPPLY|30|처방 된 약의 투여 일수.| -|SIG|NULL|최초 처방전 또는 조제 기록에 기록된 미국 처방 시스템의 용기에 인쇄된 약 처방전의 지침 ("signetur"). 약물 지침은 CDM에서 아직 표준화되지 않았으며 표기된 그대로 입력된다.| -|ROUTE_CONCEPT_ID|4132161|이 Concept은 환자의 약물 투여 경로를 나타낸다. Lauren은 아세트아미노펜을 경구 복용하였으므로, Concept ID [4132161](http://athena.ohdsi.org/search-terms/terms/4132161)을 사용하였다.| -|LOT_NUMBER|NULL|제조업체로부터의 특정 수량 또는 의약품에 할당된 식별자. 이 정보는 거의 수집되지 않는다. | -|PROVIDER_ID|NULL|약품 기록에 처방자에 대한 정보가 있으면 해당 공급자의 ID가 해당 영역에 들어간다. 이때PROVIDER 테이블의 PROVIDER_ID를 사용한다.| -|VISIT_OCCURRENCE_ ID|509|약물 처방 시 VISIT_OCCURRENCE 테이블에 대한 외래 키.| -|VISIT_DETAIL_ID|NULL|약물 처방 시 VISIT_DETAIL 테이블에 대한 외래 키.| -|DRUG_SOURCE_ VALUE|69842087651|원본 데이터에 나와있는 의약품의 원본 코드. Lauren의 예에서 NDC 코드가 저장된다.| -|DRUG_SOURCE_ CONCEPT_ID|750264|이는 약물의 원본 값을 나타내는 Concept이다. [750264](http://athena.ohdsi.org/search-terms/terms/750264) Concept은 “Acetaminophen 325 MG Oral Tablet”의 NDC 코드를 나타낸다.| -|ROUTE_SOURCE_ VALUE|NULL|원본에 나와 있는 그대로의 등록 경로를 나타낸다.| +DRUG_EXPOSURE テーブルは、患者の体内への薬物投与の意図（指示）または実際の服薬に関する記録を取り込みます。薬物には、処方薬、市販薬、ワクチン、および高分子生物学的療法が含まれる。薬物への曝露は、オーダー、処方箋、薬局での調剤、処置、その他患者からの報告情報に関連する臨床事象から推定されます。 + + +#### How Are Lauren's Drug Exposures Represented? {-} + +月経困難症の疼痛の治療のために、ローレンさんは2010年1月6日の訪問時に、アセトアミノフェン375mg（別名パラセタモール、米国でNDCコード69842087651で販売されているもの）を60錠ずつ30日間経口投与されました。DRUG_EXPOSUREの表は次のようになります。 + +Table: (\#tab:drugExposure) DRUG_EXPOSUREテーブル + +|Column name|Value|Explanation +|:---------------------|:-----------|:-------------------------------------- +|DRUG_EXPOSURE_ID|1001|T通常、各レコードの一意の識別子を作成する自動生成された値です。| +|PERSON_ID|1|PERSONテーブルのローレンさんのレコードの外部キーで、PERSONとDRUG_EXPOSUREをリンクしています。| +|DRUG_CONCEPT_ID|1127433|医薬品の概念です。アセトアミノフェンのNDCコードは、概念[1127433](http://athena.ohdsi.org/search-terms/terms/1127433)で表されるRxNormコード313782に対応しています。| +|DRUG_EXPOSURE_ START_DATE|2010-01-06|医薬品曝露の開始日。| +|DRUG_EXPOSURE_ START_DATETIME|2010-01-06 00:00:00|医薬品曝露の開始日時。時間は不明なので深夜を使用しています。| +|DRUG_EXPOSURE_ END_DATE|2010-02-05|医薬品曝露の終了日。患者がまだ医薬品に曝露されていた最終日を示します。情報源にもよりますが、確定されている日付であったり、推測される日付であったりします。この場合、ローレンさんが30日分の薬を持っていたことがわかっているので、この日付が推測されます。| +|DRUG_EXPOSURE_ END_DATETIME|2010-02-05 00:00:00|医薬品曝露の終了日時を示します。DRUG_EXPOSURE_END_DATEについても同様のルールが適用されます。時間が不明なので深夜を使用します。| +|VERBATIM_END_DATE|NULL|この情報源が明示的な実際の終了日を記録していた場合には、それを使います。患者が処方された医薬品の全日数分を使用したと仮定して、終了日を推定しています。| +|DRUG_TYPE_ CONCEPT_ID|38000177|レコードの出所（例えば診療報酬請求、処方箋等）についての情報を提供することを目的としています。この例では概念[38000177](http://athena.ohdsi.org/search-terms/terms/38000177) ("Prescription written（記載された処方箋）") が使われています。| +|STOP_REASON|NULL|本剤の投与が中止された理由。理由としては、レジメンの完了、変更、削除などがあります。この情報を取得することはほとんどありません。| +|REFILLS|NULL|多くの国で処方システムの一部となっている初回処方後の自動再処方の回数。最初の処方箋はカウントされず、値はNULLから始まります。ローレンさんのアセトアミノフェンの場合は再処方はなされていないので値はNULLです。| +|QUANTITY|60|処方箋の原本または調剤記録に記録されている薬の量| +|DAYS_SUPPLY|30|処方された薬の供給日数| +|SIG|NULL|原本の処方箋または調剤記録に記録されている（米国の医薬品処方システムでは容器に印刷されている）医薬品処方箋の指示（"signetur"）。 Signetursは、CDMではまだ標準化されておらず、口頭で提供されている。| +|ROUTE_CONCEPT_ID|4132161|この概念は、患者が曝露された薬剤の投与経路を表すものである。ローレンさんははアセトアミノフェンを経口投与したため、概念ID[4132161](http://athena.ohdsi.org/search-terms/terms/4132161) ("Oral") が使われています。| +|LOT_NUMBER|NULL|製造業者が製造した医薬品の特定の数量またはロットに割り当てられた識別子。この情報はめったに取得されない。| +|PROVIDER_ID|NULL|薬物レコードに処方医師がリストされている場合、その医師のIDがこのフィールドに入ります。その場合、PROVIDERテーブルのPROVIDER_IDが含まれます。| +|VISIT_OCCURRENCE_ ID|509|薬剤が処方された時のVISIT_OCCURRENCEテーブルの外部キー| +|VISIT_DETAIL_ID|NULL|薬剤が処方されたVISIT_DETAILテーブルの外部キーです。| +|DRUG_SOURCE_ VALUE|69842087651|ソースデータに表示されている薬剤のコードです。ローレンさんの場合、NDCコードはここに格納されています。| +|DRUG_SOURCE_ CONCEPT_ID|750264|ソースでの薬剤の値を表す概念です。概念[750264](http://athena.ohdsi.org/search-terms/terms/750264) は"Acetaminophen 325 MG Oral Tablet "のNDCコードを表しています。 +|ROUTE_SOURCE_ VALUE|NULL|ソースに記載されている投与経路に関する詳細な情報。| ### PROCEDURE_OCCURRENCE{#procedureOccurrence} -PROCEDURE_OCCURRENCE 테이블에는 의료 서비스 제공자가 진단 또는 치료 목적으로 환자에게 주문하거나 시행한 활동 또는 과정에 대한 기록이 포함되어 있다. Procedure는 다양한 수준의 표준화를 통해 다양한 형태로 여러 데이터 출처에 존재한다. 예를 들면 다음과 같다: + PROCEDURE_OCCURRENCE テーブルには、医療提供者が診断目的または治療目的で患者に処方したり、投与したりした活動やプロセスの記録が含まれています。処置は、標準化のレベルが異なる様々な形で、様々なデータソースに存在しています。例えば、以下のようなものがあります。 - * 수행된 시술을 포함한 의료 서비스에 대한 청구의 일부로 시술 코드가 포함하는 의료 청구. - * 발주 정보로부터 시술에 대한 정보를 수집하는 전자 의무 기록. - -#### Lauren이 받은 시술은 무엇일까? {-} + * 診療報酬請求書には、提供された医療サービスの請求書の一部として提出され、実施された処置の処置コードが含まれています。 + * 電子カルテにオーダとして記録された処置。 + +#### What Procedures Did Lauren Have? {-} -Lauren의 설명에서 2013년 1월 14일에 4x5cm 낭종을 왼쪽 난소 초음파를 통해 확인했다는 것을 알 수 있다. PROCEDURE_OCCURRENCE 테이블에 나타내는 방법은 다음과 같다: +彼女の説明から、私たちは彼女が2013-01-14に彼女の左卵巣の超音波検査を受けて4x5cmの嚢胞を見つけたことを把握しています。これがPROCEDURE_OCCURRENCEテーブルでどのように見えるかを示します。 -Table: (\#tab:procedureOccurrence) PROCEDURE_OCCURRENCE 테이블. +Table: (\#tab:procedureOccurrence)PROCEDURE_OCCURRENCEテーブル -Column name|Value|Explanation -:---------------------|:-----------|:-------------------------------------- -|PROCEDURE_ OCCURRENCE_ID|1277|이는 일반적으로 테이블의 각 기록에 대한 고유 식별자를 생성하는 자동으로 생성되는 값이다.| -|PERSON_ID|1|PERSON 테이블에서 Laura의 기록에 대한 외래 키이며 PERSON을 PROCEDURE_OCCURRENCE에 연결한다.| -|PROCEDURE_ CONCEPT_ID|4127451|골반 초음파에 대한 SNOMDE 처치 코드는 304435002이고, Concept [4127451](http://athena.ohdsi.org/search-terms/terms/4127451)로 나타낼 수 있다.| -|PROCEDURE_DATE|2013-01-14|처치가 시행된 날짜.| -|PROCEDURE_ DATETIME|2013-01-14 00:00:00|처치가 시행된 날짜 및 시각. 시간을 알 수 없는 경우 자정으로 입력한다.| -|PROCEDURE_TYPE_ CONCEPT_ID|38000275|해당 열은 보험 청구, 전자 의무 기록(EHR) 내의 발주 기록과 같은 처치 기록의 출처에 대한 정보를 제공하기 위한 것이다. 해당 예제에서 Concept ID [38000275](http://athena.ohdsi.org/search-terms/terms/38000275) ("EHR order list entry")이 전자 의무 기록(EHR)으로부터의 처치 기록으로 사용된다.| -|MODIFIER_CONCEPT_ ID|0|이는 처치에 대한 한정어를 나타내는 Concept Id를 위한 부분이다. 예를 들어, 기록에 CPT4의 처치가 양측에서 수행되었다고 한다면 concept ID [42739579](http://athena.ohdsi.org/search-terms/terms/42739579) ("Bilateral procedure")가 사용되는 것이다.| -|QUANTITY|0|발주 또는 등록된 처치의 수. 수량이 누락되거나 숫자 0 또는 1일 경우 모두 같은 뜻이다.| -|PROVIDER_ID|NULL|처치 기록에 제공자가 기록되어 있으면, 제공자의 ID를 이 영역에 입력한다. 이는 PROVIDER 테이블에 있는 PROVIDER_ID의 외래 키 여야만 한다.| -|VISIT_OCCURRENCE_ ID|740|처치가 실행된 방문 정보(VISIT_OCCURRENCE 테이블의 VISIT_OCCURRENCE_ID로 표시됨)를 알 수 있을 경우 입력한다.| -|VISIT_DETAIL_ID|NULL|처치가 실행된 방문에 대한 세부 사항(VISIT_DETAIL 테이블의 VISIT_DETAIL_ID로 표시됨)이 있을 경우 입력한다.| -|PROCEDURE_SOURCE_ VALUE|304435002|원본 데이터에 있는 그대로의 처치에 대한 코드 및 정보.| -|PROCEDURE_SOURCE_ CONCEPT_ID|4127451|처치의 원본 값을 나타내는 Concept.| -|MODIFIER_SOURCE_ VALUE|NULL|원본 데이터에 나타난 그대로의 원본 코드에 대한 한정어.| +|Column name|Value|Explanation +|:---------------------|:-----------|:-------------------------------------- +|PROCEDURE_ OCCURRENCE_ID|1277|通常、各レコードの一意の識別子を作成する自動生成された値です。| +|PERSON_ID|1|PERSONテーブルのローレンさんのレコードに対する外部キーであり、PERSONをPROCEDURE_OCCURRENCEにリンクしています。| +|PROCEDURE_ CONCEPT_ID|4127451|SNOMEDの骨盤超音波検査の検査コードは304435002で、概念[4127451](http://athena.ohdsi.org/search-terms/terms/4127451)で表されています。| +|PROCEDURE_DATE|2013-01-14|処置が実施された日付| +|PROCEDURE_ DATETIME|2013-01-14 00:00:00|T処置が行われた日付と時間。時間は不明なので深夜とします。| +|PROCEDURE_TYPE_ CONCEPT_ID|38000275|このカラムは手順レコードの出所についての情報を提供することを目的としています。この例では、処置のレコードが電子カルテからのものであるため、 概念ID[38000275](http://athena.ohdsi.org/search-terms/terms/38000275) ("EHR order list entry"(電子カルテにおけるオーダー))が使われています。| +|MODIFIER_CONCEPT_ ID|0|処置の修飾子を表す概念ID。例えばCPT4において手技が両側で行われたと記録に記載されていた場合、概念ID[42739579](http://athena.ohdsi.org/search-terms/terms/42739579) ("Bilateral procedure")が使われます。| +|QUANTITY|0|オーダあるいは実施された処置の量。欠落している場合、0と1という数字はすべて同じ意味になります。| +|PROVIDER_ID|NULL|処置レコードに医師が記載されている場合、その医師のIDがこのフィールドに入ります。これはPROVIDERテーブルのPROVIDER_IDへの外部キーでなければなりません。| +|VISIT_OCCURRENCE_ ID|740|確認出来る場合、処置が実行されたVISIT(VISIT_OCCURRENCEテーブルから取得したVISIT_occurrence_idで表されます)です。| +|VISIT_DETAIL_ID|NULL|確認出来る場合、処置が実行されたVISITの詳細(VISIT_DETAILテーブルから取得したVISIT_detail_idで表されます)です。| +|PROCEDURE_SOURCE_ VALUE|304435002|ソースデータに表示される処置のコードまたは情報| +|PROCEDURE_SOURCE_ CONCEPT_ID|4127451|ソースデータでの処置を表す概念です。| +|MODIFIER_SOURCE_ VALUE|NULL|ソースデータでの修飾子のコードです。| -## 부가 정보 +## Additional Information -이 장에서는 데이터 표현 방법의 예로 CDM에서 사용할 수 있는 일부 테이블만을 다룬다. 자세한 정보는 위키 사이트[^cdmWikiUrl]에서 참고할 수 있다. +この章では、データがどのように表現されるかの例として、CDMで利用可能な表の一部のみを取り上げます。詳細はwikiサイト[^cdmWikiUrl]を参照してください。 [^cdmWikiUrl]: https://github.com/OHDSI/CommonDataModel/wiki -## 요약 +## Summary ```{block2, type="rmdsummary"} -- CDM은 광범위한 관찰 연구 활동을 지원하도록 설계되었다. -- CDM은 개인 중심 모델이다. +- CDMは、幅広い観察研究活動を支援するために設計されています。 -- CDM은 데이터 구조를 표준화할뿐만 아니라 표준화된 어휘를 통해 내용 표현을 표준화한다. +- CDM は人を中心としたモデルです。 -- 충분한 추적가능성을 위하여 원본 코드가 CDM에 유지된다. +- CDM はデータの構造を標準化するだけでなく、標準化された用語集を通して内容の表現も標準化しています。 + +- ソースデータのコードは CDM で管理されており、完全なトレーサビリティが確保されています。 ``` -## 예제 +## Exercises -#### 전제 조건 {-} +#### Prerequisites {-} -첫번째 연습에서는 앞에서 설명한 CDM테이블을 확인해야 하며, ATHENA[^athenaCdmUrl] 또는 ATLAS[^atlasCdmUrl]를 통해 용어에 있는 Concept을 찾아야 할 것이다. +これらの最初の演習では、先ほど説明した CDMのテーブルについて復習する必要があり、ATHENA[^athenaCdmUrl]やATLAS[^atlasCdmUrl]を使って用語集の概念を調べる必要があります。 [^athenaCdmUrl]: http://athena.ohdsi.org/ [^atlasCdmUrl]: http://atlas-demo.ohdsi.org ```{exercise, exerciseJohnPerson} -John은 1974 년 8 월 4 일에 태어난 흑인 남자이다. 이 정보를 인코딩하는 PERSON 테이블 항목을 정의하십시오. - +ジョンは、1974年8月4日生まれのアフリカ系アメリカ人男性。 この情報をコード化したPERSONテーブルのエントリを定義してください。 ``` ```{exercise, exerciseJohnOp} -John은 2015 년 1 월 1 일에 현재 이용하는 보험에 등록했다. 그의 보험 데이터베이스의 데이터는 2019 년 7 월 1 일에 추출되었다. 이 정보를 인코딩하는 OBSERVATION_PERIOD 테이블 항목을 정의하십시오. - +ジョンは2015年1月1日に現在の保険に加入しました。彼の保険データベースからのデータは、2019年7月1日に抽出されました。この情報をコード化したOBSERVATION_PERIODテーブルのエントリを定義してください。 ``` ```{exercise, exerciseJohnDrug} -John은 2019 년 5 월 1 일에 Ibuprofen 200 MG Oral 정제 (NDC 코드 : 76168009520)를 30 일간 투여하도록 처방되었다. 이 정보를 인코딩하는 DRUG_EXPOSURE 테이블 항목을 정의하십시오. - +ジョンは2019年5月1日にイブプロフェン200mg経口錠（NDCコード：76168009520）を30日分処方されました。この情報をコード化するDRUG_EXPOSUREテーブルのエントリを定義してください。 ``` -#### 전제 조건 {-} +#### Prerequisites {-} -해당 마지막 세 연습 문제에서는 \@ref(installR)절에 설명된 것과 같이 R,R-Studio 그리고 Java가 설치되었다고 가정한다. [SqlRender](https://ohdsi.github.io/SqlRender/), [DatabaseConnector](https://ohdsi.github.io/DatabaseConnector/) 및 [Eunomia](https://ohdsi.github.io/Eunomia/) 패키지가 요구되고 아래 내용을 통해 설치할 수 있다: +これらの最後の 3 つの演習では、R、R-Studio、Java がセクション＠ref(installR)で説明されているようにインストールされていることを前提としています。また，[SqlRender](https://ohdsi.github.io/SqlRender/), [DatabaseConnector](https://ohdsi.github.io/DatabaseConnector/), [Eunomia](https://ohdsi.github.io/Eunomia/)パッケージも必要です。これらのパッケージは次のようにしてインストールすることができます。 ```{r eval=FALSE} install.packages(c("SqlRender", "DatabaseConnector", "devtools")) devtools::install_github("ohdsi/Eunomia", ref = "v1.0.0") ``` -Eunomia 패키지는 로컬 R 세션 내에서 실행될 CDM의 가상 데이터 세트를 제공한다. 연결 세부 사항은 아래 내용을 통하여 얻을 수 있다: +Eunomiaパッケージは、ローカルのRセッション内で実行されるCDM内のシミュレートされたデータセットを提供します。接続の詳細は以下のようにして得られます。 ```{r eval=FALSE} connectionDetails <- Eunomia::getEunomiaConnectionDetails() ``` -CDM 데이터 베이스 스키마는 “main”이다. +CDMデータベースのスキーマは "main "です。 ```{exercise, exerciseGiBleedRecords} -SQL과 R을 사용하여 "Gastrointestinal hemorrhage" (concept ID [192671](http://athena.ohdsi.org/search-terms/terms/192671)) 질환의 모든 기록을 검색한다. +SQLとRを使って、条件「胃腸出血」(概念ID[192671](http://athena.ohdsi.org/search-terms/terms/192671))のすべてのレコードを検索します。 ``` ```{exercise, exercisePersonSource} -SQL과 R을 사용하여 원본 코드로 "Gastrointestinal hemorrhage" 질환의 모든 기록을 검색한다. 이 데이터베이스는 ICD-10을 사용하며 관련 ICD-10 코드는 "K92.2"이다. - +SQLとRを使用して、ソースデータのコードを使用して症状「胃腸出血」のすべてのレコードを取得します。このデータベースはICD-10を使用しており、関連するICD-10コードは "K92.2 "です。 ``` ```{exercise, exercisePerson61Records} -SQL과 R을 사용하여 PERSON_ID가 61 인 사람의 관찰 기간을 검색하십시오. +SQLとRを使って、PERSON_ID 61の人の観察期間を取得します。 ``` - - -답변은 부록 \@ref(Cdmanswers)에서 확인 할 수 있다. - +回答は、付録\@ref(Cdmanswers)に掲載されています。 diff --git a/StandardizedVocabularies.Rmd b/StandardizedVocabularies.Rmd index 9f2679c..0604a46 100644 --- a/StandardizedVocabularies.Rmd +++ b/StandardizedVocabularies.Rmd @@ -1,345 +1,350 @@ -# OMOP 표준 용어 {#StandardizedVocabularies} +# Standardized Vocabularies {#StandardizedVocabularies} \index{standardized vocabularies} *Chapter leads: Christian Reich & Anna Ostropolets* -흔히 "용어(the Vocabulary)"라고 불리는 OMOP 표준 용어(Standardized Vocabularies)는 OHDSI 연구 네트워크의 기초적인 부분이자, 공통 데이터 모델(CDM)의 핵심 부분이다. OMOP 표준 용어는 데이터의 내용을 정의함으로써 분석 방법, 정의, 결과를 표준화하여 진정한 원격 (방화벽 뒤에서) 네트워크 연구와 분석을 가능하게 한다. 일반적으로, 코딩 체계를 사용한 구조화된 데이터이든 혹은 자유진술문으로 구성된 데이터이든, 관찰 의료 데이터의 내용을 찾아 해석하는 것은 임상 사건을 설명하는 수 많은 방법을 고민하는 연구 실무자들에게 까지 전달되기 마련이다. OHDSI는 표준화된 형식뿐 아니라 엄격한 표준 컨텐츠와의 조화를 필요로 한다. +「Vocabulary」と呼ばれるOMOP標準用語集は、Common Data Model（CDM）の不可欠な要素であり、OHDSI研究ネットワークの基盤です。データの内容を定義することにより、手法、定義、結果の標準化が可能になり、ファイアウォールの内側に置かれたデータを研究ネットワークに参加させ分析対象とするための道筋を切り拓きます。通常、観察医療データの内容の検索と解釈は、それがコーディング手法を採用した構造化データであれ、フリーテキストで記述されたものであれ、臨床イベントを記述するための無数の異なる方法に直面している研究者に託されます。OHDSIでは、標準化された形式だけでなく、厳密に標準化された内容に適合させることが求められます。 -이 장에서는 먼저 기초적인 부분을 이해하고 활용하기 위해, 표준 용어의 주요 원칙, 구성 요소 및 관련 규칙, 규약 및 일반적인 상황에 대해 설명하고자 한다. 또한 이를 지속적으로 개선하기 위해 커뮤니티의 지원이 필요한 곳을 언급할 것이다. +この章では、まず、標準化された語彙の主要な原則、そのコンポーネント、関連するルール、規則、およびいくつかの典型的な状況について説明します。これらはすべて、この基本的なリソースを理解して利用するために必要です。また、継続的に改善するためにコミュニティのサポートが必要な場所も紹介します。 -## 왜 용어(Vocabularies)인가, 그리고 왜 표준화인가? +## Why Vocabularies, and Why Standardizing -의학 용어는 흑사병 (plague: 페스트) 및 기타 질병들을 관리하기 위해 사용했던, 중세 런던의 사망 증명서(Bills of Mortality) 까지 거슬러 올라간다. (그림 \@ref(fig:bill) 참조) \index{Bill of Mortality} - -```{r bill, fig.cap='1660 London Bill of Mortality, 당시 알려진 62가지 질병의 분류 체계를 사용하여 사망한 거주자의 사망 원인을 보여준다.',echo=FALSE, out.width='100%', fig.align='center'} +医学用語は、中世のロンドンでペストやその他の病気の発生を管理するための「Bill of Mortality」にまでさかのぼります（図参照 \@ref(fig:bill)). \index{Bill of Mortality} + +```{r bill, fig.cap='1660年のロンドン死亡率表。当時知られていた62種類の疾患の分類システムを用いて死亡した住民の死因を示したもの',echo=FALSE, out.width='100%', fig.align='center'} knitr::include_graphics("images/StandardizedVocabularies/bill.jpg") -``` +``` + +以来、分類の規模と複雑さは大幅に拡大し、処置や診療行為、医薬品、医療機器など医療分野における他領域にも広がっています。ただし主な原則は変わっていません。患者データの収集、分類、分析を目的として、一部の医療コミュニティが合意して管理する語彙、用語、階層、またはオントロジーであるということです。用語集の多くは、長期的な権限を持つ公的機関や政府機関によって維持されています。例えば、世界保健機関（WHO）は、国際疾病分類（ICD）を作成しており、最近では第 11 版（ICD11）が追加されました。各国は、ICD10CM（米国）、ICD10GM（ドイツ）などの国別のローカルバージョンを作成しています。また、政府は医薬品の市場と販売を管理し、認証を受けた医薬品の国立のリポジトリを維持しています。また、民間においても、商用製品や電子カルテ（EHR）システムや医療保険請求報告などの内部使用のために、用語集が使用されています。 -그 후, 의학 용어 분류는 규모와 복잡성이 크게 확대되면서 시술, 서비스, 약물, 의료기기 등, 의료의 다른 측면으로 널리 전파되었다. 의학 용어 분류의 주요 원칙은 동일하게 유지된다: 즉, 일부 의료 커뮤니티가 환자 데이터를 획득, 분류 및 분석하기 위한 목적으로 동의한 통제 어휘, 전문용어, 계층 및 언어 concept (ontologies: 온톨로지) 이다. 이러한 용어집의 상당수는 공공기관과 정부 기관에서 장기적으로 의무 관리하고 있다. 예를 들면, 세계보건기구(WHO)는 최근 국제 질병분류(ICD)에 11차 개정판(ICD11)을 추가하였다. 지역 정부들은 ICD10CM(미국), ICD10GM(독일) 등과 같은 국가별 버전을 만들고 있다. 정부들은 또한 의약품의 마케팅과 판매를 통제하고 인증된 의약품의 국가 저장 목록을 운영하고 있다. 용어집은 상업용 제품 또는 내부용으로 민간 부문에서도 사용된다. 예를 들면, 전자건강기록(EHR) 시스템과 의료보험청구용이 있다. +結果的に、それぞれの国、地域、医療システム、医療機関が独自の用語集を持っている傾向があり、その用語集で適用されている分類は使用されている場所のみで使われている可能性が高いです。このような無数の用語集が、システムの相互運用性を妨げています。標準化は、患者データの交換を可能にし、グローバルレベルでの健康データ分析を可能にし、診療行為の分析や品質評価に関して体系的で標準化された研究を可能にする鍵である。この問題に対処するために、上記のWHOやSNOMED（Standard Nomenclature of Medicine）やLOINC（Logical Observation Identifiers Names and Codes）のように、多国籍の組織が立ち上がり、幅広い標準規格を作り始めています。 米国では、Health IT Standards Committee（HITAC）がSNOMED、LOINC、医薬品用語集RxNormを標準規格として使用することを全米健康ITコーディネータ（ONC）に勧告して、多様な主体間の健康情報交換のための全国共通プラットフォームでの使用を推奨しています。 -그 결과, 각 국가, 지역, 의료시스템 및 의료기관은 그 용어가 사용되는 지역에서만 쓰이는 자체 질병분류체계를 갖고 있을 가능성이 높다. 이러한 무수히 많은 용어집은 사용 중인 시스템의 상호운용성을 방해한다. 표준화는 환자 데이터 교환을 가능하게 하고, 전 세계적 수준의 의료 데이터 분석의 길을 열어주고, 성능 특성 분석 및 품질 평가를 포함한 체계적이고 표준화된 연구를 가능하게 하는 핵심 요소이다. 이러한 문제를 해결하기 위해, 위에서 언급된 WHO와 the Standard Nomenclature of Medicine(SNOMED) 또는 Logical Observation Identifiers Names and Codes(LOINC) 같은 다국적 기관들이 생겨나고 광범위한 표준들을 만들기 시작했다. 미국의 보건 IT 표준 위원회 HITAC(Health IT Standards Committee)는 다양한 단체 간의 건강 정보 교환을 위한 공통 플랫폼에서 사용하기 위해 ONC(National Coordinator for Health IT)의 표준으로 SNOMED, LOINC 및 약물용어인 RxNorm을 사용할 것을 권장하고 있다. +OHDSI は、観測研究の世界標準であるOMOP CDMを開発しました。CDMの一部として、OMOP標準用語集は主に2つの目的で利用できます。 -OHDSI는 관찰 연구를 위한 국제 표준인 OMOP CDM을 개발했다. CDM의 일부로, OMOP 표준 용어는 다음 두 가지 목적으로 사용 할 수 있다: +- コミュニティで使用されているすべての用語の共通リポジトリ +- 研究に利用するための標準化とマッピング -- 커뮤니티에서 사용되는 모든 용어의 공통 저장 자료 -- 연구에 사용하기 위한 표준화와 매핑 +標準化された用語集はコミュニティに無料で提供されており、OMOP CDMインスタンスには***必須の参照表( mandatory reference table)として使用する必要**があります。 -표준화된 용어는 커뮤니티에 무료로 제공되며, **OMOP CDM 실제 사용시마다 필수 참조 테이블로 사용되어야 한다.** -### 표준화된 용어 구축 +### Building the Standardized Vocabularies -표준 용어의 모든 용어는 동일한 공통 형식으로 통합된다. 이를 통해 연구자들이 기존 용어의 여러 가지 형식과 수명 주기 규칙을 이해하거나 처리할 필요가 없다. 모든 용어는 Pallas 시스템[^pallasUrl]을 사용하여 정기적으로 새로워지고 통합 된다. 용어는 OMOP CDM Workgroup의 일부인 OHDSI Vocabulary 팀이 만들어 운영하고 있다. 오류가 발견되면 OHDSI Forums[^forums2Url] 또는 CDM Github 페이지[^cdmIssuesUrl]에 게시하여 오류를 보고하고 리소스를 개선할 수 있도록 도와주길 바란다.\index{Pallas system} +標準用語集のすべての用語は、共通のフォーマットに統合されています。これにより、研究者は元の用語集の複数の異なるフォーマットやライフサイクルの慣習を理解して扱う必要がなくなります。すべての用語集は定期的に更新され、Pallasシステムを使用して組み込まれています[^pallasUrl]。間違いを見つけた場合は、OHDSI Forums[^forums2Url]またはCDM Github[^cdmIssuesUrl]ページに投稿して、このリソースの改善に役立ててください。\index{Pallas system} [^pallasUrl]: https://github.com/OHDSI/Vocabulary-v5.0 [^forums2Url]: https://forums.ohdsi.org [^cdmIssuesUrl]: https://github.com/OHDSI/CommonDataModel/issues -### 표준 용어 이용하기 {#accessVocabularies} +### Access to the Standardized Vocabularies {#accessVocabularies} -표준 용어 정보를 얻기 위해, Pallas를 직접 실행할 필요는 없다. 대신, ATHENA[^athenaUrl]에서 최신 버전을 다운로드하여 로컬 데이터베이스에 적재하면 된다. ATHENA도 용어를 면밀히 검색하는 기능이 있다. \index{ATHENA} \index{standardized vocabularies!download} \index{standardized vocabularies!search} +標準化された用語集を取得するためには、Pallasを自分で起動する必要はありません。その代わりに、ATHENA[^athenaUrl]から最新版をダウンロードして、ローカルデータベースにロードすることができます。ATHENAは用語集のファセット検索もできます。\index{ATHENA} \index{standardized vocabularies!download} \index{standardized vocabularies!search} [^athenaUrl]: http://athena.ohdsi.org -모든 표준 용어 테이블에 포함된 zip 파일을 다운로드하려면, OMOP CDM에 필요한 모든 용어집을 선택해야 한다. 표준 concept을 가진 용어집은 (\@ref(standardConcepts)절 참조) 미리 선택되어 있다. source data에 사용되는 vocabularies를 추가한다. 저작권이 있는 용어집은 선택할 수 없다. 해당 용어집을 리스트에 포함하려면 "License required" 버튼을 클릭해야 한다. 용어팀이 당신에게 연락할 것이고, 당신이 라이센스를 제출하도록 요청하거나, 해당 라이센스를 얻는데 적절한 사람들과 연결해줄 것이다. - -### 용어의 원천: 도입 vs 구축 +すべての標準用語集の表を含むzip ファイルをダウンロードするにあたり、OMOP CDM に必要なすべての語彙を選択してください。標準概念（セクション\@ref(standardConcepts)参照）と非常に一般的な使用法を持つ用語は既定で選択されています。ソースデータで使用されている用語集を追加してください。プロプライエタリな用語集には選択ボタンは表示されません。そのような用語集をリストに組み込むには、「License required」ボタンをクリックしてください。Vocabulary Team から連絡があり、ライセンスの確認やライセンス取得のためのサポートを依頼することができます。 -OHDSI는 일반적으로 용어집을 새로 구축하기보다는 기존에 사용되는 용어집을 채택하는 것을 선호한다. 왜냐하면 (i) 많은 용어집이 이미 공동체의 관찰 데이터에 사용되어 왔으며 (ii) 용어집의 구성 및 유지 관리가 복잡하여 오랜 기간 동안 많은 이해관계자의 의견을 수렴해야 하기 때문이다. 이러한 이유로, 전담 조직은 생성, 사용 중단, 병합 및 분할의 수명 주기에 따라 용어집을 제공하고 있다. (\@ref(conceptLifeCycle)절 참조) 현재 OHDSI는 Type Concepts (예를 들어, condition type concepts)과 같은 내부 관리 용어만 생성하고 있다. 유일한 예외는 RxNorm Extension인데, RxNorm Extension은 미국 이외의 지역에서만 사용되는 약물 용어집이다. (\@ref(rxNormExtension)절 참조) +### Source of Vocabularies: Adopt Versus Build -## Concept +OHDSI は一般的に、(i)多くの用語集が既にコミュニティの観察データに利用されていること、(ii)用語集の構築と維持は複雑であり、成熟するまでに長い期間をかけて多くの利害関係者の意見を必要とするため、一から構築するよりも既存の用語集を採用することを選びました。専門組織が提供する用語集は、生成、非推奨、マージ、分割というライフサイクルを経ています（セクション \@ref(conceptLifeCycle)）。現在のところ、OHDSI は、型概念(Type Concepts)（例えば、症状型概念）のような内部管理用用語集のみを作成しています。唯一の例外は、米国外でのみ使用される薬剤をカバーする語彙であるRxNorm Extensionです（セクション\@ref(rxNormExtension)参照）。 -OMOP CDM의 모든 임상 사건들은 concept으로 표현되며, 이는 각 사건의 의미 있는 concept을 나타낸다. Concept은 데이터 기록들의 기본적인 구성 요소로써, 모든 테이블을 거의 예외 없이 완전 정규화한다. Concept은 CONCEPT table에 저장된다. (그림 \@ref(fig:concept) 참조) \index{concept} +## Concepts -```{r concept, fig.cap='OMOP CDM에서 vocabulary의 표준 표현. 위의 예는 심방세동의 SNOMED 코드에 대한 CONCEPT 테이블 레코드이다.',echo=FALSE, out.width='90%', fig.align='center'} +OMOP CDM のすべての臨床イベントは概念(Concept)を使って表現されます。これらの概念は各イベントの意味的な概念を表します。これらはデータレコードの基本的な構成要素であり、テーブルは少数の例外を除いて完全に正規化されています。概念は CONCEPT テーブルに格納されます (図参照\@ref(fig:concept))。\index{concept} + +```{r concept, fig.cap='OMOP CDMにおける用語の概念の標準的表現。この例は、心房細動のSNOMEDコードに対応するCONCEPTテーブルのレコードです。',echo=FALSE, out.width='90%', fig.align='center'} knitr::include_graphics("images/StandardizedVocabularies/concept.png") -``` +``` -이 시스템은 포괄적이지 않으면 안 된다. 즉, 환자의 의료 경험 (예를 들어, 진단명, 시술, 약물 노출 등) 및 의료시스템의 일부 관리 정보 (예를 들어, 병원 방문, 관리 부위 등) 과 관련된 모든 이벤트를 포괄할 만큼 충분히 많은 concept이 있어야 한다. +この体系は、**包括的**であることを意図しています。すなわち、患者の健康管理に関連するあらゆる事象（例えば、状態、処置、薬剤への曝露など）をカバーするのに十分な概念があるだけでなく、医療情報システムの管理情報の一部（例えば、来院、治療場所など）をカバーするのに十分な概念があります。 ### Concept IDs -각각의 concept ID는 Concept ID를 기본 키로 할당한다. 이 무의미한 정수 ID는, 단어의 원 코드보다는 CDM 이벤트 테이블에 데이터를 기록하는 데 사용된다. +各概念には、主キーとして使用する概念ID(concept ID)が割り当てられています。IDは意味を持たない整数値であり、元の用語集におけるコードではありません。概念IDはCDMイベントテーブルにデータを記録するために使用されます。 \index{concept!identifier} -### Concept 이름 +### Concept Names -각 concept에는 하나의 이름이 있다. 그 이름은 항상 영어로 되어있다. concept들은 용어집의 source로부터 가져온다. source vocabulary에 둘 이상의 이름을 가지고 있으면, 가장 표현력이 높은 이름이 선택되고, 나머지 이름은 동일한 CONCEPT_KEY로 CONCEPT_SYNONYM 테이블에 저장된다. 영어 이외의 이름은 CONCEPT_SYNONYM에 기록되며, 적합한 language concept ID가 LANGUAGE_CONCEPT_ID 필드에 기록된다. 이름은 255자까지의 길이를 가지는데, 너무 긴 이름은 잘라내고 최대 1,000자까지 저장 가능한 다른 이름의 동의어로 기록된다. +それぞれの概念には一つの名前がついています。名前は常に英語です。それらは用語のソースからインポートされます。元の用語に複数の名前がある場合、最も表現力の高いものが選択され、残りの名前は同じCONCEPT_IDキーの下にCONCEPT_SYNONYMテーブルに保存されます。英語以外の名前も同様にCONCEPT_SYNONYMに記録され、LANGUAGE_CONCEPT_IDフィールドに適切な言語概念IDが割り当てられます。名前の長さは255文字で、非常に長い名前は切り捨てられ、完全な長さのものは1000文字までの別のシノニムとして記録されます。 -### 도메인 {#conceptDomains} +### Domains {#conceptDomains} -각 concept에는 DOMAIN_ID가 필드에 할당되는데, 숫자 CONCEPT_ID와 달리 도메인의 대소문자를 구분하면서 길이가 짧은 고유한 영 숫자 ID이다. 이러한 각 도메인의 예로는 "Condition", "Drug", "Procedure", "Visit", "Device", "Specimen" 등이 있다. 모호하거나 pre-coordinated(combination) concepts의 경우 combination 도메인에 속할 수 있으나, 표준 concept은 (\@ref(standardConcepts)절 참조) 항상 단일 도메인에 할당된다. 도메인은 또한 어떤 임상 사건 또는 임상 속성 등이 어떤 CDM 테이블과 필드에 기록되어야 하는지 알려준다. -도메인 할당은 [Pallas](https://github.com/ohDSI/vocabulary-v5.0) 내에 경험적 지식을 이용한 용어 수집 중에 수행되는 OMOP 고유의 특징이다. Source vocabularies는 서로 다른 도메인들이 함께 혼재되어 있는 경우가 많으나, 그 정도는 각기 다르다 (그림\@ref(fig:domains) 참조). \index{domain!concept} +各概念は、DOMAIN_IDフィールドにドメインが割り当てられます。DOMAIN_IDは、数値のCONCEPT_IDとは対照的に、ドメインのための短い大文字小文字を区別するユニークな英数字のIDです。このようなドメイン識別子の例として、"Condition"、"Drug"、"Procedure"、"Visit"、"Device"、"Specimen "などがあります。曖昧な概念又は事前に調整された（組み合わせた）概念は、組み合わせドメインに属することができるが、標準概念（セクション\@ref(standardConcepts)参照）には、常に単一ドメインが割り当てられます。ドメインはまた、臨床事象や事象属性がどの CDM テーブルやフィールドに記録されるかを指示します。 +ドメインの割り当ては、OMOP固有の機能として、[Pallas](https://github.com/ohDSI/vocabulary-v5.0)で示されているヒューリスティックな手法を用いて、用語の取り込み中に行われます。ソース用語集は、程度の差はあれ、複数のドメインのコードを組み合わせることがあります(図\@ref(fig:domains))。\index{domain!concept} -```{r domains, fig.cap='시술 용어인 CPT4와 HCPCS의 도메인 할당 비율. 직관적으론, 이러한 용어집은 한 도메인의 코드와 concept을 포함하고 있어야 하지만, 실제로는 여러 도메인들이 혼재되어있다.',echo=FALSE, out.width='70%', fig.align='center'} +```{r domains, fig.cap='DPT4とHCPCSの処置用語集におけるドメインの割り当て。直感的には、これらの用語集には単一のドメインのコードと概念が含まれているはずですが、実際には混在しています. +',echo=FALSE, out.width='70%', fig.align='center'} knitr::include_graphics("images/StandardizedVocabularies/domains.png") -``` +``` -경험적 지식을 이용한 도메인 할당 방법은 도메인의 정의를 따라 진행한다. -이러한 정의는 CDM의 테이블 및 필드 정의에서 파생된다 (\@ref(CommonDataModel)장 참조). 경험적 지식은 완벽하지 않으며, 불분명하다 (\@ref(specialSituations)절의 "Special Situations" 참조). 만일, 잘못 지정된 concept 도메인을 발견한다면, [Forums](https://forums.ohdsi.org) 또는 [CDM issue](https://github.com/OHDSI/CommonDataModel/issues) 게시판을 통하여, 문제점을 보고하고 개선하도록 해야 한다. +ドメインのヒューリスティックはドメインの定義に従います。これらの定義は、CDMのテーブルとフィールドの定義から導き出されます(Chapter \@ref(CommonDataModel)を参照)。ヒューリスティックは完全ではありません。グレーゾーンがあります(セクション\@ref(specialSituations) "Special Situations "を参照)。概念ドメインの割り当てが間違っているのを見つけた場合は、[Forums](https://forums.ohdsi.org) または [CDM issue](https://github.com/OHDSI/CommonDataModel/issues) に投稿して、プロセスを改善するために報告してください。 -### 용어집 (Vocabularies) +### Vocabularies -각 용어집에는 대소문자를 구분하는 고유한 영 숫자 ID가 있으며, 일반적으로 용어집의 약어 이름을 쓰고, 대시는 생략한다. 예를 들자면, ICD-9-CM의 용어 ID는 "ICD9CM" 이다. 현재 OHDSI가 지원하는 용어집은 11개로, 그중 78개가 외부 source에서 채택되었고, 나머지는 OMOP 내부 용어집이다. 이러한 용어는 일반적으로 분기별 일정에 따라 갱신된다. 용어집의 버전은 VOCABULARY reference file에 따라 정의되어 있다. \index{vocabulary} +各用語集のIDは、用語集の略称の後に続く短い大文字小文字を区別するユニークな英数字のIDを持ち、ダッシュは省略されています。例えば、ICD-9-CMは "ICD9CM "という用語IDを持っています。現在OHDSIがサポートしている用語集は111種類で、そのうち78種類は外部からの採用であり、残りはOMOPの内部用語集です。これらの用語集は通常、四半期ごとに更新されます。これらの用語集の出典とバージョンは、VOCABULARY参照ファイルで定義されています。\index{vocabulary}. -### Concept 계층 (Concept Classes) +### Concept Classes -일부 용어집은 대소문자를 구분하는 고유한 영 숫자 ID를 통해 표현되는 코드나 concept을 분류한다. 예를 들어, SNOMED에는 "semantic tag"라고 불리는 33가지 concept 계층을 가지고 있다: "clinical finding", social context, body structure 등 concept 계층은 concept들의 수직적 구분을 말한다. MedDRA 또는 RxNorm과 같은 다른 concept들은 계층화된 계급 내에서 수평적인 수준에서 분류하는 concept 계층들을 가지고 있다. HCPCS와 같이 concept 계층이 없는 용어들은 Concept Class ID를 vocabulary ID로 사용해야 한다. \index{concept!class} +一部の用語集では、コードや概念を分類しており、大文字小文字を区別するユニークな英数字のIDで示されている。例えば、SNOMEDには臨床所見、社会的背景、身体構造などの33の概念クラスがあり、SNOMEDでは「意味タグ(semantic tags)」と呼んでいます。これらは概念群を縦割りで分類するものです。MedDRAやRxNormのような概念クラスは、階層化された階層の中で水平方向に分類しています。HCPCS のように概念クラスを持たない用語は、用語ID を概念クラスIDとみなします。\index{concept!class} -Table: (\#tab:sublassification)concept 계층에서 수평 및 수직 하위분류 원칙에 따른 용어집들 +Table: (\#tab:sublassification) 概念クラスにおける分類手法 -Concept class subdivision principle | Vocabulary -:-------- |:---------------------------------- -Horizontal | all drug vocabularies, ATC, CDТ, Episode, HCPCS, HemOnc, ICDs, MedDRA, OSM, Census -Vertical | CIEL, HES Specialty, ICDO3, MeSH, NAACCR, NDFRT, OPCS4, PCORNET, Plan, PPI, Provider, SNOMED, SPL, UCUM -Mixed | CPT4, ISBT, LOINC -None | APC, all Type Concepts, Ethnicity, OXMIS, Race, Revenue Code, Sponsor, Supplier, UB04s, Visit +|Concept class subdivision principle | Vocabulary +|:-------- |:---------------------------------- +|Horizontal | 全ての医薬品の用語集, ATC, CDТ, Episode, HCPCS, HemOnc, ICDs, MedDRA, OSM, Census +|Vertical | CIEL, HES Specialty, ICDO3, MeSH, NAACCR, NDFRT, OPCS4, PCORNET, Plan, PPI, Provider, SNOMED, SPL, UCUM +|Mixed | CPT4, ISBT, LOINC +|None | APC, all Type Concepts, Ethnicity, OXMIS, Race, Revenue Code, Sponsor, Supplier, UB04s, Visit -수평적 concept 계층을 사용하면 특정 계층 수준을 지정할 수 있게 해준다. 예를 들어, 약물 용어의 RxNorm에서 "Ingredient" concept 계층은 최상위층 계급 레벨을 정의한다. 수직적 모델에서 concept 계층 요소들은 최상위에서 맨 아래까지 모든 계급 중의 하나일 수 있다. +水平に分類される概念クラスでは、特定の階層レベルを決定することができます。例えば、医薬品の用語集であるRxNormでは、概念クラス" Ingredient "は階層の最上位レベルを定義します。垂直分類モデルでは、概念クラスのメンバーは、上から下までの任意の階層レベルを持つことができます。 -### 표준 Concept {#standardConcepts} +### Standard Concepts {#standardConcepts} -각 임상 사건의 의미를 나타내는 하나의 concept을 표준 concept(Standard Concepts)이라고 부른다. 예를 들면, MESH 코드 D001281, CIEL 코드 148203, SNOMED 코드 49436004, ICD9CM 코드 427.31 및 Read 코드 G573000은 모두 condition 도메인에서 "심방세동 atrial fibrillation"을 정의하지만, condition 데이터에서는 SNOMED의 concept만이 표준이고 그 데이터에서 질환을 나타낸다. 나머지는 비표준 concept 또는 원천 concept(source concepts)으로 지정되고, 표준 concept에 매핑이 된다. 표준 concept은 STANDARD_CONCEPT 필드에 "S"라고 표시한다. 그리고 이러한 표준concept만이 "_CONCEPT_ID"로 끝나는 CDM 필드에 데이터를 기록하는 데 사용된다. \index{standard concept} +各々の臨床事象に関して、（候補としての数ある概念の中から）一つの概念が標準概念として選ばれます。例えば、MESHコードD001281、CIELコード148203、SNOMEDコード49436004、ICD9CMコード427.31、ReadコードG573000は、すべて症状ドメインにおいて「心房細動」を定義していますが、SNOMEDの概念だけが標準概念として採用され、データの中で症状を表すのに使われます。他の概念は非標準概念またはソース概念とされ、標準概念へマッピングされます。標準概念は、STANDARD_CONCEPTフィールドの "S "によって示されます。そして、"_CONCEPT_ID "で終わるCDMフィールドにデータを記録するためには、これらの標準概念のみが使用されます。\index{standard concept} -### 비표준 Concept +### Non-Standard Concepts -비표준 concept(Non-Standard Concepts)은 임상사건을 나타내는데 사용되지 않으나, 여전히 표준 용어집의 일부를 구성하고 소스데이터에서 흔히 발견된다. 이런 이유로, 그것들은 "source concepts"라고 부른다. source concepts을 표준 concept으로 변환하는 과정을 "매핑 mapping"이라고 부른다 (\@ref(conceptMapping)절 참조). 비표준 concept은 STANDARD_CONCEPT 필드에 값이 없다(NULL). +非標準概念は臨床事象の表現には使用されないが、標準化語彙の一部であることに変わりはなく、またソースデータに多く見られます。そのため、「ソース概念(source concepts)」とも呼ばれます。ソース概念の標準概念への変換は、「マッピング」と呼ばれるプロセスです（セクション\@ref(conceptMapping)参照）。STANDARD_CONCEPTフィールドでは、非標準概念には値がありません（NULL）。 -### 분류 Concept +### Classification Concepts -분류 concept(Classification Concepts)은 표준이 아니므로 데이터를 나타내는데 사용할 수 없다. 하지만 표준 concept과 어울러져 계층 구조를 나타냄으로서, 계층 쿼리(hierarchical queries)를 수행하는데 사용할 수 있다. 예를 들어, MedDRA 코드 10037908의 모든 하위 항목에 대한 쿼리를 사용하면 (MedDRA license를 받지 않는 사용자에게는 보이지 않음, \@ref(accessVocabularies)절 액세스 제한 참조) 심방세동 atrial Fibrillation에 대한 표준 SNOMED concept이 검색된다. (CONCEPT_ANCESTOR 테이블을 사용한 계층 쿼리는 \@ref(conceptAncestor)절 참조) - 그림 \@ref(fig:hierarchy) 참조. \index{classification concept} +これらの概念は標準概念ではないので、データを表現するために使用することはできません。しかし、これらの概念は標準概念と一緒に階層を構成していますので、階層的なクエリを実行するために使用できます。例えば、MedDRA コード 10037908 の全ての子孫（MedDRA ライセンスを取得していないユーザーには表示されません。アクセス制限についてはセクション　\@ref(accessVocabularies)を確認下さい。）は、心房細動のための標準的なSNOMEDコンセプトを取得します（CONCEPT_ANCESTORテーブルを使用した階層的なクエリについては、セクション\@ref(conceptAncestor)を参照してください） - Figure ＠ref(fig:hierarchy)を参照してください。\index{classification concept} -```{r hierarchy, fig.cap='Standard, non-standard source 및 분류 concept 및 condition 도메인에서의 계층적 관계. SNOMED는 대부분 standard condition concepts (일부 ICDO3에서 파생된 종양학 관련 concept) 에 사용되고, MedDRA concept은 계층 분류 concept에 사용되며, 그 외 다른 모든 용어집은 비표준 concept이나 혹은 계층 구조에 포함되지 않는 원천 concept을 가지고 있다.',echo=FALSE, out.width='100%', fig.align='center'} +```{r hierarchy, fig.cap='症状ドメインにおける標準概念、非標準概念またソース概念、および分類概念とその階層的な関係について。ほとんどの標準的な症状概念にはSNOMEDが使用されます（ICDO3に由来するいくつかの腫瘍関連概念を含む）。階層的な分類概念にはMedDRAの概念が使用されます。他のすべての用語集には階層に参加しない非標準またはソース概念が含まれている。',echo=FALSE, out.width='100%', fig.align='center'} knitr::include_graphics("images/StandardizedVocabularies/hierarchy.png") -``` +``` -concept을 표준, 비표준 및 분류 concept 중 어디로 지정할지 선택할 때, 각 도메인 용어 수준에서 개별적으로 시행한다. 이는 concept의 질, 내장된 계층구조 및 그 용어가 선언된 목적에 따라 행해진다. 또한, 한 용어집의 모든 concept이 표준 concept으로 사용되는 것은 아니다. 어디로 지정할지는 각 도메인마다 분리되어 있고, 각 concept은 유효해야 하며 (\@ref(conceptLifeCycle)절 참조), 다른 용어집에서 하나 이상의 concept이 같은 의미로 경쟁하는 경우 우선순위가 있을 수 있다. 다른 말로 하면, 그런 경우에는 표준 용어집은 존재하지 않는다. 예는 표 \@ref(tab:vocabList)를 참고하기 바란다. +標準概念、非標準概念、分類概念の選択は、通常、用語集レベルで各ドメインごとに個別に行われます。これは、概念の質、組み込まれている階層、用語が定義された目的に基づいて行われます。また、用語のすべての概念が標準概念として使用されるわけではありません。概念の指定はドメインごとに分かれていて、それぞれの概念はアクティブでなければならず（セクション\@ref(conceptLifeCycle)参照）、異なる用語集における複数の概念が同じ意味で競合している場合には、優先順位があるかもしれません。つまり、「標準用語集」というものは存在しないのです。例としては、表の\@ref(tab:vocabList)を参照してください。 -Table: (\#tab:vocabList) 표준, 비표준 및 분류 concept 할당에 활용할 용어집 목록 +Table: (\#tab:vocabList) 標準/非標準/分類 概念の割り当てに使用される用語のリスト -도메인 | 표준 concept | 원천 concept | 분류 concept -:-------- |:--------------- |:--------------- |:------------- -Condition | SNOMED, ICDO3 | SNOMED Veterinary | MedDRA -Procedure | SNOMED, CPT4, HCPCS, ICD10PCS, ICD9Proc, OPCS4 | SNOMED Veterinary, HemOnc, NAACCR | 현재까지 없음 -Measurement | SNOMED, LOINC | SNOMED Veterinary, NAACCR, CPT4, HCPCS, OPCS4, PPI | 현재까지 없음 -Drug | RxNorm, RxNorm Extension, CVX | HCPCS, CPT4, HemOnc, NAAACCR | ATC -Device | SNOMED | Others, currently not normalized | 현재까지 없음 -Observation | SNOMED | Others | 현재까지 없음 -Visit | CMS Place of Service, ABMT, NUCC | SNOMED, HCPCS, CPT4, UB04 | 현재까지 없음 +|Domain | 標準概念への使用 | ソース概念への使用 | 分類概念への使用 +|:-------- |:--------------- |:--------------- |:------------- +|Condition | SNOMED, ICDO3 | SNOMED Veterinary | MedDRA +|Procedure | SNOMED, CPT4, HCPCS, ICD10PCS, ICD9Proc, OPCS4 | SNOMED Veterinary, HemOnc, NAACCR | None at this point +|Measurement | SNOMED, LOINC | SNOMED Veterinary, NAACCR, CPT4, HCPCS, OPCS4, PPI | None at this point +|Drug | RxNorm, RxNorm Extension, CVX | HCPCS, CPT4, HemOnc, NAAACCR | ATC +|Device | SNOMED | Others, currently not normalized | None at this point +|Observation | SNOMED | Others | None at this point +|Visit | CMS Place of Service, ABMT, NUCC | SNOMED, HCPCS, CPT4, UB04 | None at this point -### Concept 코드 +### Concept Codes -concept 코드(Concept Codes)는 원천 용어집 내에서 사용하는 식별자이다. 예를 들어, ICD9CM 또는 NDC 코드는 해당 필드(concept 코드)에 저장되는데, OMOP 테이블은 concept ID를 CONCEPT 테이블에 foreign key로 사용을 한다. 그 이유는, 네임 스페이스가 용어집에 걸쳐 겹치기 때문이고, 동일한 코드가 완전히 다른 의미로 다른 용어에 존재할 수 있기 때문이다. (역자 주: concept 코드는 한 용어집 내에서 유일한 코드로 사용되지만, 같은 코드가 다른 용어집에서 나타날 수 있으나 다른 의미로 사용될 수 있다) (표 \@ref(tab:code1001)참조) \index{concept!code} +ICD9CMやNDCコードはこのフィールドに格納されるが、OMOPテーブルはCONCEPTテーブルへの外部キーとして概念IDを使用する。その理由は、名前空間が用語集間で重複していること、すなわち、同じコードが全く異なる意味を持つ異なる用語集に存在する可能性があるからである（表参照：表 \@ref(tab:code1001) \index{concept!code} -Table: (\#tab:code1001) 같은 concept 코드 1001이 다른 용어집에서 다른 도메인, 다른 concept classes로 사용된다. +Table: (\#tab:code1001) 同一の概念コード1001を持つが、用語集、ドメイン、概念クラスが異なる概念 -Concept ID | Concept Code | Concept Name | Domain ID | Vocabulary ID | Concept Class -:--------- |:---- |:------------ |:---------- |:---------- |:---------- -35803438 | 1001 | Granulocyte colony-stimulating factors | Drug | HemOnc | Component Class -35942070 | 1001 | AJCC TNM Clin T | Measurement | NAACCR | NAACCR Variable -1036059 | 1001 | Antipyrine | Drug | RxNorm | Ingredient -38003544 | 1001 | Residential Treatment - Psychiatric | Revenue Code | Revenue Code | Revenue Code -43228317 | 1001 | Aceprometazine maleate | Drug | BDPM | Ingredient -45417187 | 1001 | Brompheniramine Maleate, 10 mg/mL injectable solution | Drug | Multum | Multum -45912144 | 1001 | Serum | Specimen | CIEL | Specimen +|概念ID | 概念コード | 概念名称 | ドメインID | 用語集ID | 概念クラス +|:--------- |:---- |:------------ |:---------- |:---------- |:---------- +|35803438 | 1001 | Granulocyte colony-stimulating factors | Drug | HemOnc | Component Class +|35942070 | 1001 | AJCC TNM Clin T | Measurement | NAACCR | NAACCR Variable +|1036059 | 1001 | Antipyrine | Drug | RxNorm | Ingredient +|38003544 | 1001 | Residential Treatment - Psychiatric | Revenue Code | Revenue Code | Revenue Code +|43228317 | 1001 | Aceprometazine maleate | Drug | BDPM | Ingredient +|45417187 | 1001 | Brompheniramine Maleate, 10 mg/mL injectable solution | Drug | Multum | Multum +|45912144 | 1001 | Serum | Specimen | CIEL | Specimen -### 수명 주기 {#conceptLifeCycle} +### Life-Cycle {#conceptLifeCycle} -용어집이 영원불변의 고정된 코드 세트인 경우는 드물다. 오히려, 코드와 concept이 더해지며 꾸준히 수정된다. OMOP CDM은 장기에 걸친 환자 데이터를 지원하기 위한 모델이므로, 과거에 사용되었지만, 지금은 더 이상 사용되지 않는 concept들을 지원해야 할 뿐 아니라, 신설된 concept을 더하여 상황에 맞게 지원해야 한다. CONCEPT 테이블에는 사용 가능한 수명 주기 상태를 설명하는 세 개의 필드가 있다: VALID_START_DATE, VALID_END_DATE, INVALID_REASON -그 값들은 각 concept의 수명 주기 상태에 따라 달라진다. +Vocabularies are rarely permanent corpora with a fixed set of codes. Instead, codes and concepts are added and get deprecated. The OMOP CDM is a model to support longitudinal patient data, which means it needs to support concepts that were used in the past and might no longer be active, as well as supporting new concepts and placing them into context. There are three fields in the CONCEPT table that describe the possible life-cycle statuses: VALID_START_DATE, VALID_END_DATE, and INVALID_REASON. Their values differ depending on the concept life-cycle status: -- **유효한 concept 및 새로운 concept** - - 설명: 사용 중인 concept. - - VALID_START_DATE: concept이 사용되기 시작한 날, 용어집에 concept을 통합한 날을 알지 못하거나, 알려지지 않은 경우 1970-1-1. - - VALID_END_DATE: "지금은 활성화되어 있으나, 추후에는 무효가 될 수가 있음."을 나타내는 규칙으로 2099-12-31을 설정. +用語集は、固定されたコードのセットを持つ永続的なコーパスであることはほとんどありません。その代わり、コードや概念は追加され、古いものは非推奨となります。OMOP CDMは縦断的な患者データをサポートするためのモデルであり、過去に使用されていた概念もサポートする必要があります。そして、新しい概念をサポートし、これまでのデータに対して適用する必要があることを意味しています。CONCEPTテーブルには、ライフサイクル・ステータスを記述する3つのフィールドがあります。VALID_START_DATE、VALID_END_DATE、INVALID_REASONです。これらの値は、概念のライフサイクル・ステータスによって変わります。 + +- **Active or new concept** + - 説明: 現在使用されている + - VALID_START_DATE: 概念のインスタンスが作成された日。用語集に当該概念が組み込まれた日が不明な場合は、1970-1-1を指定します。 + - VALID_END_DATE: 未定義の未来には無効になるかもしれないが、今は有効である "ことを示す慣例として、2099-12-31に設定します。 - INVALID_REASON: NULL -- **후속 코드 없이 더 이상 사용되지 않는 concept** - - 설명: concept이 비활성화 상태여서 표준으로 사용할 수 없다. (\@ref(standardConcepts)절 참조) - - VALID_START_DATE: concept이 사용되기 시작한 날, 용어집에 concept을 통합한 날을 알지 못하거나, 알려지지 않은 경우 1970-1-1. - - VALID_END_DATE: 사용 중단을 나타내는 과거의 날짜, 또는 해당 날짜를 알 수 없는 경우, concept이 누락되거나 비활성화된 용어집 갱신일 +- **Deprecated Concept with no successor** + - 説明: 概念は非アクティブであり、標準概念として使用することはできません(セクション\@ref(standardConcepts)参照). + - VALID_START_DATE: 概念のインスタンスが作成された日。用語集に当該概念が組み込まれた日が不明な場合は、1970-1-1を指定します。 + - VALID_END_DATE: 非推奨になった過去の日、不明な場合は用語集から当該概念が削除された、あるいは非アクティブに設定された時の用語集の更新日 - INVALID_REASON: "D" -- **후속 코드가 있는 업그레이드 된 concept** - - 설명: 비활성이지만, 후속 코드가 정의된 concept. 이들은 일반적으로 중복 제거를 통해 제거된 concept. - - VALID_START_DATE: concept이 사용되기 시작한 날, 용어집에 concept을 통합한 날을 알지 못하거나, 알려지지 않은 경우 1970-1-1. - - VALID_END_DATE: 업그레이드를 나타내는 과거의 날짜, 또는 해당 날짜를 알 수 없는 경우, 업그레이드가 추가된 용어집 갱신일 +- **Upgraded Concept with successor** + - 説明: 概念は非アクティブですが、後継者が定義されています。これらは典型的には重複排除が行われた概念です。 + - VALID_START_DATE: 概念のインスタンスが作成された日。用語集に当該概念が組み込まれた日が不明な場合は、1970-1-1を指定します。 + - VALID_END_DATE: アップグレードがあった過去の日付。不明な場合は当該概念がアップグレードされた概念が含まれた時の用語集の更新日 - INVALID_REASON: "U" -- **다른 새로운 concept에 대한 재사용 코드** - - 설명: 용어집은 새로운 concept을 위해 없어진 concept의 concept 코드를 재사용했다. - - VALID_START_DATE: concept이 사용되기 시작한 날, 용어집에 concept을 통합한 날을 알지 못하거나, 알려지지 않은 경우 1970-1-1. - - VALID_END_DATE: 사용 중단을 나타내는 과거의 날짜, 또는 해당 날짜를 알 수 없는 경우, concept이 누락되거나 비활성화로 설정된 용어집 갱신일 +- **Reused code for another new concept** + - 説明: この用語はこの非推奨概念の概念コードを新しい概念に再利用しました。 + - VALID_START_DATE: 概念のインスタンスが作成された日。用語集に当該概念が組み込まれた日が不明な場合は、1970-1-1を指定します。 + - VALID_END_DATE: 非推奨となった過去の日付。不明な場合は当該概念が削除されたか非アクティブに設定されたときの用語集の更新日 - INVALID_REASON: "R" - -일반적으로 concept 코드는 재사용하지 않는다. 하지만 이 규칙에서 벗어나는 몇몇 용어집으로 HCPCS, NDC, DRG가 있다. 그들 용어집에서는 동일한 concept 코드가 같은 용어집 내에서 하나 이상의 concept에 사용된다. 그들의 CONCEPT_ID 값은 고유값을 유지한다. 재사용된 concept 코드는 INVALID_REASON 필드에 "R"로 표시되며 VALID_START_DATE 부터 VALID_END_DATE 까지의 기간을 이용하여 concept 코드는 같지만 서로 다른 concept을 구별하는데 사용해야 한다. -## 관계 Relationships +一般に、概念コードは再利用されることはありません。しかし、この規則から逸脱したいくつかの用語集、特に HCPCS、NDC 及び DRG がある。これらの用語集では、同じ概念コードが同じ用語集の複数の概念に現れます。それらのCONCEPT_ID値は一意のままです。これらの再利用された概念コードはINVALID_REASONフィールドに "R "でマークされ、VALID_START_DATEからVALID_END_DATEまでの期間は、同じ概念コードを持つ概念から区別されるようにするべきです。 -두 concept이 동일한 도메인 또는 용어집에 속하는지 여부와 관계없이 두 concept은 지정된 관계를 맺을 수 있다. 관계의 특성은 CONCPET_RELATIONSHIP 테이블의 RELATIONSHIP_ID 필드에서 대소문자를 구분하는 고유한 짧은 영 숫자 ID로 표시한다. 각 관계에 대해서 전후가 바뀐 대칭 관계가 존재하며, CONCEPT_ID_1, CONCEPT_ID_2 필드의 내용이 교환되고, RELATIONSHIP_ID는 반대로 바뀌게 된다. 예를 들어, "Maps to" 관계는 "Mapped from"과 반대의 관계를 갖는다. \index{concept!relationship} +## Relationships + +とある2つの概念間において、2つの概念が同じドメインや用語集に属するかどうかに関係なく、関係を定義することができます。関係の性質は、CONCEPT_RELATIONSHIPテーブルのRELATIONSHIP_IDフィールドの短い大文字小文字を区別するユニークな英数字IDで指定されます。関係性は対称性があります。すなわち、各関係性に対して、CONCEPT_ID_1とCONCEPT_ID_2のフィールドの内容が入れ替わり、RELATIONSHIP_IDは反対の関係性のものにセットされます。例えば、"Maps to "関係性で定義された2つの概念は、順番を入れ替えて反対の関係性である "Mapped from "で定義されます。\index{concept!relationship} -CONCEPT_RELATIONSHIP 테이블 레코드에는 수명 주기 필드인 RELATIONSHIP_START_DATE, RELATIONSHIP_END_DATE, INVALID_REASON이 있다. 그러나, INVALID_REASON = NULL인 유효한 기록들만 ATHENA에서 이용할 수 있다. 비활성화된 관계는 Pallas 시스템 내에서 내부처리 용도로만 사용되도록 보관된다. RELATIONSHIP 테이블은 전체 relationship IDs 목록 및 그 반대의 목록과 함께 참조로 사용된다. + CONCEPT_RELATIONSHIPテーブルのレコードは、ライフサイクルのフィールドであるRELATIONSHIP_START_DATE、RELATIONSHIP_END_DATE、INVALID_REASONも持っています。しかし、ATHENAを通じて利用できるのは、INVALID_REASON = NULLを持つアクティブなレコードのみです。非アクティブな関係性は内部処理のためだけにPallasシステムに保持されます。RELATIONSHIPテーブルは、関係性IDの完全なリストとその逆の対応を持つリファレンスとして機能します。 -### 매핑 관계 Mapping Relationships {#conceptMapping} +### Mapping Relationships {#conceptMapping} -이러한 관계는 두 개의 relationship ID 쌍을 이용하여 비표준화 concept에서 표준concept으로 변환 하게 해준다. (표 \@ref(tab:mappingRelationships) 참조). \index{concept!mapping} +これらの関係性は、非標準概念から標準概念へのマッピングを提供し、2つの関係性IDのペアでサポートされています(表 \@ref(tab:mappingRelationships) 参照)。\index{concept!mapping} -Table: (\#tab:mappingRelationships) 매핑관계의 유형. +Table: (\#tab:mappingRelationships) マッピング関係性の種類 -Relationship ID pair | Purpose -:------------- | :---------------------------------------------------- -"Maps to" and "Mapped from" | 표준 concept에 매핑. 표준 concept은 자기 자신에게 매핑되고, 비표준 concept은 표준 concept으로 매핑된다. 대부분의 비표준 concept과 모든 표준 concept들은 한 표준 concept과 이러한 관계를 맺는다. 비표준 concept은 *_SOURCE_CONCEPT_ID에 저장되고 표준 concept은 * _CONCEPT_ID 필드에 저장된다. 분류 concept(Classification concepts)은 매핑되지 않는다. -"Maps to value" and "Value mapped from" | MEASUREMENT와 OBSERVATION 테이블의 VALUE_AS_CONCEPT_ID 필드에 배치할 값을 나타내는 concept에 Mapping. +|関係性IDペア | 目的 +|:------------- | :---------------------------------------------------- +|"Maps to" and "Mapped from" | 標準概念はそれ自身に、非標準概念は標準概念にマッピングされます。ほとんどの非標準概念とすべての標準概念は、標準概念とこの関係を持っています。前者は*_SOURCE_CONCEPT_IDフィールドに、後者は*_CONCEPT_IDフィールドに格納されます。分類概念はマッピングされません。 +|"Maps to value" and "Value mapped from" | MEASUREMENTテーブルおよびOBSERVATIONテーブルのVALUE_AS_CONCEPT_IDフィールドに配置される値を表す概念へのマッピング。 + -이러한 매핑 관계를 사용하는 목적은 같은 concept간의 교차를 통해 OMOP CDM에서 임상 사건이 표현되는 방식을 조화롭게 해주는 것이다. 이는 표준화된 용어들이 이루어 낸 주요 성과이다. +これらのマッピング関係性の目的は、OMOP CDM における臨床イベントの表現方法を調和させるために、等価な概念間のクロスウォークを可能にすることです。これは標準化用語集の主な成果です。 -"동등 concept(Equivalent concepts)"은 동일한 의미를 가지며, 중요한 것은 계층적으로 하위 concept(descendant)들이 동일한 의미론적 공간을 가진다. 동등concept을 사용할 수 없고, 그 concept이 표준이 아닌 경우, 그 concept은 약간 더 넓은 의미를 가진 concept으로 (소위, "uphill-mappings") 매핑된다. 예를 들어, ICD10CM W61.51 "Bitten by goose" 는 일반적으로 표준 condition concept에 사용되는 SNOMED 용어집에는 없다. 대신 SNOMED 217716004의 "Peck by bird"에 매핑되지만, 그 새가 거위라는 맥락을 잃게 된다. Up-hill 매핑은 정보가 유실돼도 표준 연구 사례들을 진행하는 데 문제없다고 간주할 때만 사용해야 한다. +"等価な概念 "とは、同じ意味を持つということです。重要なことは、階層的な子孫が同じ意味空間をカバーしていることを意味するということです。等価な概念が利用できず、その概念が標準化されていない場合でも、、少し広い概念にマッピング（いわゆる"up-hill"マッピング」）されます。例えば、ICD10CM W61.51 "Bitten by goose （ガチョウに噛まれた）"は、標準状態概念において一般的に使用されるSNOMED統制用語集には等価なものがありません。その代わりに、SNOMED 217716004 "Peck by bird (鳥につつかれた)"にマッピングされ、その鳥がガチョウであるという文脈が失われます。このような情報の損失が、標準的な研究のユースケースとは無関係であると考えられる場合にのみ、"up-hill"マッピングが使用されます。 -일부 매핑은 원천 concept을 둘 이상의 표준 concept에 연결한다. 예를 들어, ICD9CM의 070.43 "Hepatitis E with hepatic coma"는 SNOMED의 235867002 "Acute hepatitis E"뿐 아니라 SNOMED의 72836002 "Hepatic Coma" 에도 매핑되어 있다. 그 이유는 기존의 원천 concept이 간염 hepatitis와 혼스 coma라는 두 가지 조건의 선 조합 pre-coordinated이기 때문이다. SNOMED에는 해당 조합이 없음으로, ICD9CM 레코드에 기록된 두 개의 레코드 (각각 매핑된 표준 concept이 있는 레코드) 가 생성된다. +いくつかのマッピングは、ソース概念を複数の標準概念に接続します。例えば、ICD9CM 070.43 "Hepatitis E with hepatic coma (肝性昏睡を伴うE型肝炎)"は、SNOMED 235867002 "Acute hepatitis E (急性E型肝炎)"とSNOMED 72836002 "Hepatic Coma (肝性昏睡)"の両方にマッピングされています。その理由は、元々のソース概念が、肝炎と昏睡という2つの症状がプリコーディネートされた組み合わせだからです。SNOMED にはその組み合わせがないため、ICD9CM レコードには 2 つのレコードが書き込まれ、それぞれにマッピングされた標準概念が 1 つずつ書き込まれることになります。 -"Maps to value" 관계는 Entity-Attribute-Value(EAV) 모델에 따라 OMOP CDM 테이블의 값을 나누기 위한 목적이 있다. 일반적으로 다음과 같은 경우이다: +関係性 "値へのマップ("Maps to value") "は、実体-属性-値（EAV）モデルに従ったOMOP CDMテーブルの値の分割を目的としている。これは、以下のような状況で適用されます -- 테스트와 결과값으로 구성된 측정값 -- 개인 또는 가족의 질병력 -- 물질에 대한 알레르기 -- 예방접종 필요 +- 検査と結果値から構成される検査結果 +- 個人または家族の病歴 +- 物質へのアレルギー +- 予防接種の必要性 -이런 상황들에서 source concept은 속성(test or history)과 값(test result or disease)의 조합이다. "Maps to" 관계는 소스를 속성 concept에 매핑하고, "Maps to value" 관계는 value concept을 매핑한다. (예로 그림 \@ref(fig:conceptValue)참조) +これらの状況では、ソース概念は、属性（検査または履歴）と値（検査結果または疾患）の組み合わせです。ソース概念は、Maps to"関係によって属性概念に、"Maps to value"関係によって値概念にマッピングされます。例として図の\@ref(fig:conceptValue)を参照してください。 -```{r conceptValue, fig.cap='원천 concept과 표준 concept 사이의 일대다 매핑. 선 조합 pre-coordinated concept은 두 가지 concept으로 나뉘는데, 하나는 속성(여기서는 임상 소견의 과거력)과 다른 하나는 값(소화성 궤양 peptic ulcer)이다. "Maps to" 관계는 measurement 또는 observation 도메인에 매핑되는 반면, "Maps to value" concept에는 도메인 제한이 없다.',echo=FALSE, out.width='100%', fig.align='center'} +```{r conceptValue, fig.cap='ソース概念と標準概念の間の一対多のマッピング。プリコーディネートされた概念は2つの概念に分割され、1つは属性(ここでは臨床所見の履歴)で、もう1つは値(消化性潰瘍)です。"Maps to"関係は測定ドメインや観察ドメインの概念にマッピングしますが、"Maps to value"概念にはドメインの制限はありません。',echo=FALSE, out.width='100%', fig.align='center'} knitr::include_graphics("images/StandardizedVocabularies/conceptValue.png") -``` +``` -concept 매핑은 네트워크 연구를 수행하는 구성원들의 노력을 도와주는 지원과, 무료로 제공되는 OMOP 표준 용어집의 또 다른 핵심 기능이다. 매핑 관계는 외부 소스에서 파생되거나 용어팀에 의해 수작업으로 유지 관리된다. 이것은 용어팀이 완벽하지 않다는 것을 의미한다. 잘못되거나 이의가 있는 매핑 관계를 발견한 경우 [Forums](https://forums.ohdsi.org) 또는 [CDM issue](https://github.com/OHDSI/CommonDataModel/issues) 게시판을 통해 알려줘서 프로세스를 개선하도록 돕는 것이 중요하다. +概念のマッピングは、無料で提供される OMOP標準用語集の中心的な機能の一つであり、ネットワーク研究を行うコミュニティの取り組みを支援しています。関係性のマッピングは外部のソースから導き出されたものであるか、用語集のチームが手動で管理しています。完全とは言えませんので、間違った関係性のマッピングを発見した場合、[フォーラム] (https://forums.ohdsi.org) や [CDM issue] (https://github.com/OHDSI/CommonDataModel/issues) に投稿して、プロセスを改善するための手助けをしてください。 -매핑 규칙에 대한 자세한 설명은 OHDSI Wiki에서 확인할 수 있다. [^vocabMappingUrl] +マッピングの規約についてのより詳細な説明は OHDSI Wiki にあります。[^vocabMappingUrl] [^vocabMappingUrl]: https://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:mapping -### 계층적 관계 +### Hierarchical Relationships -계층을 나타내는 관계는 "Is a" – "Subsumes" 관계를 통해 정의된다. 계층적 관계는 자식 concept이 하나 이상의 추가 속성이나 더욱 정밀하게 정의된 속성에 더하여, 부모 concept의 모든 속성을 갖도록 정의된다. 예를 들어, SNOMED의 49436004 "심방세동 atrial fibrillation"은 "Is a" 관계를 통해 SNOMED의 17366009 "심방 부정맥 atrial arrhythmia"에 연결된다. 두 concept 모두 부정맥arrhythmia 형태를 제외하고 다른 속성은 동일하다, 즉, 한 concept에는 세동 fibrillation으로 정의되고, 다른 concept에서는 세동으로 정의되지 않는다. concept에는 둘 이상의 부모와 둘 이상의 자식 concept이 있을 수 있다. 이 예에서는, SNOMED의 49436004 "심방세동 atrial fibrillation"은 SNOMED의 40593004 "세동 fibrillation"과도 "Is-a" 관계를 가진다. \index{concept!hierarchy} +階層を示す関係は、"Is a"-"Subsumes"の関係性ペアによって定義されます。階層関係は、子概念が親概念のすべての属性に加えて、1 つ以上の追加属性またはより正確に定義された属性を持つように定義されます。例えば、SNOMED 49436004「心房細動」は、SNOMED 17366009「心房性不整脈」と「Is a」の関係で関連しています。両方の概念は、不整脈のタイプを除き、同じ属性を持っています。概念は、複数の親概念と複数の子概念を持つことができます。この例では、SNOMED 49436004 「心房細動」は、SNOMED 40593004 「細動」に対する "Is a "でもあります。\index{concept!hierarchy} -### 서로 다른 용어집에서 온 concept들 간의 관계 +### Relationships Between Concepts of Different Vocabularies -이들 관계는 일반적으로 "Vocabulary A – Vocabulary B equivalent"의 유형으로, 기존 용어집 소스에서 제공되거나, OHDSI 용어팀에 의해 구축된다. 그것들은 대략적인 매핑 역할을 할 수 있지만, 종종 잘 정리된 매핑보다는 관계의 정확도가 떨어진다. High-quality equivalence 관교 (예: Source – RxNorm equivalent) 는 항상 "Maps to" 관계에 의해 복제된다. +これらの関係は一般的に「用語A- 用語Bは同等である」というタイプのもので、原典の用語集から定義を提供されるか、OHDSI用語集チームが作成したものです。これらは近似的なマッピングの役割を果たしますが、多くの場合、より正確な関係性のマッピングよりも精度が低いことがあります。高品質の等価関係（例:"Source - RxNorm equivalent"）は常に"Maps to"関係として取り入れられます。 -### 동일 용어집 내 concept들 간의 관계 +### Relationships Between Concepts of the Same Vocabulary -한 용어집 내부의 관계는 일반적으로 용어집 제공자가 보급한다. 전체적인 설명은 OHDSI Wiki의 개별 용어집 아래의 용어집 설명서에서 찾을 수 있다. 이들 중 다수는 임상 사건 간의 관계를 정의하여 정보 검색에 이용될 수 있다. 예를 들어, 요도 장애 disorders of the urethra는 “finding site of” 관계를 따라가면 찾을 수 있다. (표 \@ref(tab:findingSite)참조) +内部の用語の関係性は、通常、用語集の提供者が提供しています。完全な説明は、OHDSI Wikiの個々の用語集に関するエントリーにある用語集のドキュメントを参照してください。[^vocabVocabulariesUrl] [^vocabVocabulariesUrl]: https://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary -Table: (\#tab:findingSite) "요도 urethra"의 "Finding site of" 관계는 해부학적 구조에 위치한 모든 조건을 나타낸다. +多くは臨床事象間の関係を定義しており，情報検索に利用できます．例えば、尿道の障害は、"Finding site of "の関係を辿ることで見つけることができます（表\@ref(tab:findingSite)参照）。 -CONCEPT_ID_1 | CONCEPT_ID_2 -:---------------- | :---------------------------- -4000504 "Urethra part" | 36713433 "Partial duplication of urethra" -4000504 "Urethra part" | 433583 "Epispadias" -4000504 "Urethra part" | 443533 "Epispadias, male" -4000504 "Urethra part" | 4005956 "Epispadias, female" +Table: (\#tab:findingSite) "Finding site of" relationship of "Urethra "の関係は、この解剖学的構造の中に全ての疾患が存在することを示しています + +|CONCEPT_ID_1 | CONCEPT_ID_2 +|:---------------- | :---------------------------- +|4000504 "尿道部" | 36713433 "尿道の部分重複" +|4000504 "尿道部" | 433583 "尿道上裂" +|4000504 "尿道部" | 443533 "尿道上裂, 男性" +|4000504 "尿道部" | 4005956 "尿道上裂, 女性" -이러한 관계의 품질과 포괄성은 기존 용어집의 질에 따라 다르다. 일반적으로, SNOMED와 같은 표준 concept을 도출하는데 사용되는 용어집은 자료 분류와 구조화를 더 잘해주기 때문에, 내부 관계의 품질을 높여주는 데 도움이 된다. +これらの関係性の定義の質や網羅性は、元の用語集の質によって異なります。一般的には、SNOMEDのように標準概念として利用するために使用されている用語集は、キュレーションが良いという理由で選ばれているため、内部の関係性の定義の質も高い傾向にあります。 -## 계층 Hierarchy {#conceptAncestor} -도메인 내에서 표준 및 분류 체계는 계층 구조로 구성되며, CONCEPT_ANCESTOR 테이블에 저장된다. 이를 통해 concepts과 모든 계층적 하위 항목을 쿼리로 검색할 수 있게 된다. 이 하위 항목들은 그들의 상위 항목과 같은 속성을 가지고 있지만, 추가로 정의된 것들도 있다. +## Hierarchy {#conceptAncestor} -계층적 관계를 통해 연결된 모든 가능한 concepts을 내포한 CONCEPT_RELATIONSHIP 테이블로부터 자동으로 CONCEPT_ANCESTOR 테이블이 생성된다. 이들은 "Is a" – "Subsumes" (그림 \@ref(fig:conceptAncestor) 참조), 또는 다른 종류의 관계를 서로 다른 용어집들 간에 계층화하여 연결한다. 한 관계가 계층 구조 생성자에 참여할 것 인가, 말 것인가의 선택은 RELATIONSHIP 참조 테이블의 DEFINIES_ANCESTRY라는 표시를 달아서 정의해준다. +ドメイン内では、標準概念と分類概念は階層構造に編成され、CONCEPT_ANCESTORテーブルに格納されます。これにより、概念とそのすべての階層的な子孫を検索したり、取得したりすることができます。これらの子孫は、その祖先と同じ属性を持っていますが、追加の属性や定義された属性も持っています。 -(ref:foo) "심방세동 atrial fibrillation" condition의 계층. First degree ancestry는 "Is a"와 "Subsumes" 관계를 통해 정의되며, 모든 higher degree 관계는 추론되고, CONCEPT_ANCESTOR 표에 저장된다. 각 concept은 분리 수준이 0인 자기 자신의 하위concept이다. \index{concept!ancestor} - +CONCEPT_ANCESTORテーブルは、CONCEPT_RELATIONSHIPテーブルから自動的に構築され、階層的な関係を介して接続されたすべての可能な概念を網羅します。これらは、"Is a" - "Subsumes "のペア（図\@ref(fig:conceptAncestor)参照）や、用語集を越えて階層的に接続された他の関係です。関係性が階層構造に参加するかどうかの選択は、各関係性IDについて、RELATIONSHIP参照テーブルのフラグDEFINES_ANCESTRYによって定義されます。 + +(ref:foo) 症状 "心房細動 "の階層。第一親等の先祖関係は "Is a "と "Subsumes "の関係によって定義され、すべての高次の関係は推論され、CONCEPT_ANCESTORテーブルに格納される。各概念は、両方のレベルの分離が0に等しい、それ自身の子孫でもあります。 \index{concept!ancestor} + ```{r conceptAncestor, fig.cap='(ref:foo)', echo=FALSE, out.width='100%', fig.align='center'} knitr::include_graphics("images/StandardizedVocabularies/conceptAncestor.png") -``` +``` -상위와 하위 항목 사이의 단계(step) 개수를 의미하는 ancestor degree는 MIN_LEVELS_OF_SEPARATION과 MAX_LEVELS_OF_SEPARATION으로 표현되고, 최단 또는 최장의 가능한 연결 정도를 정의해준다. 모든 계층적 관계가 분리 수준 계산에 동일하게 기여하는 것은 아니다. Degree를 구하기 위한 단계는 각 relationship ID에 대한 RELATIONSHIP 참조 테이블의 IS_HIERARCHICAL 표시 flag로 결정된다. +先祖の程度、つまり祖先と子孫の間のステップ数は、MIN_LEVELS_OF_SEPARATIONフィールドとMAX_LEVELS_OF_SEPARATIONフィールドで捕捉され、可能な限り最短または最長の接続を定義します。すべての階層関係が、分離レベルの計算に等しく寄与するわけではありません。程度のためにカウントされるステップは、各リレーションシップIDのRELATIONSHIP参照テーブルのIS_HIERARCHICALフラグによって決定されます。 -현재, 고품질의 포괄적인 계층구조는 drug와 condition 두 개의 도메인에만 존재한다. Procedure, measurement, observation 도메인은 부분적으로만 적용되며 현재 구축 중에 있다. 조상(ancestry) concept은 출처, 상품명 또는 다른 속성들과 무관하게 특정 성분이나 약물 등급의 구성원을 가지는 모든 약물을 탐색할 수 있기 때문에 특히 약물 도메인에서 유용하다. +現時点では、高品質な包括的階層が存在するのは、薬剤と状態の2つのドメインのみです。処置、検査、観察のドメインは部分的にしかカバーされておらず、構築中です。祖先に関する情報(ancestry)は、原産国、ブランド名、または他の属性に関係なく、与えられた成分を持つすべての薬剤または薬剤クラスのメンバーを閲覧できるので、薬剤ドメインでは特に有用です。 -## 내부 참조 테이블 +## Internal Reference Tables -DOMAIN_ID, VOCABULARY_ID, CONCEPT_CLASS_ID (셋 모두 CONCEPT 레코드안에 있는) 및 CONCEPT_RELATIONSHIP_ID (CONCEPT_RELATIONSHIP 안에 있는)는 모두 자체 용어집에 의해 제어된다. 이들은 4개의 참조 테이블인 DOMAIN, VOCABULARY, CONCEPT_CLASS 및 RELATIONSHIP에 정의되어 있으며, *_ID 필드를 primary keys로 하여 더욱 자세한 *_NAME 필드 및 *_CONCEPT_ID 필드를 포함하는 CONCEPT 테이블에 대한 참조가 포함된 4개의 참조 테이블에 정의되어 있다. 이들 중복 레코드들의 목적은 정보 모델이 자동 탐색 엔진을 허용하도록 지원하기 위한 것이다. +DOMAIN_ID、VOCABULARY_ID、CONCEPT_CLASS_ID(すべてCONCEPTレコード内)、CONCEPT_RELATIONSHIP_ID(CONCEPT_RELATIONSHIP内)はすべて独自の用語によって制御されます。これらは4つの参照テーブル DOMAIN, VOCABULARY, CONCEPT_CLASS, RELATIONSHIPで定義されており、主キーとしての*_IDフィールド、より詳細な*_NAMEフィールド、および参照テーブルレコードのそれぞれの概念を含むCONCEPTテーブルへの参照を持つ*_CONCEPT_IDフィールドを含んでいます。これらの重複レコードの目的は、自動ナビゲーション・エンジンを可能にする情報モデルをサポートすることにあります。 -VOCABULARY 테이블에는 기존 vocabulary의 source와 버전을 참조하는 VOCABULARY_REFERENCE 및 VOCABULARY_VERSION 필드가 포함되어 있다. RELATIONSHIP 테이블에는 추가 필드인 DEFINES_ANCESTRY, IS_HIERARCHICAL 및 REVERSE_RELATIONSHIP 필드가 있다. 후자는 한 쌍의 관계에 대해 반대의(counter) relationship ID를 정의한다. +また、VOCABULARYテーブルは、元の用語のソースとバージョンを参照するVOCABULARY_REFERENCEおよびVOCABULARY_VERSIONフィールドを含みます。RELATIONSHIPテーブルは、追加のフィールドDEFINES_ANCESTRY、IS_HIERARCHICAL、およびREVERSE_RELATIONSHIP_IDを有します。後者は、関係性のペアの反対の関係性を定義する関係性IDを定義します。 -## 특수 상황 {#specialSituations} +## Special Situations {#specialSituations} -### 성별 +### Gender -OMOP CDM 및 표준 용어집의 성별은 출생 시의 생물학적 성별을 나타내지만, 종종 양자택일하는 성별을 어떻게 정의하는지 의문이 제기된다. 이러한 사례들은 OBSERVATION 테이블의 레코드를 통하여 처리해야 하는데, 여기에 개인이 자체적으로 정의한 성별이 저장된다 (데이터 자산에 그런 정보가 포함된 경우). +OMOP CDM および標準用語集における性別は、出生時の生物学的性別を示す。しばしば、代替的な性別をどのように定義するかという質問が出てくる。これらのユースケースは、OBSERVATION テーブルのレコードでカバーしなければならず、（データ資産にそのような情報が含まれている場合には）人の自己定義の性別が格納される。 -### 인종과 민족 +### Race and Ethnicity -인종(race)과 민족(ethnicity)은 미국 정부가 지정한 정의를 따른다. 민족은 인종과 상관없이, Hispanic 또는 non-Hispanic 인구에서 분화된 세부 항목으로 구분한다. 인종은 공통적인 상위 5개 인종으로 나뉘며, 계층적 후손으로서 민족성을 가지고 있다. 혼혈 인종은 포함되지 않는다. +これらは、米国政府の定義に従っています。民族とは、ヒスパニック系か非ヒスパニック系かの区別であり、どのような人種でもよいです。人種は主な5つの上位人種で区分され、その階層的な子孫として民族を持つ。いわゆるハーフは含まれない。 -### 진단 코딩 체계 및 OMOP Conditions +### Diagnostic Coding Schemes and OMOP Conditions -ICD-9 또는 ICD-10과 같은 일반적으로 사용되는 코딩 체계는 적절한 진단 작업에 기반하여, 다소 잘 정의된 진단을 명시한다. condition 도메인은 의미론적 공간과 동일하지 않지만, 부분적으로 겹치는 부분이 있다. 예를 들어, conditions에는 진단이 도출되기 전에 기록된 징후와 증상도 포함되어있으며, ICD 코드에는 다른 도메인에 속하는 concept (예를 들어, procedures) 이 포함되어 있다. +ICD-9やICD-10のような一般的に使用されているコーディングスキームは、適切な診断ワークアップに基づいて、それなりに確定された診断群を定義しています。状態ドメインは、この意味空間と同一というわけではなく、部分的に重複しています。例えば、状態ドメインには、診断が導出される前に記録される徴候や症状も含まれておりますし、ICDコードには他のドメイン（例えば、処置）に属する概念が含まれていたりします。 -### 시술 코드 시스템 +### Procedure Coding Systems -마찬가지로, HCPCS 및 CTP4와 같은 코딩 체계는 의료 시술의 목록으로 간주한다. 실제로, 이 체계들은 의료비 지급 타당성을 선택하는 메뉴에 가깝다. 이러한 서비스의 많은 부분이 procedure 도메인 하에 포함되어 있지만, 많은 concept이 이 도메인 밖에 벗어나 있다. +同様に、HCPCSやCPT4のようなコーディングスキームは、医療処置のリストと考えられています。実際には、これらは医療サービスの支払いを正当化するためのメニューのようなものです。これらのサービスの多くは手技の領域に含まれていますが、多くの概念はこの領域から外れています。 -### 기기 +### Devices -기기 concept(Device concepts)은 원천 표준 concept에 사용될 수 있는 표준화된 코드 체계를 가지고 있지 않다. 많은 source 데이터에서 기기들은 코드화되어 있지 않고, 외부 코딩 체계에도 포함되지 않는다. 이와 같은 이유로, 현재 사용 가능한 계층 시스템이 없다. +デバイスの概念には、標準概念のソースに使用できる標準化されたコーディングスキームがありません。多くのソースデータでは、デバイスはコード化されていないか、外部コーディングスキームにすら含まれていません。同様に、現在利用可能な階層体系はありません。 -### 방문 및 서비스 +### Visits and Services -방문 concept은 의료 서비스의 성격을 정의한다. 많은 source system에서 병원과 같은 일부 기관이나, 물리적 구조를 나타내는 장소를 서비스 공간이라고 한다. 다른 곳에서는 서비스라고 한다. 방문 concept은 또한 국가마다 다르며, 정의하기 쉽지 않다. 진료 장소(Care sites)는 일반적으로 방문을 몇 번 했는지로 특정한다 (예를 들어, XYZ병원) 그러나 그 방문 숫자만으로는 정의하지는 않아야 한다. (예를 들어, XYZ병원에서 조차 환자들은 진료 목적이 아닌 방문을 할 수도 있기 때문이다) +来院(Visits)の概念は、医療機関における受療を定義する。多くのソースシステムでは、「医療サービスの提供場所」と呼ばれ、病院などの組織や物理的な構造物を意味する。他のシステムでは、サービスと呼ばれることもある。これらも国によって異なり、統一された定義を得るのは困難である。診療施設(Care site)は、多くの場合、数回来院した施設に集約させる（XYZ病院）が、それでも、それによって定義されるべきではない（XYZ病院の患者であっても、患者は当該病院外で受診することがあるかもしれない）。 -### 제공자 및 전문의 +### Providers and Specialties -모든 인간 제공자들은 provider 도메인에 정의되어 있다. 이 제공자들은 의사 및 간호사와 같은 의료 전문가일 수도 있지만, 검안사나, 신발 제조업자와 같은 비의료 서비스 제공자(non-medical provider)일 수도 있다. 전문의는 제공자인 "의사"(Physician)의 하위concept이다. Care sites는 전문성을 보유할 수 없으나, 주요 직원의 전문성에 의해 정의되는 경우가 많다 ("외과 Surgical department"). +医療従事者のドメインでは、あらゆる（人間の）医療従事者が定義されている。これらは、医師や看護師のような医療専門家だけでなく、検眼士や靴屋のような非医療専門家であってもよい。専門分野は、医療従事者である "Physician "の子孫である。診療施設は、主流を占める（例えば「外科部門」）の専門性によって定義されていることが多いが、専門性を持つことはできない。 -### 특별한 요구사항이 있는 치료 영역 -표준 용어들은 포괄적인 방식으로 의료의 모든 측면을 다루고 있다. 하지만, 일부 치료영역에서는 특별한 요구를 가지고 있으며, 특별한 용어집이 필요하다. 예로, 종양학, 방사선학, 유전체학 같은 것이다. Special OHDSI Working Groups은 이러한 확장 기능을 개발한다. 결과적으로, OMOP 표준 용어집은 통합 시스템을 구성하여 서로 다른 기원과 목적으로 생긴 concept들이 모두 동일한 도메인 특화 계층 내에 존재하게 된다. +### Therapeutic Areas With Special Requirements -### 약물 도메인 내의 표준 concept {#rxNormExtension} +標準化された用語集は、医療のあらゆる側面を包括的にカバーしています。しかし、一部の治療分野では特別なニーズがあり、特別な用語集が必要とされています。例として、腫瘍学、放射線学、ゲノミクスなどが挙げられます。特別な OHDSI ワーキンググループがこれらの拡張機能を開発しています。その結果、OMOP 標準語用語集は統合されたシステムを構成しており、異なる起源と目的を持つ概念がすべて同じドメイン固有の階層に存在しています。 -Drug 도메인의 많은 concept은 미국 국립 의학 도서관(National Library of Medicine)이 제공하는 용어집인 RxNorm에서 제공하고 있다. 하지만, 미국 외 지역의 의약품은 미국에서 시판되는 성분, 형태, 강도의 조합 인지에 따라 다뤄지거나 다뤄지지 않을 수도 있다. 미국 시장에 없는 약물은 OHDSI 용어팀에 의해 [RxNorm 확장판, RxNorm Extension](https://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:rxnorm_extension)이라는 용어집으로 추가되며, 이것은 OHDSI에 의해 유일하게 생성된 큰 도메인 용어집이다. +### Standard Concepts in the Drug Domain {#rxNormExtension} -### NULL의 특색 +医薬品ドメインの多くの概念は、米国国立医学図書館が作成した一般に公開されている用語集であるRxNormから出典を得ています。しかし、米国外の医薬品は、成分、形態、強度の組み合わせが米国で販売されているかどうかによって、対象となる場合と対象とならない場合があります。米国市場に出回っていない薬剤は、OHDSI語彙チームが[RxNorm Extension](https://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:rxnorm_extension)と呼ばれる語彙の下に追加しており、これはOHDSIが作成した唯一の大きなドメイン用語集です。 -많은 용어집에는 정보가 없는 코드들을 포함하고 있다. 예를 들어, 5개의 성별 concept인 8507 "Male", 8532 "Female", 8570 "Ambiguous", 8551 "Unknown", 8521 "기타" 중 앞의 2개인 8507 "Male", 8532 "Female"만 표준이며, 나머지 3개는 매핑이 되어있지 않은 source concepts이다. 표준 용어집에서는 왜 정보가 없는지에 대한 구분은 없다. 환자가 정보를 철회하거나, 결측값, 정의되지 않거나 표준화되지 않은 값 때문일 수도 있으며 COCEPT_RELATIONSHIP에 매핑 레코드가 없는 경우 일 수도 있다. 이러한 concept은 매핑되지 않으며, 이는 concept ID = 0인 표준 concept 기본 매핑에 해당한다. +### Flavors of NULL -## 요약 +多くの用語集には、情報の不在に関するコードが含まれています。例えば、5つの性別を表す概念、8507「男性」、8532「女性」、8570「曖昧」、8551「不明」、および8521「その他」のうち、最初の2つだけが標準であり、他の3つはマッピングのないソース概念です。それは、患者による情報の撤回によるもの、値の欠落、何らかの方法で定義されていないか、標準化されていない値、またはCONCEPT_RELATIONSHIPにマッピングレコードがないためかもしれません。そのような概念はマッピングされず、'概念ID=0'の標準概念へのデフォルトマッピングに対応します。 -```{block2, type='rmdsummary'} -- 모든 이벤트 및 관리되는 사건은 OMOP 표준 용어집에 concept, concept 관계 및 concept 상위 계층으로 표현된다. -- 이 중 대부분은 기존의 코딩 체계나 용어집에서 채택해지만, 일부는 OHDSI 용어팀에서 새로 선별했다. -- 모든 concept은 한 개의 도메인을 가지는데, 그런데 그 도메인은 concept으로 표현되는 그 사건이 CDM의 어떤 테이블에 저장될 지를 결정한다. -- 다른 용어집에서 동등한 의미가 있는 concept들은 그중 하나에 매칭되는데, 그것이 표준concept으로 지정된 concept이다. 다른 concept들은 원천 concept들이다. -- 매핑은 "Maps to"와 "Maps to value" concept relationships을 통해 수행된다. -- 분류 concept이라 불리는 추가 concept 계층이 있는데, 이는 비표준이지만, 원천 concept과 달리 계층으로 존재한다. 비표준인, 분류 concept이라고 불리는 추가적인 concepts class가 있다. 하지만, source concepts과는 다르게 계층으로 존재한다. -- concept은 시간이 지남에 따라 수명 주기(life-cycle)를 갖는다. -- 도메인 내의 concept은 계층으로 구성된다. 계층구조의 품질은 도메인마다 상이하며, 계층 구조 시스템의 완성을 위해 아직 진행 중이다. -- 실수나, 오류를 발견한 경우 커뮤니티에 참여할 것을 적극적으로 권장한다. +## Summary +```{block2, type='rmdsummary'} +- OMOP 標準用語集では、すべての事象や管理上の事実が概念、概念関係、概念の祖先階層として表現されています。 +- ほとんどは既存のコーディングスキームや用語集から採用されていますが、OHDSI用語集チームによって一から開発されているものもあります。 +- すべての概念にはドメインが割り当てられています。これは概念によって表現された事実が CDM のどこに格納されるかを制御するものです。 +- 異なる用語集で同等の意味を持つ概念は、そのうちの1つにマッピングされ、標準概念に指定されます。それ以外のものはソース概念となります。 +- 「Maps to」と「Maps to value」という概念間の関係性を用いてマッピングが行われます。 +- 分類概念と呼ばれる概念の追加クラスがあります。これは非標準ですが、ソース概念とは違って概念階層の構成に参加します。 +- 概念には、時間の経過とともにライフサイクルがあります。 +- ドメイン内の概念は、階層に編成されます。階層の質はドメインごとに異なり、階層体系の作り込みは継続的な作業です。 +- 間違いや不正確な点を発見したと思われる場合は、コミュニティに参加することを強くお勧めします。 ``` -## 예제 +## Exercises -#### 전제조건 {-} +#### Prerequisites {-} -첫 연습에서는, ATHENA[^athenaCdm2Url] 또는 ATLAS[^atlasCdm2Url]를 이용해서 표준용어집 내에서 -concept을 찾아 볼 필요가 있다. +最初の演習では、ATHENA[^athenaCdm2Url] やATLAS[^atlasCdm2Url]を使って標準語彙集の概念を調べます。 [^athenaCdm2Url]: http://athena.ohdsi.org/ [^atlasCdm2Url]: http://atlas-demo.ohdsi.org ```{exercise, exerciseVocab1} -"위장관 출혈 gastrointestinal hemorrhage"에 대한 Standard Concept ID는 무엇인가? +「消化管出血」の標準概念IDは？ ``` ```{exercise, exerciseVocab2} -"위장관 출혈 gastrointestinal hemorrhage"에 대한 Standard Concept에 어떤 ICD-10CM 코드가 매핑되는가? 이 Standard Concept에 어떤 ICD-9CM 코드가 매핑되는가? +「消化管出血」の標準概念に対応する ICD-10CM コードはどれか？どのICD-9CMコードがこの標準概念に対応するか？ + ``` ```{exercise, exerciseVocab3} -"위장관 출혈 gastrointestinal hemorrhage"에 대한 Standard concept에 해당하는 MedDRA 선호 용어는 무엇인가? - -``` +消化管出血の標準概念に相当する MedDRAの優先用語は何か？ +``` -제시된 답변은 부록 \@ref(Vocabanswers)에서 찾을 수 있다. +回答はAppendix \@ref(Vocabanswers)で確認できます。