Changes between Version 40 and Version 41 of Archtectural Overview Design of the openEHR EHR
- Timestamp:
- Feb 10, 2008, 2:59:12 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Design of the openEHR EHR
v40 v41 6 6 6 Design of the openEHR EHR 7 7 8 == 6.1 EHR システム == 8 == 6.1 EHR システム == #system 9 9 6.1 The EHR System 10 10 11 情報という点でいうと,openEHRをベースとした最小限のEHRシステムはEHRのリポジトリで構築されている。それは,[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr8.gif 図13]に示すようにアーキタイプの レポジトリや(もし利用可能であれば)用語体系,デモグラフィック/識別情報からなりたっている。11 情報という点でいうと,openEHRをベースとした最小限のEHRシステムはEHRのリポジトリで構築されている。それは,[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr8.gif 図13]に示すようにアーキタイプのリポジトリや(もし利用可能であれば)用語体系,デモグラフィック/識別情報からなりたっている。 12 12 13 13 In informational terms, a minimal EHR system based on openEHR consists of an EHR repository, an archetype repository, terminology (if available), and demographic/identity information, as shown in FIGURE 13. … … 19 19 The latter may be in the form of an existing PMI (patient master index) or other directory, or it may be in the form of an openEHR demographic repository. An openEHR demographic repository can act as a front end to an existing PMI or in its own right. Either way it performs two functions: standardisation of demographic information structures and versioning. An openEHR EHR contains references to entities in whichever demographic repository has been configured for use in the environment; the EHR can be configured to include either no demographic or some identifying data. One of the basic principles of openEHR is the complete separation of EHR and demographic information, such that an EHR taken in isolation contains little or no clue as to the identity of the patient it belongs to. The security benefits are described below. In more complete EHR systems, numerous other services (particularly security-related) would normally be deployed, as shown in FIGURE 7. 20 20 21 == 6.2 トップレベル情報構造 ==21 == 6.2 最上位情報構造 == #top-level 22 22 6.2 Top-level Information Structures 23 23 24 今まで述べてきたように、openEHRの情報モデルはさまざまな粒度の情報を定義している。細粒度の構造がデータ構造や共通モデルで利用される支援情報やデータ型で定義されている。これらは,EHR、EHR Extract,デモグラフィックと他の「 トップレベル」モデルの順番で利用されており、後の方のモデルはopenEHRNo「トップレベル構造」を定義している。内容の構造は明確に独立しており,ドキュメント指向システムにおいて分割されたドキュメントと同じように考えてよい。openEHRの情報システムでは、「トップレベル構造」は一般的にユーザーにとって直接関心を引くものである。主要なトップレベル構造には以下のようなものがある。24 今まで述べてきたように、openEHRの情報モデルはさまざまな粒度の情報を定義している。細粒度の構造がデータ構造や共通モデルで利用される支援情報やデータ型で定義されている。これらは,EHR、EHR Extract,デモグラフィックと他の「最上位」モデルの順番で利用されており、後の方のモデルはopenEHRの「最上位構造」を定義している。内容の構造は明確に独立しており,ドキュメント指向システムにおいて分割されたドキュメントと同じように考えてよい。openEHRの情報システムでは、「最上位構造」は一般的にユーザーにとって直接関心が向けられるものである。主要な最上位構造には以下のようなものがある。 25 25 26 26 As has been shown, the openEHR information models define information at varying levels of granularity. Fine-grained structures defined in the Support and Data types are used in the Data Structures and Common models; these are used in turn in the EHR, EHR Extract, Demographic and other "top-level" models. These latter models define the "top-level structures" of openEHR, i.e. content structures that can sensibly stand alone, and may be considered the equivalent of separate documents in a document-oriented system. In openEHR information systems, it is generally the top-level structures that are of direct interest to users. The major top-level structures include the following: … … 28 28 * Composition - EHRの引き渡し単位(EHR IMのCOMPOSITION型を参照) 29 29 * EHR Acces - EHR単位のアクセス管理オブジェクト(EHR IMのEHR_ACCESS型を参照) 30 * EHR Status - EHR No状態サマリー(EHR IMのEHR_STATUS型を参照)30 * EHR Status - EHRの状態サマリー(EHR IMのEHR_STATUS型を参照) 31 31 * Folder hierarchy - EHRやデモグラフィックサービスののディレクトリ構造として働く(Common IMのFOLDER型を参照) 32 32 * Party - ActorやRoleなどを含むさまざまなサブタイプ。識別や連絡先情報といったデモグラフィックエンティティを表現する(PARTY型やDemographic IMのサブタイプを参照) … … 42 42 All persistent openEHR EHR, demogr[!http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/aphic and related content is found within top-level information structures. Most of these are visible in the following figures. 43 43 44 == 6.3 EHR == 44 == 6.3 EHR == #ehr 45 45 6.3 The EHR 46 46 47 openEHRのEHRは比較的単純なモデルにしたがって構造化されている。EHR IDで識別されるEHRの中心オブジェクトは,構造化された数多くの型や更新管理された情報に加えて、EHRへの変更を監査する役割のあるContributionオブジェクトのリストへの参照を指定している。[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehra.gif 図14]にopenEHRのEHR高次構造が示されている。示している。47 openEHRのEHRは比較的単純なモデルにしたがって構造化されている。EHR IDで識別されるEHRの中心オブジェクトは,構造化された数多くの型や更新管理された情報に加えて、EHRへの変更を監査する役割のあるCONTRIBUTIONオブジェクトのリストへの参照を指定している。[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehra.gif 図14]にopenEHRのEHR高次構造が示されている。 48 48 49 49 The openEHR EHR is structured according to a relatively simple model. A central EHR object identified by an EHR id specifies references to a number of types of structured, versioned information, plus a list of Contribution objects that act as audits for changes made to the EHR. The high-level structure of the openEHR EHR is shown in FIGURE 14. … … 58 58 * ''EHR_access (versioned)'': レコードへのアクセス管理設定を持つオブジェクト 59 59 * ''EHR_status (versioned)'': さまざまな状態や管理情報を持つオブジェクト。現在関連のあるレコード(例えば患者)を対象とした識別子をもつこともある。 60 * ''D irectory (versioned)'': Compositionを論理的に整理するために使える任意に階層的な構造を持つFolder61 * ''C ompositions(versioned)'': 全ての臨床や管理のためのレコードの内容についてのコンテナ62 * ''C ontributions'' : 健康記録に変更が加えられるたびに作成される変更記録。各Contributionはユーザーにより付託されるかともに保証されたレコードの中の更新管理された任意のアイテムの一つあるいはそれ以上のVersionsを参照している。60 * ''DIRECTORY (versioned)'': COMPOSITIONを論理的に整理するために使える任意に階層的な構造を持つFOLDER 61 * ''COMPOSITION (versioned)'': 全ての臨床や管理のためのレコードの内容についてのコンテナ 62 * ''CONTRIBUTION'' : 健康記録に変更が加えられるたびに作成される変更記録。各CONTRIBUTIONはユーザーにより付託されるかともに保証されたレコードの中の更新管理された任意のアイテムの一つあるいはそれ以上のVERSIONを参照している。 63 63 64 64 * EHR: the root object, identified by a globally unique EHR identifier; … … 69 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. 70 70 71 D irectoryオブジェクトにしたがいCompositionの内部構造はCEN EN13606やHL7 CDA標準のような国際的に承認された健康情報の水準に密接に対応している。臨床やレコードの管理のために必要な全てのデータ型のために21のデータ型が提示されている。71 DIRECTORYオブジェクトにしたがいCOMPOSITIONの内部構造はCEN EN13606やHL7 CDA標準のような国際的に承認された健康情報のレベルに密接に対応している。臨床やレコードの管理のために必要な全てのデータ型のために21のデータ型が提示されている。 72 72 73 73 The internal structure of the Composition along with the Directory object correspond closely to the levels in internationally agreed models of health information such as the CEN EN13606 and HL7 CDA standards. … … 75 75 The logical structure of a typical Composition is shown in more detail in FIGURE 15. In this figure, the various hierarchical levels from Composition to the data types are shown in a typical arrangement. The 21 data types provide for all types of data needed for clinical and administrative recording. 76 76 77 == 6.4 エントリーと「臨床記述」 == 77 == 6.4 エントリーと「臨床記述」 == statement 78 78 6.4 Entries and "clinical statements" 79 79 … … 81 81 Entry Subtypes 82 82 83 結局のところopenEHRのEHRで作成された臨床情報は全て「Entry」として表現される。Entryは論理的には、1つの「臨床記述」であって、簡単で短くわかりやすいフレーズであるが、重要な意味を多く含んでもいる。例えば、微生物検査結果全体や、心理学的検査記録、複雑な処方オーダーなど。実際の意味において、Entryクラスはレコードにおける「ハード」な情報すべてのセマンティクスを定義しているため、openEHRのEHR情報モデルでもっとも重要なものである。これらはアーキタイプ化されることを目的としており、実際にEntryのためのアーキタイプとEntryの一部はEHRのために定義されたアーキタイプの非常に大きな部分を占めている。83 突き詰めて言うと,openEHRのEHRで作成される臨床情報は全て「Entry」として表現される。Entryは論理的には、1つの「臨床記述」であって、簡単で短くわかりやすいフレーズであるが、重要な意味を多く含んでもいる。例えば、微生物検査結果全体や、心理学的検査記録、複雑な処方オーダーなど。実際の意味において、Entryクラスはレコードにおける「ハード」な情報すべてのセマンティクスを定義しているため、openEHRのEHR情報モデルでもっとも重要なものである。これらはアーキタイプ化されることを目的としており、実際にEntryのためのアーキタイプとEntryの一部はEHRのために定義されたアーキタイプの非常に大きな部分を占めている。 84 84 85 85 All clinical information created in the openEHR EHR is ultimately expressed in "Entries". An Entry is logically a single `clinical statement', and may be a single short narrative phrase, but may also contain a significant amount of data, e.g. an entire microbiology result, a psychiatric examination note, a complex medication order. In terms of actual content, the Entry classes are the most important in the openEHR EHR Information Model, since they define the semantics of all the `hard' information in the record. They are intended to be archetyped, and in fact, archetypes for Entries and sub-parts of Entries make up the vast majority of archetypes defined for the EHR. … … 101 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). 102 102 103 このプロセスモデルはLawrence WeedのEHR記録における「問題指向」(problem-oreinted)をはじめ、あとで関連する業績として、Rector, Nowland, Kayによるモデル[[FootNote(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.)]]や「仮説演繹」推論モデル[[FootNote(Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press, 1978)]]を合成して作られている。しかしながら、仮説をたてて検証していくことは臨床家にとって唯一の成功のためのプロセスではない。エビデンスは(年齢が高く経験を積んでいるほど)パターン認識に大きく依存しており、以前に経験した同じような患者やプロトタイプモデルで使われたプランを直接利用することがある。openEHRで使われている調査プロセスモデルは、認知的方法にも準拠している。なぜなら、意見がどのように形成されるのか,結論までにどれくらいプロセスを繰り返さなければいけないのか、繰り返しの間に存在する全てのステップが要求されるかどうかさえも明らかにされていないからである。(例えば,一般内科医(General Physician)は確定診断に至る前に処方することがよくある)結局のところ,openEHRのEntryモデルはプロセスモデルを押し付けるものではなく、起こりうる情報がとりうる型をあらわしている。103 このプロセスモデルはLawrence WeedのEHR記録における「問題指向」(problem-oreinted)をはじめ、あとで関連する業績として、Rector, Nowland, Kayによるモデル[[FootNote(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.)]]や「仮説演繹」推論モデル[[FootNote(Elstein AS, Shulman LS, Sprafka SA. Medical problem solving: an analysis of clinical reasoning. Cambridge, MA: Harvard University Press, 1978)]]を合成して作られている。しかしながら、仮説をたてて検証していくことは臨床家にとって唯一の成功のためのプロセスではない。エビデンスは(年齢が高く経験を積んでいるほど)パターン認識に大きく依存しており、以前に経験した同じような患者やプロトタイプモデルで使われたプランを直接利用することがある。openEHRで使われている調査プロセスモデルは、認知論的手法にも準拠している。なぜなら、意見がどのように形成されるのか,結論までにどれくらいプロセスを繰り返さなければいけないのか、繰り返しの間に存在する全てのステップが要求されるかどうかさえも明らかにされていないからである。(例えば,一般内科医(General Physician)は確定診断に至る前に薬剤を処方することがよくある)つまり,openEHRのEntryモデルはプロセスモデルを押し付けるものではなく,起こりうる情報がとりうる型をあらわしている。 104 104 105 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. … … 114 114 [[Image(design_of_ehr3.gif)]] 115 115 116 最上位の重要なカテゴリは「ケア情報(care information)」と「管理情報(administrative information)」である。ケア情報カテゴリにはケアプロセスの任意の時点で記録される可能性のあるすべての命令文を網羅しており,Entryモデルの基礎となっている主要なサブカテゴリである「観察(observation)」、「 主張(opinion)」、「指示(instruction)」、「行動(action)」(ある種の観察)も含んでいる。これらは過去や現在、そして未来の時点にも対応している。管理情報カテゴリはケアプロセスだけで生成されていないが、それを組織化するのに関連するような予約や入院と言ったことに関する情報を網羅している。この情報はケアに関するものではないが,ケアを提供するための後方支援に関連している。116 最上位の重要なカテゴリは「ケア情報(care information)」と「管理情報(administrative information)」である。ケア情報カテゴリにはケアプロセスの任意の時点で記録される可能性のあるすべての命令文を網羅しており,Entryモデルの基礎となっている主要なサブカテゴリである「観察(observation)」、「見解(opinion)」、「指示(instruction)」、「行動(action)」(ある種の観察)も含んでいる。これらは過去や現在、そして未来の時点にも対応している。管理情報カテゴリはケアプロセスだけで生成されていないが、それを組織化するのに関連するような予約や入院と言ったことに関する情報を網羅している。この情報はケアに関するものではないが,ケアを提供するための後方支援に関連している。 117 117 118 118 The key top-level categories are `care information' and `administrative information'. The former encompasses all statements that might be recorded at any point during the care process, and consists of the major sub-categories on which the Entry model is based, namely `observation', `opinion', `instruction', and `action' (a kind of observation) which themselves correspond to the past, present and future in time. The administrative information category covers information which is not generated by the care process proper, but relates to organising it, such as appointments and admissions. This information is not about care, but about the logistics of care delivery. … … 141 141 Further details on the openEHR model clinical information are given in the EHR IM document, Entry Section. 142 142 143 == 6.5 介入の管理 == 143 == 6.5 介入の管理 == #intervention 144 144 6.5 Managing Interventions 145 145 … … 174 174 and manage interventions for the patient in a distributed environment. 175 175 176 == 6.6 EHRでの時間 == 176 == 6.6 EHRでの時間 == #time 177 177 6.6 Time in the EHR 178 178 179 時間は健康情報をモデル化する際の取り組むべき問題点として知られている。openEHRでは、今までに述べられてきた調査プロセスの副産物である時間(例えば、検体を採取した時間や集めた時間、測定した時間、ヘルスケア業務の出来事が起きた時間、データが登録された時間)は具体的にモデル化されていて、特定の内容に限定された他の時間(例えば、発症した日や転帰日)は汎用データ属性をアーキタイプ化することでモデル化されつつある。次の[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr6.gif?format=raw 図]は典型的な観察プロセスについての時間とopenEHRの参照モデルにおいて対応する属性との関係を示している。GPの診察や放射線レポートや他のものであるなどの異なるシナリオにおいては、一時的な関係は図に示されているものとはまったく異なることに注意すべきである。時間はEHR情報モデル文書(EHR Infomation Model document)に詳し き記載されている。179 時間は健康情報をモデル化する際の取り組むべき問題点として知られている。openEHRでは、今までに述べられてきた調査プロセスの副産物である時間(例えば、検体を採取した時間や集めた時間、測定した時間、ヘルスケア業務の出来事が起きた時間、データが登録された時間)は具体的にモデル化されていて、特定の内容に限定された他の時間(例えば、発症した日や転帰日)は汎用データ属性をアーキタイプ化することでモデル化されつつある。次の[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20of%20the%20openEHR%20EHR/design_of_ehr6.gif?format=raw 図]は典型的な観察プロセスについての時間とopenEHRの参照モデルにおいて対応する属性との関係を示している。GPの診察や放射線レポートや他のものであるなどの異なるシナリオにおいては、一時的な関係は図に示されているものとはまったく異なることに注意すべきである。時間はEHR情報モデル文書(EHR Infomation Model document)に詳しく記載されている。 180 180 181 181 Time is well-known as a challenging modelling problem in health information. In openEHR, times that are a by-product of the investigation process (e.g. time of sampling or collection; time of measurement, time of a healthcare business event, time of data committal) described above are concretely modelled, while other times specific to particular content (e.g. date of onset, date of resolution) are modelled using archetyping of generic data attributes. The following figure shows a typical relationship of times with respect to the observation process, and the corresponding attributes within the openEHR reference model. Note that under different scenarios, such as GP consultation, radiology reporting and others, the temporal relationships may be quite different than those shown in the figure. Time is described in detail in the EHR Information Model document. … … 183 183 [[Image(design_of_ehr6.gif)]] 184 184 185 == 6.7 言語 == 185 == 6.7 言語 == #language 186 186 6.7 Language 187 187 … … 194 194 Language is handled as follows in the openEHR EHR. The default language for the whole EHR is determined from the operating system locale. It may be included in the EHR_status object if desired. 195 195 196 次に言語は強制的にEHRデータの二つの場所で指定される。つまり、CompositionとEntry(例えばObservationなど)のlanguage属性である。こうすることで、EHRで尾となる言語をCompositionで使うことができ、同じCompositionにある複数のエントリーで異なる言語を利用することができる。さらに、Entry内部でテキストやコード化されたテキストといった項目はEntry内部での言語と違うものであれば、その言語で記録することも出来、これらの型は言語を指定しなくてもよいEntry型以外の構造で使われることもある。[[BR]]Language is then mandatorily indicated in two places in the EHR data, namely in Compositions and Entries (i.e. Observations, etc), in a language attribute. This allows both Compositions of different languages in the EHR, and Entries of different languages in the same Composition. Additionally, within Entries, text and coded text items may optionally have language recorded if it is different from the language of the enclosing Entry, or where these types are used within other non-Entry structures that don't indicate language. 197 198 実際の多言語環境は、いくつかの場面において臨床で遭遇する内容ではあるが、これらの特徴は翻訳の時にもっともよく利用される。翻訳の場合にはEHRのある部分(例えば、特定のComposition)が臨床で起こることの前後でEHRの第一言語で利用できる情報に翻訳するために利用される。(他のEHRとの交流のような場面での)翻訳作業では記録を新しいVersionの形式に変更することもある。新しい翻訳はバージョンのブランチとして便利に記録することが出来、翻訳のバージョンを付け加えることができる。これは強制されるものではないが、大本の内容を置換することなく翻訳を記録する便利な方法を提供している。The use of these features is mostly likely to occur due to translation, although in some cases a truly multi-lingual environment might exist within the clinical encounter context. In the former case, some parts of an EHR, e.g. particular Compositions will be translated before or after a clinical encounter to as to make the information available in the primary language of the EHR. The act of translation (like any other interaction with the EHR) will cause changes to the record, in the form of new Versions. New translations can conveniently be recorded as branch versions, attached to the version of which they are a translation. This is not mandatory, but provides a convenient way to store translations so that they don't appear to replace the original content. 196 次に言語は強制的にEHRデータの二つの場所で指定される。つまり、COMPOSITIONとEntry(例えばObservationなど)のlanguage属性である。こうすることで、EHRで異なる言語を同一のCOMPOSITIONで使うことができ、同じCOMPOSITIONにある複数のエントリーで異なる言語を利用することができる。さらに、Entry内部でテキストやコード化されたテキストといった項目はEntry内部での言語と違うものであれば、その言語で記録することも出来、これらの型は言語を指定しなくてもよいEntry型以外の構造で使われることもある。 197 198 Language is then mandatorily indicated in two places in the EHR data, namely in Compositions and Entries (i.e. Observations, etc), in a language attribute. This allows both Compositions of different languages in the EHR, and Entries of different languages in the same Composition. Additionally, within Entries, text and coded text items may optionally have language recorded if it is different from the language of the enclosing Entry, or where these types are used within other non-Entry structures that don't indicate language. 199 200 実際の多言語環境は、いくつかの場面において臨床で遭遇する内容ではあるが、これらの特徴は翻訳の時にもっともよく利用される。翻訳の場合にはEHRのある部分(例えば、特定のCOMPOSITION)が臨床で起こることの前後でEHRの第一言語で利用できる情報に翻訳するために利用される。(他のEHRとの交流のような場面での)翻訳作業では記録を新しいVERSION形式に変更することもある。新しい翻訳はVERSIONのブランチとして便利に記録することが出来、翻訳のVERSIONを付け加えることができる。これは強制されるものではないが、大本の内容を置換することなく翻訳を記録する便利な方法を提供している。 201 202 The use of these features is mostly likely to occur due to translation, although in some cases a truly multi-lingual environment might exist within the clinical encounter context. In the former case, some parts of an EHR, e.g. particular Compositions will be translated before or after a clinical encounter to as to make the information available in the primary language of the EHR. The act of translation (like any other interaction with the EHR) will cause changes to the record, in the form of new Versions. New translations can conveniently be recorded as branch versions, attached to the version of which they are a translation. This is not mandatory, but provides a convenient way to store translations so that they don't appear to replace the original content. 199 203 200 204 [[FootNote]]