openEHR and Problem

1. 正確性・連続性に関する考察
〜openEHRにおけるProblemの扱いの調査を通して〜
木村 映善
愛媛大学医学部附属病院 医療情報部
ソグネフィヨルド（ノルウェー）を船中より望みて 2011/08/30

2. Agenda
• openEHRにおけるProblemの定義・実装
– 用途・目的の共通認識
– 標準化された情報モデル(RM)とアーキタイプ
– 情報モデルに関するオントロジ
– プロブレム内容におけるオントロジ・ターミノロジ
– コンテキスト・監査情報の分離
• openEHRの方法論を到達点と仮定した場合
の正確性、連続性の要件整理
• 現状とのギャップ分析（阻害要因）

3. 情報モデルの標準化
用途、目的の共通認識
オントロジの定義
コンテキスト情報・監査情報の分離
Problem
文章による定義
• Lawrence Weed’s “problem-oriented”
method
• The model of Rector,Nwlan & Key
• The “hypothetico deductive” model
版管理 (Versioning)
COMPOSITIONがCI 相当
監査証跡・診療記録のメタデータ
COMPOSITION
• 診療記録の内容定義 ENTRY
• プロブレム
• 診療のナビゲーションに関わる定義
NAVIGATION
• SECTION
• プロブレムリスト
2階層情報モデル構造
・情報モデル(RM)
・アーキタイプ(Archetype)
情報モデル自体のオントロジの定義
ENTRY/CARE_ENTRY/EVALUATIONに所属
プロブレム記述自体のオントロジ、ターミノロジー
Problem曼陀羅@openEHR
セマンティックな接続の定義
・LINKクラスによるアーキタイプ間接続

4. The choice of these types is based on the clinical problem-solving process shown in FIGURE 17.
This figure shows the cycle of information creation due to an iterative, problem solving process typi-
cal not just of clinical medicine but of science in general. The “system” as a whole is made up of two
parts: the “patient system” and the “clinical investigator system”. The latter consists of health carers,
and may include the patient (at points in time when the patient performs observational or therapeutic
activities), and is responsible for understanding the state of the patient system and delivering care to
it. A problem is solved by making observations, forming opinions (hypotheses), and prescribing
actions (instructions) for next steps, which may be further investigation, or may be interventions
designed to resolve the problem, and finally, executing the instructions (actions).
This process model is a synthesis of Lawrence Weed’s “problem-oriented” method of EHR recording,
and later related efforts, including the model of Rector, Nowlan & Kay [7], and the “hypothetico-
ACTIVITY
FIGURE 16 The openEHR Entry model (in EHR IM)
FIGURE 17 Relationship of information types to the investigation process
opinions
observations
instructions
actions
patient
investigator
agents
investigator
- assessment
- goals
- plan
1
2
3
4
published
evidence
base
personal
knowledge
base
References:
*T Beale, S Heard,Architecture Overview Design of the openEHR EHR Rev 1.1,2007
3.Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reason- ing. Cambridge, MA: Harvard University Press, 1978
7.Rector A L, Nowlan W A, Kay S. Foundations for an Electronic Medical Record. The IMIA Yearbook of Medical Informatics 1992 (Eds. van Bemmel J, McRay A).
Stuttgart Schattauer 1994.
This process model is a synthesis of Lawrence Weed’s “problem-oriented” method of EHR recording, and later related efforts, including
the model of Rector, Nowlan & Kay [7], and the “hypothetico-
deductive” model of reasoning (see e.g. [3]). However hypothesis-making and testing is not the only successful process used by clinical
professionals - evidence shows that many (particularly those older and more experienced) rely on pattern recognition and direct retrieval
of plans used previously with similar patients or prototype models. The investigator process model used in openEHR is compatible with
both cognitive approaches, since it does not say how opinions are formed, nor imply any specific number or size of iterations to bring the
process to a conclusion, nor even require all steps to be present while iterating (e.g. GPs often prescribe without making a firm diagnosis).
Consequently, the openEHR Entry model does not impose a process model, it only provides the possible types of infor- mation that might
occur.
#奥原先生の研究にて言及
Problemの用途・目的

