openEHR入門

openEHR入門 京都大学EHR共同研究講座 小林慎治

Agenda • Semantic interoperabilityと標準 • 臨床情報モデルとは • openEHRとは • ISO 13606, Archetypeについて • 臨床情報モデル設計の実際について

相互運用性(Interoperability) • Foundational（基礎的) interoperability – データをシステム間で受け渡すことができる – 受け取ったデータを解釈できなくてもよい • Structural (構造的) interoperability – システム間で構造化されたデータを受け渡すことが できる。 – 共通の構造、文法を定義しておく必要がある • Semantic(意味論的) interoperability – システム間で構造および語彙について定義された データを受け渡すことができる

臨床情報モデルとは • 情報モデルとは、概念や関係性、制約やルー ルと特定の領域におけるセマンティクス（意味 論）を特定する作業のことである[1]。 • 臨床情報モデルとは、医療分野における概 念について、共有可能なセマンティクス、制約、 ルール、関係性について機械可読可能なよう に定義したものである。 1) Y. Tina Lee (1999). "Information modeling from design to implementation" National Institute of Standards and Technology.

• http://www.mel.nist.gov/msidlibrary/doc/tina99im.pdf

臨床情報モデルの構成 • 用語（ターミノロジー） – 病名、解剖学的位置、薬剤、検査名、有害事象 • ICD10、JLAC10, LOINC, SNOMED-CT, MEDRA/CTCAE – タキソノミー、オントロジー • データ構造 – 階層化、正規化 – UML

用語だけでは不明瞭 SNOMED-CTの例 右上肢と左下肢の感覚麻痺 • 感覚麻痺(44077006) • 右(24028007) • 上肢(40983000) • 左(7771000) • 下肢(30021000) 左上肢と右下肢の感覚麻痺 • • • • • 感覚麻痺(44077006) 左(7771000) 上肢(40983000) 右(24028007) 下肢(30021000) Stan Huff, Practical Modeling Issues: Representing Coded and Structured Patient Data in EHR Systems, AMIA 2014, Washington D.C., USA

表現のブレ • 1つの項目名（コード）と値 – Dry weight = 70kg • 2つの項目名（コード）と値 – Weight = 70kg • Weight type = “Dry” Stan Huff, Practical Modeling Issues: Representing Coded and Structured Patient Data in EHR Systems, AMIA 2014, Washington D.C., USA

