Changes between Version 12 and Version 13 of Archetype FAQ
- Timestamp:
- Jul 26, 2007, 7:01:12 PM (17 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archetype FAQ
v12 v13 60 60 * 'designed' archetypes, which clinicians design from scratch. There are many examples in Australia, and a growing library in Europe. These kind of archetypes are based on what we have called the "Domain Base Concept Model" (presentation about this). This sounds complicated, but in fact it just means "the UML model of invariant concepts in the domain, on which archetypes can be safely based". Currently this is the openEHR Reference Model, since it is the openEHR community doing most of this work at the moment. But in the future, we hope that this model will be adopted by others for this purpose, possibly with some additions, simplifications and so on. For example, the Danish Board of Health might want to propose some G-EPJ concepts should go in there. But note: this model is not meant to be large at all; our experience is that the openEHR model of Observation and Evaluation is about right for all archetypes so far developed as observations and diagnoses etc. We are redeveloping the Instruction Entry subtype in openEHR, which will provide a very powerful basis for archetypes for medication, interventions, orders etc. 61 61 62 * 'レガシー'アーキタイプ。レガシーデータを元にデザインされたものであり、典型的にはフラットであり樹状構造をもつものもある存在論的なデザインには従ってい ない。病院のデータベースやHL7v2メッセージなどのデータがそうである。GENERIC_ENTRYタイプはopenEHRの参照モデルにレガシーアーキタイプを提供する基礎として加えらるだろう(GENERIC_ENTRYタイプの[http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/integration_im.pdf 技術仕様])。62 * 'レガシー'アーキタイプ。レガシーデータを元にデザインされたものであり、典型的にはフラットであり樹状構造をもつものもある存在論的なデザインには従っていません。病院のデータベースやHL7v2メッセージなどのデータがそうです。GENERIC_ENTRYタイプはopenEHRの参照モデルにレガシーアーキタイプを提供する基礎として加えらるでしょう(GENERIC_ENTRYタイプの[http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/integration_im.pdf 技術仕様])。 63 63 64 64 * 'legacy' archetypes. These are archetypes which are designed to mimic legacy data, which itself does not follow any ontologica design - typically is is flat, or else tree-like. This could be data from a hospital database, HL7v2 messages etc. The GENERIC_ENTRY type will be added to the openEHR Reference Model to provide a basis for legacy archetypes (technical specification of GENERIC_ENTRY type). 65 65 66 openEHRをもとにしたデータ処理では以下のようなことが可能とな る:66 openEHRをもとにしたデータ処理では以下のようなことが可能となります: 67 67 68 68 Data processing in an openEHR-enabled context can now be done as follows: … … 70 70 * 例えばRDBMSやHL7v2メッセージといった大本のデータから仲介のためのXMLやCSV形式にデータをエクスポートあるいはコンバートする 71 71 * openEHRシステムにCEN 13606標準に準拠したアーキタイプを参照し、GENERIC_ENTRYのインスタンスとしてデータをインポートする 72 * データを望み通りのアーキタイプを元にした形式や、OBSERVATION、ACTION、ECALUATION、INSTRUCTIONなどといったopenEHRのENTRYサブタイプにコンバートする。このコンバートは「アーキタイプインターフェース」を利用することに依存して実現するもので ある。つまり、アーキタイプのインターフェース定義によるものであって、その内部構造によるものではない。72 * データを望み通りのアーキタイプを元にした形式や、OBSERVATION、ACTION、ECALUATION、INSTRUCTIONなどといったopenEHRのENTRYサブタイプにコンバートする。このコンバートは「アーキタイプインターフェース」を利用することに依存して実現するものです。つまり、アーキタイプのインターフェース定義によるものであって、その内部構造によるものではありません。 73 73 74 74 * export or convert data from original source, e.g. RDBMS, HL7v2 messages to an intermediate XML or comma-separated value format … … 76 76 * convert the data to a form based on desired archetypes, and openEHR ENTRY subtypes, i.e. OBSERVATION, ACTION, EVALUATION, INSTRUCTION. This conversion can be done based on the use of "archetype interfaces", i.e. definitions of the interfaces of archetypes, regardless of their internal structures. 77 77 78 データはEN13606 Extractsの形式で簡単にシステムに入力することができ,EN13606 Extracsの形式で出力することもでき る。これについて簡単に図示したプレゼンテーションがある。78 データはEN13606 Extractsの形式で簡単にシステムに入力することができ,EN13606 Extracsの形式で出力することもできます。これについて[http://www.openehr.org/downloads/EN13606_Entry.ppt 簡単に図示したプレゼンテーション]があります。 79 79 80 80 Data can also be easily accepted into such a system in the form of EN13606 Extracts, and output in the form of EN13606 Extracts. A simple presentation shows this graphically. … … 83 83 Do archetypes replace terminology? 84 84 85 すべて ではない。アーキタイプは用語体系に関する系統的なインターフェースを提供するように設計されている。アーキタイプはそれ自体用語体系に中立である。医療情報システムではありとあらゆる医学的視点が必要となるため,単一の用語体系やオントロジーで記述できない(おそらく今後もできないだろう)。用語体系についての問題への議論については,ADL仕様(セクション:The Problem of Terminology)を参照すること。ADLは85 すべてを置き換えられることはありません。アーキタイプは用語体系に関する系統的なインターフェースを提供するように設計されています。アーキタイプはそれ自体用語体系に中立でです。医療情報システムではありとあらゆる医学的視点が必要となるため,単一の用語体系やオントロジーで記述できません(おそらく今後もできないでしょう)。用語体系についての問題への議論については,ADL仕様(セクション:The Problem of Terminology)を参照してください。ADLは用語体系と関連付けて設計されており,一つ以上の用語体系と結合することができるようにアーキタイプが作られています。この関連付けはそこにある用語と用語体系コードへの制約性のあるコードや問い合わせ表現に,それぞれ対応するようマッピングされたものの集合です。例として[http://svn.openehr.org/knowledge/archetypes/dev/adl/openehr/ehr/entry/observation/openEHR-EHR-OBSERVATION.microbiology.v1.html このアーキタイプ]を参照してください(''オントロジー''セクションまでスクロールしてください)。 86 86 87 87 Not at all. Archetypes are designed to provide systematic interface with terminologies. They are, in themselves, terminology-neutral, because there is no (and probably will never be) single terminology or ontology which describes the whole of medicine in the myriad points of view needed in clinical information systems. For a discussion of the problems with terminology, see the ADL specification (section: The Problem of Terminology). ADL is designed to have bindings to terminologies, and any given archetype can include bindings to more than one. A binding is the set of mappings from archetype local term and constraint codes to terminology codes and query expressions respectively. See this archetype for an example (scroll to the ontology section).