5. コンテキスト、監査情報の分離
• 臨床情報の記述とコンテキスト・監査用の情
報は明示的に分離する
• バージョン管理システムの概念
– 診療記録のマージなどの際に臨床情報はいじら
ずに、バージョンツリーの操作を行う
Versioning Architecture Overview
Rev 1.1
to provide a formal, general-purpose model for change control, and show how it applies to health
information.
8.2.1 Organisation of the Repository
The general organisation of a repository of complex information items such as a software repository,
or the EHR consists of the following:
• a number of distinct information items, or configuration items, each of which is uniquely
identified, and may have any amount of internal complexity;
• optionally, a directory system of some kind, in which the configurations items are organised;
• other environmental information which may be relevant to correctly interpreting the primary
versioned items, e.g. versions of tools used to create them.
In a software or document repository, the CIs are files arranged in the directories of the file system; in
an EHR based on openEHR, they are Compositions, the optional Folder structure, Parties in the
demographic service and so on. Contributions are made to the repository by users. This general
abstraction is visualised in FIGURE 24.
FIGURE 24 General Structure of a Controlled Repository
CI
CI
CI
CI
CI
CI
CI
CI
CI
Users
Repository
Users
CI
Directory
Structure Configuration
Item
F
F
F
F
contributions contributions
コンテキスト・監査情報 臨床情報

6. 例:カルテのマージ
• バージョン管理ツリーの操作のみ

7. 例:時刻情報
監査・コンテキスト情報
• 診療記録の記載開始、終了、確定
• 検査情報の受信
• オーダ情報受信、実施、終了
臨床情報（Problem Archetype)
• 初めて発症した日 (Date of Initial
onset)
• 臨床的に認識された日 (Date
Clinically recognized)
• 解決した日 (Date of Resolution)
• 最後に発生した日 (Date of last
occurrence)
• 発生した日と解決した日 (Date of
onset of occurrence and resolution of
occurrence)

8. Problem Archetypeで
扱っている時系列情報
Initial Onset
Clinically recognized
Resolution
Last occurrence
Onset of occurrence
Resolution of occurrence

9. 典型的な診療記録
openEHR Release 1.0.1 “openEHR Architecture Architecture Overview” T Beaks, S Heard et al.
検体の採取 測定・結果報告
openEHR
の記録
コミット
データ入力
一連のイベント
の開始時間
一連のイベント
の終了時間
監査
記録時間
検体の
採取時間
検体の
採取時間からの
経過時間、報告時間

10. 看護記録
openEHR
の記録 入院記録・イベント
入院日時
監査
記録時間
バイタル
サイン
入院記録・イベント
退院日時
バイタル
サイン
バイタル
サイン
監査
記録時間
監査
記録時間
採取日時 採取日時 採取日時

11. T Beals, S Heard,D Karla, D Lloyd, “The openEHR Reference Model” 2010
コミットした時刻の監
査証跡
Committerでコミット
した人を記録
コンテキスト・監査情報の
標準モデル
全てにおいて6W1Hが同じ
方法で記録・管理されるこ
とが重要

12. Ontological Structure of archetype
“2階層モデル”と外部概念への参照
Citation Sundvall, E., Qamar, R., Nyström, M., Forss, M., Petersson, H., Karlsson, D., Åhlfeldt, H.,Rector, A. ：Integration of
tools for binding archetypes to SNOMED CT： BMC Medical Informatics and Decision Making 8， S7， 2008.
疾患概念の記述
情報モデルの抽象化
外部概念

13. Archetypeのシステムへの実装
Domain
Content
Models
Information
Representation
Models
Vendor
Specific
Systems
情報モデルの抽象化
ベンダ固有実装
臨床概念の記述
EMR A EMR B EMR C
ISO/CEN13606Specifications
ofarchetypeandRM

14. ２つのオントロジ
情報モデルのオントロジ
• 診療記録の構造概念定義
• 「どこに何があるか」を一意
に定義する
• openEHRは標準情報モデ
ルの設計にオントロジを構
築
臨床情報記述用のオントロジ
• 診療情報の概念定義
• 「記載されている対象は何
であるか」を一意に定義す
る

15. 情報モデルのオントロジ
• ENTRYは”臨床記述そのもの”に対応し、ENTRYを基底クラスとしたオントロジを構
成する
• EVALUATION/INSTRUCTION/ACTION/OBSERVATIONは、”Clinical Investigator
Recording Process”のモデルに沿って分類
EHR Information Model Entry Package
Rev 5.1.1
patients or prototype models. The investigator process is compatible with both cognitive approaches,
since it does not say how opinions are formed, nor imply any specific number or size of iterations to
bring the process to a conclusion. As such, the openEHR information model does not impose any
process model, only the types of information used.
On the basis of this process, a Clinical Investigator Recording ontology is developed [4], as shown in
FIGURE 19. From this ontology, the openEHR class model for Entries is derivde. The openEHR
Entry class names are annotated next to their originating ontological categories.
FIGURE 19 The Clinical Investigator Recording (CIR) ontology
INSTRUCTIONEVALUATION
OBSERVATION ACTION
ADMIN_ENTRY
CARE_ENTRY
ENTRY
observation/
intervention
recorded
information
history opinion
assessment
care
information
admin
information
proposal
diagnosis risk recommendationgoal
intervention
scenarioprognosis
instruction
xxx
xxx = observation-related
= intervention-related
observation action
cognitive/temporal
categories
categories
analytical
categories
request
investigation
request
Ｐｒｏｂｌｅｍ