情報モデルのズレ(XML) • 未調整のデータ表現(項目名1の場合） <observation> <cd>Dry weight(LOINC 8340-2) </cd> <value>70kg</value> </observation> • 調整されたデータ表現（項目名2の場合） <observation> <cd >Weight(LOINC 3141-9) </cd> <qualifier> <cd>Weight type(LOINC 8337-8)</cd> <value>Dry(SNOMED-CT 13880007)</value> </qualifier> <value>70kg</value> </observation>

例：肺がんの疑い 診療所A 病院B外来 病院C入院 診断名 診断： がん 診断名 診断名 診断： がん疑 部位： 肺 診断： 肺がん疑 部位： 肺 状態： ◎疑い ○確定 ○未検 OK キャンセル OK キャンセル OK Linda Bird によるISO-Semantic modelの例、日本語訳 キャンセル

モデル階層 診断 診断病名 モデルのズレ 診療所A 病院B外来 病院C入院 がん がんの疑い 肺がんの疑い 肺 肺 詳細部位 身体部位 左右の別 診断過程 現時点での状態 対象との関係 疑い

臨床情報モデル

臨床情報モデルの役割 • 医療従事者間で共有される情報単位 – 血圧、脈拍、体重 – 帳票、伝票、見出し • 機械的情報処理 – 単数あるいは複数の用語から構成される • 用語、構造、形式を標準化 – コードへの置き換え • 知識共有基盤 – EHRの情報単位、知識ベース、標準

医療情報標準規格 交換プロトコル IHE HL7 メッセージ形式 MML ISO 13606 openEHR 臨床情報モデル SNOMED-CT 用語 ICD-10 厚生労働省マスタ

MML Stan Huff, Designing of international collaboration for clinical information modeling, Seminar “Design of clinical models and standards”, May 23 2014, Kyoto Japan

openEHRとは

openEHRとは何か • 標準的健康情報モデルを開発する団体 • 健康情報モデルについての公開された仕様 – オープンなエコシステムを支援することができる • ベンダー中立（依存しない） • 技術的中立（依存しない） – 資料や参照実装がApache 2/CC-BY-SAライセンス で提供されているためオープンソースビジネス、 クローズドソースビジネスのどちらでも利用するこ とができる。

openEHRへの誤解 • オープンソースの医療ソフトウェアではない • ダウンロードしてすぐに使えるアプリケーショ ンではない • 特定のベンダーによる専有物ではない • 営利組織による私有物ではない • 営利目的で使用できないというわけではない

openEHRが提供しているもの • 政府・行政のために – ベンダー中立で、国家レベルまでスケーラブルな EHRシステム／ヘルスケアデータリポジトリ • 疫学研究のために – 質の高いヘルスケアデータ • 開発者のために – 入念に設計されたEHR仕様と臨床情報モデル • 臨床家のために – 再利用可能な情報モデル

Health Computing Platform app app Service API Service API Interfaces, Information and Meaning 4. Standard Service API Service API Service API interfaces Service API Service API B2B Service API B2B Service API other system B2B Service API 5. Semantic Querying 2. Standard content definitions 1. Standard Information model 3. Open terminologies Copyright 2015 openEHR Thomas Beale, 千年カルテシンポジウ ム、2017、東京

ISO/EN 13606: EHR Communication standard • Part 1: Reference Model(参照モデル） • comprehensive, generic model for communicating part or all of an EHR • constraint-based approach for defining clinical “business objects” that are built from the Reference Model - adopted from openEHR • Part 2: Archetype Specification（アーキタイプ仕様) • Part 3: Reference Archetypes and Term Lists • • initial set of archetypes mapping to other relevant standards • measures to support access control, consent and auditability of EHR communications vocabularies for the Part 1 model • Part 4: Security • Part 5: Interface specification • message and service interfaces to enable EHR and archetype communication Dipak Kalra, 日本医療情報学連合大会2010

研究と相互運用性標準 EU and Australian R&D projects EHR quality and interoperability requirements EHR reference models 1995 pre-standard Early archetype approach 1999 pre-standard Richer EHR models 2007-9 ISO/EN 13606 Archetype formalism and tools Archetype authorship and governance Open source reference implementations Ongoing evaluation & refinement + implementation guide Dipak Kalra, 日本医療情報学連合大会2010

ISO13606とopenEHR • 標準（ISO 13606) – 標準化団体による3カ月ごとの会議 – 学会，産業界のリーダー – 過去の作業をベースに理論的に構成される – 政治的プロセスにより決定 • 仕様(openEHR) – インターネット上でコミュニティベースで議論，開発が おこなわれる – 実装試験 – エキスパートにより変更要求と承認がおこなわれる

EHRのための論理モデル（ISO/TR 20514） • ISO/EN 13606 • 最も単純であるが、すべての要件を満たすEHR参照モデル。 • 多様な旧来のシステム間での相互運用にも適している。 • EHR通信における世界標準 • openEHR • 最も充実したEHRアーキテクチャ仕様であり、わかりやすい • • EHRを構築するために最適である。 技術的に検証された仕様が公開されている。 ISO 13606に完全に準拠しつつ拡張を加えている • どちらもArchetypeを使っている • どちらも世界中で実装されつつある

まとめ：The openEHR Project • 医療情報モデルの標準仕様を規定する – 実働するアプリケーションプロジェクトではない – openEHRベースで稼働するEHRシステムは多数開発 されている • 医療情報モデルを開発している – Web上のツール、Clinical Knowledge Managerで公開 の元で議論し開発が進められている • 国際的プロジェクト – 約50カ国から参加していて、各国へのローカライズが 進められている

openEHRのアーキテクチャ • 参照(Reference)モデル – データ型、データ構造 • Text, Quantity, Date, Time DateTime – EHRを構成するパーツ • バージョニング、セキュリティ、識別子（ID) • アーキタイプ(Archetype)モデル – 臨床概念モデル • 医療従事者で同意がとれるもの – 参照モデルで構築されるls

