Changes between Version 21 and Version 22 of Archtectural Overview Design of the openEHR EHR
- Timestamp:
- Oct 20, 2007, 7:18:53 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Design of the openEHR EHR
v21 v22 1 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Package" PREV] [wiki:"Archtectural Overview Security and Confidentiality" NEXT] 2 [[TOC]] 1 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Package" PREV] [wiki:"Archtectural Overview Security and Confidentiality" NEXT] [[TOC]] 3 2 4 3 = 6 openEHRの EHR設計 = 5 6 4 この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/design_of_ehr.html 6 Design of the openEHR EHR]の翻訳である。内容の正確性については保証しないので,正確な内容については原文を参照すること 7 5 … … 9 7 10 8 == 6.1 EHR システム == 11 12 9 6.1 The EHR System 13 10 … … 36 33 * EHR Extract - EHRシステム間の情報伝達単位であり、EHRをシリアライズしたものや、デモグラフィックなどの情報を持っている(EHR_Extract IMのEHR_EXTRACT型を参照) 37 34 38 39 40 41 42 43 35 * Composition - the committal unit of the EHR (see type COMPOSITION in EHR IM); 36 * EHR Acces - the EHR-wide access control object (see type EHR_ACCESS in EHR IM); 37 * EHR Status - the status summary of the EHR (see type EHR_STATUS in EHR IM); 38 * Folder hierarchy - act as directory structures in EHR, Demographic services (see type FOLDER in Common IM); 39 * Party - various subtypes including Actor, Role, etc. representing a demographic entity with identity and contact details (see type PARTY and subtypes in Demographic IM); 40 * EHR Extract - the transmission unit between EHR systems, containing a serialisation of EHR, demographic and other content (see type EHR_EXTRACT in EHR Extract IM). 44 41 45 42 All persistent openEHR EHR, demographic and related content is found within top-level information structures. Most of these are visible in the following figures. 46 43 47 44 == 6.3 EHR == 48 49 45 6.3 The EHR 50 46 … … 66 62 * ''Contributions'' : 健康記録に変更が加えられるたびに作成される変更記録。各Contributionはユーザーにより付託されるかともに保証されたレコードの中の更新管理された任意のアイテムの一つあるいはそれ以上のVersionsを参照している。 67 63 68 69 70 71 72 73 64 * EHR: the root object, identified by a globally unique EHR identifier; 65 * EHR_access (versioned): an object containing access control settings for the record; 66 * EHR_status (versioned): an object containing various status and control information, optionally including the identifier of the subject (i.e. patient) currently associated with the record; 67 * Directory (versioned): an optional hierarchical structure of Folders that can be used to logically organise Compositions; 68 * Compositions (versioned): the containers of all clinical and administrative content of the record; 69 * Contributions: the change-set records for every change made to the health record; each Contribution references a set of one or more Versions of any of the versioned items in the record that were committed or attested together by a user to an EHR system. 74 70 75 71 DirectoryオブジェクトにしたがいCompositionの内部構造はCEN EN13606やHL7 CDA標準のような国際的に承認された健康情報の水準に密接に対応している。臨床やレコードの管理のために必要な全てのデータ型のために21のデータ型が提示されている。 … … 80 76 81 77 == 6.4 エントリーと「臨床記述」 == 82 83 78 6.4 Entries and "clinical statements" 84 79 85 ==== Entryサブタイプ 80 ==== Entryサブタイプ ==== 86 81 Entry Subtypes 87 82 … … 104 99 この図では、臨床医学だけではなく、一般科学においても典型的な対話的問題解決プロセスで、情報が作成されるサイクルを示している。全体としての「システム」は、「患者システム」(patient system)と「臨床調査システム」(clinical investigator system)の2つの部分で構成されている。後者は医療従事者で構成されているが、患者を含むこともあり(患者が観察的行動や治療的行動を行っている場合)、患者システムの状態を理解し,ケアを提供することに関与する。問題は、観察し、意見(仮説)を出し、次のステップのために行動を処方(指示)することで解決される。その結果,更なる調査が行われたり問題を解決するために計画された調査が行われたりして、指示(行動)が実施される。 105 100 106 107 101 This figure shows the cycle of information creation due to an iterative, problem solving process typical 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). 108 102 … … 111 105 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 information that might occur. 112 106 113 114 107 ==== Entry型のオントロジー ==== 115 116 108 Ontology of Entry Types 117 109 … … 130 122 Regardless of the diversity, each of the leaf-level categories shown in this figure is ultimately a subcategory of one of the types from the process model, and hence, of the subtypes of the openEHR Entry model. 131 123 132 特定(こでの場合は評価)のEntryサブタイプに関連のある関心についての情報(例えば、リスク評価)を表現するために設計されたアーキタイプを利用することで、オントロジー由来のカテゴリーを正確に表現することができるようになる。Entryがこのようにモデル化されたシステムでは、 124 特定(こでの場合は評価)のEntryサブタイプに関連のある関心についての情報(例えば、リスク評価)を表現するために設計されたアーキタイプを利用することで、オントロジー由来のカテゴリーを正確に表現することができるようになる。Entryがこのようにモデル化されたシステムでは、多様な種類のEntryを誤って識別する危険性がなく、Entryのサブタイプや時間、確定性/否定も同様に配慮される。[図18 http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr3.gif]のオントロジーが正確なものではなくても、アーキタイプはそのようなカテゴリーが実際にあるべき改良された概念を扱うように構築されることに注意すべきである。 133 125 126 Correct representation of the categories from the ontology is enabled by using archetypes designed to express the information of interest (say a risk assessment) in terms of a particular Entry subtype (in this case, Evaluation). In a system where Entries are thus modelled, there will be no danger of incorrectly identifying the various kinds of Entries, as long as the Entry subtype, time, and certainty/negation are taken into account. Note that even if the ontology of FIGURE 18 is not correct (undoubtedly it isn't), archetypes will be constructed to account for each improved idea of what such categories should really be. 134 127 135 Correct representation of the categories from the ontology is enabled by using archetypes designed to express the information of interest (say a risk assessment) in terms of a particular Entry subtype (in this case, Evaluation). In a system where Entries are thus modelled, there will be no danger of incorrectly identifying the various kinds of Entries, as long as the Entry subtype, time, and certainty/negation are taken into account. Note that even if the ontology of FIGURE 18 is not correct (undoubtedly it isn't), archetypes will be constructed to account for each improved idea of what such categories should really be. 128 ==== 臨床記述の状態と否定 ==== 136 129 Clinical Statement Status and Negation 130 131 診療情報を記録する際によく知られている問題は、記録された事項の状態をどのように割り当てるかということである。「Pの実測値」(Pはある現象を現す)「Pの家族歴」「Pのリスク」「Pのおそれ」や、これらの否定(例えば「Pではないもの」「Pの履歴なし」など)についても同様に多様な状態についての表現がある。このように一般に表現される状態を適切に分析してみると、これらは「状態」といえるものではなく、[図18 http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr3.gif]に示されるオントロジーのような情報の別のカテゴリーである。一般に、否定は適切なEntry型の「除外(exclusion)」アーキタイプを利用して扱われる。例えば、「アレルギーなし」はこの患者からアレルギーが除外されると表現する評価(Evaluation)アーキタイプを使ってモデル化することができる。別の状態を示す型の組み合わせは、例えば「(5年前の)大腿骨頭置換術」、「大腿骨頭置換術(推奨される)」、「大腿骨頭置換術(来週の火曜日午前10時に予定されている)」といった介入に関連した情報をシステム内で適切にモデル化することができずに混乱している。 137 132 138 133 A well-known problem in clinical information recording is the assignment of "status" to recorded items. Kinds of status include variants like "actual value of P" (P stands for some phenomenon), "family history of P", "risk of P", "fear of P", as well as negation of any of these, i.e. "not/no P", "no history of P" etc. A proper analysis of these so called statuses shows that they are not "statuses" at all, but different categories of information as per the ontology of FIGURE 18. In general, negations are handled by using "exclusion" archetypes for the appropriate Entry type. For example, "no allergies" can be modelled using an Evaluation archetype that describes which allergies are excluded for this patient. Another set of statement types that can be confused in systems that do not properly model information categories concern interventions, e.g. "hip replacement (5 years ago)", "hip replacement (recommended)", "hip replacement (ordered for next tuesday 10 am)". … … 150 145 The openEHR approach to these challenges is to use the Entry type INSTRUCTION, its subpart ACTIVITY to specify interventions in the future, and the Entry subtype ACTION to record what has actually happened. A number of important features are provided in this model, including: 151 146 152 153 154 155 147 * a single, flexible way of modelling all interventions, whether they be single drug medication orders or complex hospital-based therapies; 148 * a way of knowing the state of any intervention, in terms of the states in a standard state machine, shown in FIGURE 19; this allows a patient's EHR to be queried in a standard way so as to return "all active medications", "all suspended interventions" etc.; 149 * a way of mapping particular care process flow steps to the standard state machine states, enabling health professionals to define and view interventions in terms they understand; 150 * support for automated workflow, without requiring it. 156 151 157 152 Coupled with the comprehensive versioning capabilities of openEHR, the Instruction/Action design allows clinical users of the record to define and manage interventions for the patient in a distributed environment. … … 173 168 [[FootNote]] 174 169 175 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Package" PREV][wiki:"Archtectural Overview Security and Confidentiality" NEXT]170 [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Package" PREV] [wiki:"Archtectural Overview Security and Confidentiality" NEXT]