16. 臨床情報記述用のオントロジ
Empirical Derivation of an Electronic Clinically Useful Problem Statement
System Steven H. Brown, MS, MD; Randolph Annals of Internal Medicine Volume
131 Number 2 pp.117-126 1999
• Problemの記述に特化した用語集 CCPSS(Canonical Clinical Problem Statement
System) の評価
• 現在はCCPSSはUMLSに収録されている。
“Existing standardized vocabularies that predominantly include diagnoses or findings,
such as the International Classification of Diseases, Ninth Revision, Clinical Modification
(ICD-9-CM) (65) and the Systematized Nomenclature of Human and Veterinary Medicine
(SNOMED) (66), cannot encompass all categories of problem statements.”
“Computerized problem-statement input techniques have varied across implementation
sites because no ideal problem statement vocabulary exists”
“Because full-scale problem-oriented medical record systems are cumbersome and are
not universally accepted, most computerized medical record systems provide problem
lists but are not “problem-oriented.”
これらの指摘は現在でもあてはまる。1999年の古さを感じさせない
#Problemに関連した話題を例として

17. ENTRY間関連の表現
• ENTRY間に何らかの意味的関係があることを
表現する時にはLINKクラスが使われる。
• LINKクラスは同COMPOSITION内のみならず、
EHRをまたいだ紐付けの表現も可能。
– DV_EHR_URIというRMで記述される
• LINKクラスはRMであり、archetypeの中で保
持される。複数設定できるので、1:Nの関係を
定義できる。双方向リンクは対向のarchetype
から張り返すことで実現

18. CEN
The Link Item class is a simplified form of the Synapses Link Item, permitting
links to be established but with limited labelling and no representation for impor-
tance.
Synapses
The Link Item class provides the means to link any arbitrary parts of a single
EHR, for the overall linkage network to be labelled and revised, and for each
direct link to be labelled explicitly. An importance attribute provides guidance on
how links should be handled if only part of a linkage network is requested by a
client process.
GEHR n/a
HL7v3 The ACT_RELATIONSHIP class in some cases appears to correspond to LINK.
Attributes Signature Meaning
1..1
meaning: DV_TEXT Used to describe the relationship, usually in
clinical terms, such as “in response to” (the
relationship between test results and an order),
“follow-up to” and so on. Such relationships
can represent any clinically meaningful connec-
tion between pieces of information.
Values for meaning include those described in
Annex C, ENV 13606 pt 2 [11] under the cate-
gories of “generic”, “documenting and report-
ing”, “organisational”, “clinical”,
“circumstancial”, and “view management”.
1..1
type: DV_TEXT The type attribute is used to indicate a clinical
or domain-level meaning for the kind of link,
for example “problem” or “issue”. If type val-
ues are designed appropriately, they can be used
by the requestor of EHR extracts to categorise
links which must be followed and which can be
broken when the extract is created.
1..1
target: DV_EHR_URI The logical “to” object in the link relation, as
per the linguistic sense of the meaning attribute.
CLASS LINK

20. openEHR-EHR-
EVALUATION.problem.v1

21. ＊奥原先生より提供
プ
ロ
ブ
レ
ム
リ
ス
ト
プロブレムの
統合
プロブレムの
派生
記録の作成を
表わす星印
星印のダブルクリック
で開いた記録の内容
日付
Problem
Archetype間の
LINKによる定義
Problem Archetypeによる
記載内容の標準化
Problem List Archetype
によるコンテナ
Problem Archetypeに記
載された情報に基づく
監査上の日付等はバー
ジョン管理機構で

22. 連続性に関する考察