2段階モデリング Ian McNil, MEDINFO 2015, Sao Paolo

2段階モデリング ドメイン固有の概念モデルとデータモデルを分離 The openEHR architecture overview

Template, Archetype Sam Heard, EHR標準ISO13606 and openEHR, 第28回医療情報学連合大会2008

What is openEHR organisationally? 1. A set of managed specifications Thomas Beale, 千年カルテシンポジウ ム、2017、東京 Copyright openEHR Foundation Copyright 2014 2014 openEHR Foundation

参照モデル • 一般的なデータモデル – データ型 • テキスト、数量、日付、時刻 – データ構造 • 木、リスト、表 • 階層的データ構造 – 一個人の生涯にわたる健康情報、1回の入院での患者 データ、検査レポート、一つの処置、検査 • EHRを構成する要素技術 – セキュリティ、バージョン管理、識別子(ID) – 特定の技術に依存しない • RDBMS, XML, JSON

参照モデル(Reference model) • 健康に関する記録を扱うためのすべての属性を表現 するための包括的な構造を提供する – Archetypeを構成するクラスと属性 • OBSERVATIONなど – 構造 • リストなど – データ型 – その他 • Archetypeを表現するために利用されるが、ツールで 隠蔽されている – 臨床情報モデルを構築するときは臨床情報に集中するこ と！

Part 1 - Reference Model EHR_EXTRACT RECORD_COMPONENT all_compositions folders 0..* 0..* COMPOSITION rc_id compositions FOLDER 0..* 0..* sub-folders content CONTENT 0..* ENTRY members 0..* items SECTION 0..* parts ITEM 0..* CLUSTER ELEMENT 0..1 value DATA_VALUE

33 参照モデルのクラス クラス 特徴 下位クラス 設計上必要 Composition Context; Participations Sections Entries Strict Sections Entries Not required Clusters Elements Strict Section Entry Participations • Observation • Evaluation • Instruction • Action = 経過モデル、プロトコール、状態 = 評価と要約 = 指示 = 実施とステートモデル Cluster © Ocean Informatics 2009 (Structures) (Structures) Clusters Elements Strict

参照モデル階層 EHR Folders 1個人の電子健康記録 EHRの中での上位構造 例：専門科ごとの診療記録 Compositions 一連の医療行為や文書を表すエントリ型の集合 Sections ワークフローやコンサルト，診断の過程，診療行 為に関連する見出し項目。例：SOAP Entries 診療概念の表現（statement) 観察，評価，指示，行為 Clusters データを複数まとめたもの 例：解剖学的位置，TNM分類 Elements 診療概念を構成する値 Data values 例：検査レポート，臨床個人調査票 例：受診理由，体重 データ型，値 例：用語コード，単位と値 © Ocean Informatics 2009

EHR, FOLDERの図 FOLDER EHR

「紹介状」の概念構成 • 紹介状様式 • 個人情報 • 医療機関情報 • 見出し情報 • 内容： – 紹介目的 – 病歴 – 治療経過 – 処方箋

紹介状のアーキタイプ構成 • 紹介状様式:COMPOSITION • 個人情報:DEMOGRAPHIC • 医療機関情報 • 見出し情報:SECTION • 内容： – – – – openEHR-EHR-COMPOSITION.refferral openEHR-DEMOGRAPHIC.personal openEHR-EHRCLUSTER.professional_individual openEHR-EHR-SECTION.refferal – 紹介目的 – 病歴 – 治療経過 – 処方箋 • • • • openEHR-EHREVALUATION.reason_for_encounter openEHR-EHR-OBSERVATION.story openEHR-EHR-EVALUATION.clinical_synopsis openEHR-EHR-ACTION.medication.order

COMPOSITION • 「コンテナ」クラス – openEHRの参照モデルをすべて組み込むことができる。 • 記録の最小単位 – COMPOSITIONより小さい単位では記録としては扱われな い • 帳票、伝票、画面に相当 – 変更・修正は新しいバージョンとして管理される • 法的根拠となりうる記録を扱う – いつ、誰が、何を – 電子署名、あるいは電子監査 – 参加者

