Changes between Version 22 and Version 23 of Archtectural Overview Design of the openEHR EHR

Timestamp:

Oct 20, 2007, 7:23:55 PM (17 years ago)

Author:

KOBAYASHI, Shinji

Comment:

--

Archtectural Overview Design of the openEHR EHR

@@ -122 +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.
 
-特定（こでの場合は評価）のEntryサブタイプに関連のある関心についての情報（例えば、リスク評価）を表現するために設計されたアーキタイプを利用することで、オントロジー由来のカテゴリーを正確に表現することができるようになる。Entryがこのようにモデル化されたシステムでは、多様な種類のEntryを誤って識別する危険性がなく、Entryのサブタイプや時間、確定性/否定も同様に配慮される。[図18 http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr3.gif]のオントロジーが正確なものではなくても、アーキタイプはそのようなカテゴリーが実際にあるべき改良された概念を扱うように構築されることに注意すべきである。
+特定（こでの場合は評価）のEntryサブタイプに関連のある関心についての情報（例えば、リスク評価）を表現するために設計されたアーキタイプを利用することで、オントロジー由来のカテゴリーを正確に表現することができるようになる。Entryがこのようにモデル化されたシステムでは、多様な種類のEntryを誤って識別する危険性がなく、Entryのサブタイプや時間、確定性/否定も同様に配慮される。[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr3.gif 図18]のオントロジーが正確なものではなくても、アーキタイプはそのようなカテゴリーが実際にあるべき改良された概念を扱うように構築されることに注意すべきである。
 
 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. 
@@ -129 +129 @@
 Clinical Statement Status and Negation
 
-診療情報を記録する際によく知られている問題は、記録された事項の状態をどのように割り当てるかということである。「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時に予定されている）」といった介入に関連した情報をシステム内で適切にモデル化することができずに混乱している。
+診療情報を記録する際によく知られている問題は、記録された事項の状態をどのように割り当てるかということである。「Pの実測値」（Pはある現象を現す）「Pの家族歴」「Pのリスク」「Pのおそれ」や、これらの否定(例えば「Pではないもの」「Pの履歴なし」など）についても同様に多様な状態についての表現がある。このように一般に表現される状態を適切に分析してみると、これらは「状態」といえるものではなく、[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr3.gif 図18]に示されるオントロジーのような情報の別のカテゴリーである。一般に、否定は適切なEntry型の「除外(exclusion)」アーキタイプを利用して扱われる。例えば、「アレルギーなし」はこの患者からアレルギーが除外されると表現する評価(Evaluation)アーキタイプを使ってモデル化することができる。別の状態を示す型の組み合わせは、例えば「(5年前の)大腿骨頭置換術」、「大腿骨頭置換術(推奨される）」、「大腿骨頭置換術(来週の火曜日午前10時に予定されている）」といった介入に関連した情報をシステム内で適切にモデル化することができずに混乱している。
 
 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)".
+
+これらを記述するすべての型は
 
 All of these statement types map directly to one of the openEHR Entry types in an unambiguous fashion, ensuring that querying of the EHR does not match incorrect data, such as a statement about fear or risk, when the query was for an observation of the phenomenon in question.