23. 連続性(第3回幹事会資料より）
• 一連の流れの中で記録されたデータは、そ
の流れの中の位置が明確になるような情報
が付加されているべき
• 少なくとも5W1H（誰が、誰に、何時、何処で、
何を、どうやって）、に加えて「目標」（プロブレ
ム）も必要。
• （プロブレムリストの決定に至った根拠（デー
タ、エビデンス）との関係が明らかであるべ
き。）

24. 一連の流れの中で記録されたデータは、その流れの中の位
置が明確になるような情報が付加されているべき。少なくとも
5W1H（誰が、誰に、何時、何処で、何を、どうやって）、に加えて
「目標」（プロブレム）も必要。
• 監査・コンテキスト情報と臨床情報の分離
– 診療記録管理上の5W1H
– 臨床情報記述上の5W1H
• バージョニングの独立管理
• 「流れ」をプロブレム間の関連と定義するなら
ば、LINKクラスのようにプロブレム間の関連を
定義する情報の付与

25. プロブレムリストの決定に至った根拠（データ、エビデンス）との
関係が明らかであるべき。
• LINKクラスにより、各プロブレムに根拠となる
情報を記載したCOMPOSITION、ENTRYへのリ
ンクを張る

26. 連続性の定義
• 時系列、空間的な位置(6W1H)等、前後関係
について多義的解釈の余地がない状態で特
定できること。
• さらに意味上においては、各プロセスの帰結
としてのドキュメント間の関連が特定出来るこ
と。

27. 連続性の要件充足のために(1)
• 時系列、空間的な位置(6W1H)等、前後関係
について多義的解釈の余地がない状態で特
定できること。
– 監査・コンテキスト情報と臨床情報の分離
– コンテキスト情報のモデルの標準化(6W1H)
• コンテキストに関するターミノロジーの標準化
– リンク情報のモデルの標準化
• 関係性を定義するターミノロジーの標準化

28. 連続性の要件充足のために(2)
• さらに意味上においては、各プロセスの帰結
としてのドキュメント間の関連が特定出来るこ
と。
– 診療記録の構造を定義する情報モデルの
• オントロジ標準化、モデル構造標準化
– リンク情報の標準化（前出）

29. 正確性に関する考察

30. 正確性の定義
• 臨床情報を構成する項目において、意味上の唯一の
解釈性と存在を保証すること。
– 唯一の解釈性とは、多義的解釈の余地を残さず、一次利
用、二次利用において、意味の誤解に基づく誤入力・誤
用が発生しないことである。(1)
– 存在を保証するとは、それ自体の概念及び上位概念を構
成するにあたって必須のデータは、入力し保存されている
ことを保証することである。(2)
• 備考
– インフラの観点からは電子保存の三原則（真正性、保存
性、見読性）を充足していることが前提である。
– 運用上の問題については言及しない
• 入力し忘れ等、ヒューマンファクターに関わる部分など

31. 正確性の阻害事象
(第3回幹事会資料より）
• 同じ概念であるデータの一元管理ができていない
– 異なるメーカごとに独立したシステム（心電図：フクダと日
本光電） (1)
– 異なる検査機器由来の計測値の不整合 (1)
• 変更中止等、記載漏れ (2)
• 2 重記載が生じる (1)+(2)
– 同じ内容を記載する場所が複数ある (1)+(2)
• 表記方法が不統一 (1)
• 用語の不統一 (1)
• 後利用を考えないデータ形式（絶対時間：暦年と相対
時間：何年前の混在） (1)
• 時刻データの定義が統一されていない (1)

32. 正確性の要件充足のために(1)
“唯一の解釈性とは、多義的解釈の余地を残さず、
一次利用、二次利用において、意味の誤解に基づ
く誤入力・誤用が発生しないことである。”
• オントロジの支援を受けた共通マスタ、モデルの
設計
– 標準モデルは値域の制約等、インスタンス上の整合
性に言及する
• 電子カルテ、テンプレート設計時に共通マスタに
基づいて項目を割り当てる

33. 正確性の要件充足のために(2)
“存在を保証するとは、それ自体の概念及び上位
概念を構成するにあたって必須のデータは、入力
し保存されていることを保証することである。”
• 上位概念を構成するとは？
– 複数の臨床情報が合わさって初めて意味を持つもの
• Ex. 拡張期/収縮期血圧
• Ex. 内視鏡オーダ時のワーファリン、MRIオーダ時の金属物
• Ex. 側性、ステージ
– 状態遷移の整合性をもって診療記録として成立する
もの
• Ex. オーダの指示、実施、中止

34. “必須のデータは、入力し保存されて
いることを保証することである。”
• 必須であるかどうかを定義する必要がある
–  標準データモデル、オントロジの定義が前提
•  正確性の定義の第1項の充足に依る
• 入力し保存されていることを保証
– 電子カルテ横断的にデータをリアルタイムで検索、
存在の確認ができることが前提
• Ex. MRIオーダ時の金属物
– 金属物に関する情報（及び格納方法）の標準化がなければ、
電子カルテ上でAd Hocな実装の繰り返しになる
– 医療安全に関する要件は今後も増える

35. 問診票
患者プロファイル
MRIオーダ
Check
インシデント例
• 問診票に金属物有りの書き込みがあったが、
患者プロファイルには記載されていなかった
• オーダ時チェックは患者プロファイルに記載さ
れているかどうかを確認していた

36. モデル標準化による横断検索
• Proactive Management
– データ欠損をリアルタイムに検出し、入力を督促
• Reactive Management
– 電子カルテ横断的にチェックの網をかぶせる
横断的監査
入力・発生源が複数あり、診
療記録が散在していても、
データモデルが標準化されて
いれば、横断検索ができるの
で、漏れがなくなる。