COMPOSITION2 • 見出し情報をSECTIONで定義することができる – どの見出し項目を扱うかはSECTIONクラスを指定する ことが一般的 • ContextとContent情報を扱う – Context(文脈情報) • 直接的には健康に関係しない情報 – 例：帳票種別、記載者など – Content(内容情報) • SECTION, ENTRY以下、直接健康に関する情報 – 例：SOAPなどの見出し、血圧、検査結果、処方内容など

「紹介状」のSECTION部分 • 各見出し項目 – 傷病名 – 紹介目的 – 受信経過・検査結果・治 療経過 – 現在の処方 – 備考 • 個別の内容は含まない。 – 個別の内容を記録する アーキタイプを組み込む ためのスロットを用意

SECTION • 見出し項目でCOMPOSITION以下に組み込ま れる参照モデルを構造化する – COMPOSITION以下の情報の構造を標準化する – 見出しを付けることで人間にとってわかりやすく する – SECTIONの例 • SOAP • 身体所見：系統的に入力。「頭頚部、胸腹部..」 • 病歴：「現病歴、既往歴、家族歴」など

「紹介状」のENTRY部分 • 各見出しの内容 – 傷病名 – 紹介目的 – 既往歴・家族歴 – 受信経過・検査結果・治 療経過 – 現在の処方 – 備考

ENTRY • ENTRYは情報の「意味単位」 – 個々の「診療記録」を対象とする – ENTRYが表す情報は、どのような状況であっても同じもの を指す。 • これがopenEHRアーキテクチャ設計の基本的な特徴である。 – ENTRYの例 • 血圧：全身の動脈血圧 • 血管内圧：血管系のどこかの部位での圧 • 体重：全身の重量 • 心電図計測 • 脈拍 • 薬剤 • 診断

Entry型 measurable or observable Published evidence base Observations Domain Expert Personal knowledge base 1 Time/Event series; State 5 2 Evaluation clinically interpreted OR Persistent Summary findings Admin Entry order or initiation of a workflow process 3 Instructions © Ocean Informatics 2009 Subject 4 Actions Recording each activity Investigator’s agents

「血圧」のArchetype

参照モデルとアーキタイプ • アーキタイプは参照モデル で構成される – 参照モデル：OBSERVATIONと 「血圧」アーキタイプ • アーキタイプを元に参照モ デルのインスタンスが生成 される – 血圧アーキタイプから、 OBSERVATIONクラスのインス タンスが導出され、血圧デー タを格納される OBSERVATION Blood pressure

Archetypeの役割 • 情報を共有するベースとしての概念モデル – 幅広く共有できる • 最大セット – 機械処理ができる – 専門家による合議のもとで形成される • 情報についての制約と検証 – データ型（文字列、数値、日付など） – データの範囲（収縮期血圧は0以上、1000以下）

openEHR: Templates • TemplateはArchetypeを組み合わせ てデータセットを構成する • 実世界のデータセットを表現す る • • たとえば、「バイタルサイ ンの入力画面」、「退院サ マリー」、「緩和ケアプラ ン」 臨床上重要なエンドポイントやス タートポイントについて技術的に 作成することができる Ian McNil, MEDINFO 2015, Sao Paolo

各モデルの比較  参照モデル（Reference Model ）– 堅牢  Archetype – 安定、固定  Template – 柔軟+++++++  Reference Model は設計の基本となる  Reference Model は archetype を構成する  Archetypes は Templateを構成する

Archetype/Templateのまとめ • Reference model – データ型や構造、メタ臨床モデル • Archetype – 医療記録のパーツとしての臨床概念モデル – どのような場面でも利用できるように「最大データセッ ト」で構築される – 参照モデルを使って構築される • Template – 実際のユースケースに応じた医療記録 – Archetypeの組み合わせで表現される

Archetypeの設計

Archetypeの役割 • 情報を共有するベースとしての概念モデル – 幅広く共有できる • 最大セット – 正確に情報を記録することができる – 専門家による合議のもとで形成される • 情報についての制約と検証 – データ型（文字列、数値、日付など） – データの範囲（収縮期血圧は0以上、1000以下）

よいArchetypeとは • 要件 – ○最大データセット – ×必要最低限データセット • アーキタイプは個別の臨床概念に対応して臨 床家が想定するすべての項目を網羅するの が望ましい – 同じアーキタイプを多様な場面で利用するため

設計手順 1. 対象となる臨床概念を調査する 2. 既存のArchetypeがないか検索する – Clinical Knowledge Manager 3. 概念が示す内容を集める 4. 集められた内容を構造化する 5. どの参照モデルに相当するか検討する 6. Archetype Editorで内容を定義する

1.対象となる臨床概念を調査する • すべての臨床概念を同定する – 対象となる実施記録や業務について調査する • 一つの臨床概念（たとえば体重）なのか • 複数の臨床概念で構成されるのか • Mindmapを作成しよう – 複雑な概念を明確にすることができる – 個別の概念を同定することに役立つ – 重複した概念を整理することに役立つ

2.既存のArchetypeがないか検索 • Archetype repository – The openEHR clinical knowledge manager • http://www.openehr.org/ckm/ • 見つかった場合 – そのArchetypeが目的とする項目をすべて網羅してい るかどうか • 網羅している場合 → そのまま使う • 網羅していない場合 → 修正あるいは追加する • 見つからなかった場合 – 新しいArchetypeを作成する

• http://www.openehr.org/ckm/

Clinical Knowledge manager http://www.openehr.org/ckm/

• http://www.openehr.org/ckm/

新しいArchetypeを設計する 3. 4. 5. 6. 概念が示す内容を集める 集められた内容を構造化する どの参照モデルに相当するか検討する Archetype Editorで内容を定義する a. b. c. d. e. f. Archetypeを命名する 構造を決定する データ型を追加する 制約を加える メタデータを書き加える ターミノロジーを指定する 7. 共同作業のために公開 8. テンプレートに加える

3a 概念が示す内容を集める • ブレインストーミング • 臨床概念を多角的に検討する – 誰が？何を？どこで？いつ？どのように？ – 最大／最小 – 正常／異常 – 単純／複雑 – 合併症？ – 包含条件、除外条件 – などなど

3b 診療記録から情報を集める • どのように臨床家が記録しているか考える – 叙述的(Narrative)か構造化されているか – 正常の表現 – “特記事項なし” –図 – 画像・マルチメディア – ターミノロジーとの対応、どの用語がターミノロジーにひも 付けが必要か • 臨床家によって好みの記録方法が分かれる • 求められる詳細さが異なる。 – いわゆる2号用紙診療記録（フリーテキストとして） vs 構造 化された詳細な診療記録

3c いろいろな情報源からデータを集 める • 何を今使っているのか？「車輪の再発明」を避ける – 帳票 – アプリケーションなど • 最低限のデータセット – 国、県、市町村 – 特化(Specialised)されたデータ – 報告書、カルテ • インターネット – 世界的、ローカル – 似たようなプロジェクトがないか • 先行研究 – 教科書・論文

3d さまざまな専門家から情報を集め る • 医師 • 看護師 • コメディカルスタッフ • 歯科医師 • 研究者 • 公衆衛生担当者 • 臨床決定支援システム開発者 • Personal health record • 医療機器開発者

4. 集められた内容を構造化する • Mindmapを作成する • 以下のものを特定する – 目的 • コンテナあるいは見出しとして – 文脈 – データ項目 – Protocol（方法） – Statas（状態） • データ解釈のための文脈として – 起こりうるイベント – 状態遷移ステップ – ターミノロジーが必要な概念

5. どの参照モデルに相当するか検討 する • COMPOSITION – 文書のコンテナ • SECTION – レイアウト、見出し項目 • ENTRY – 臨床表現、制約、意味 • CLUSTER – 再利用可能なパーツ

6. Archetype Editorで内容を定義する • • • • • • Archetypeを命名する 構造を決定する データ型を追加する 制約を加える メタデータを書き加える ターミノロジーを指定する

診療における情報の流れ 観察 公知のエビデ ンス 医師 1 患者 4 個人の知識と 経験 実施 2 評価 3 指示 コメディカル スタッフ

Entry

ENTRYのオントロジー

Entryのクラス図

Entry型の特徴 特徴 Eval Obs Subject �� � � � �� � � � � � - 対象となるのは誰か Protocol - 記録された方法 History - 時系列 State - 記録時の状態 Pathway - 状態遷移 © Ocean Informatics 2009 Inst Act Adm

EVALUATION • ENTRYの「Default」 • 評価、意見、目標あるいは臨床的に解釈された所見 – 臨床家によって生成される情報 – 直接観察された他の情報に対する臨床上の推定や評価 – 「これらの事実を元にした私の意見では、この患者の病名は ○○、■■といったリスクがあり」 • History/Eventモデルは必要とならない – ある特定の時点での評価であって、経時的に記録する必要は 無い – 経時的記録データに対する評価であっても評価が経時的であ るということではない – 経時的な記録の中間評価というのは論理的ではない（評価は それ以前の事象に対して行うため）

OBSERVATION • 直接観察された情報 – 直接計測されたもの – 患者の病歴 – 病歴など固定された情報、事実についての表現 • History/Eventモデルが必要 – 経時的記録を伴うため – 複数回の連続した情報を記録することができる – 中間記録というのはある程度意味がある • Stateモデルが必要 – どのような状態で観察されたかを記録するため • Protocolモデルも必要 – どのような方法で記録されたかという情報を記録するため • 臨床家の「意見」は含まれない

OBSERVATION vs EVALUATION • OBSERVATION – 血圧 – 検査結果 – アプガースコア • EVALUATION – 副作用 – 診断 – 危険因子（家族歴、生活歴など）

「血圧」のArchetype at0004 – DV_QUANTITY at0005– DV_QUANTITY at0000 - concept name

INSTRUCTION/ACTION • • • • INSTRUCTION = 指示、オーダー ACTION = (逐次的)実施記録 Instruction ≈ Action(必ず一致するとは限らない) 2つのパターン – 組み込まれたデータ構造とデータエレメントを共有する • 例:内服処方箋、薬剤払い出し記録、内服記録 – INSTRUCTIONとACTIONでデータが分かれる • 例：注射処方箋、注射実施記録 • 複雑なINSTRUCTION/ACTION(例：硬膜外麻酔） – 複数の構造体で一つのINSTRUCTIONを構成する必要がある。 • 例：一つのINSTRUCTIONに、薬剤処方と処置のArchetypeを組み込む – 各実施記録は実施された状態とともに、それぞれ個別のACTIONに組 み込まれる（ただし、Linkとして） • 例：処置は完了したが、投薬は未実施

Action State Model © Ocean Informatics 2009

Medication Order : Pathways © Ocean Informatics 2009

CLUSTER/ELEMENT • CLUSTERとELEMENTでツリー構造を作る • 複数のENTRYに組み込むことができる – 再利用可能な情報パーツを構築 – 例：解剖学的位置、薬剤組成、TNM分類、身体所見 • 詳細な情報を分離することでENTRYクラスをシンプルに構 成することができる – 例:症状(Symptom)アーキタイプに組み込んで利用する頭痛 CLUSTER(光線過敏や吐き気といった項目を含む) • 基本的な臨床項目は再利用されるのでこの分類となるこ とが多い – 理学的所見：大きさ、形、位置、正常、周辺、温度、表面など。 これらの情報はいろいろな理学的所見や診察といった情報に 組み込んで利用することができる

CLUSTER,ELEMENT図 ELEMENT CLUSTER ELEMENT CLUSTER ELEMENT

Archetype Slot • 他のアーキタイプを組み込むことができる – 組み込むアーキタイプに制約を与えることができ る（適合条件、除外条件） – 鍵と鍵穴 • 概念上、下位のアーキタイプしか食い込めな い – COMPOSITION-(SECTION)-ENTRY-CLUSTERELEMENT

Template設計

TEMPLATE • 実際のユースケースに応じて設計される – 帳票、伝票、画面、メッセージ • COMPOSITIONをベースとする – 運用上の最小単位 • 組み込んだArchetypeにさらに制約を付け加える こともできる – 必要な部分以外は省略 – オプション項目を必須化 • 構造を示すOETファイル、すべてのArchteype情 報を埋め込んだOPT(Operational Template)

Template設計手順 • Templateを命名する • コンテナを選択する – COMPOSITIONの中のどれか • 見出しを選ぶ（必要であれば） – SECTIONを利用する • 内容を定義する – 必要であれば制約を加える • OPTなどを作成する