Changes between Version 12 and Version 13 of Archetype FAQ


Ignore:
Timestamp:
Jul 26, 2007, 7:01:12 PM (17 years ago)
Author:
KOBAYASHI, Shinji
Comment:

ですます調への統一

Legend:

Unmodified
Added
Removed
Modified
  • Archetype FAQ

    v12 v13  
    6060    * '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.
    6161
    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 技術仕様])。
    6363
    6464    * '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).
    6565
    66 openEHRをもとにしたデータ処理では以下のようなことが可能とな
     66openEHRをもとにしたデータ処理では以下のようなことが可能となります
    6767
    6868Data processing in an openEHR-enabled context can now be done as follows:
     
    7070 * 例えばRDBMSやHL7v2メッセージといった大本のデータから仲介のためのXMLやCSV形式にデータをエクスポートあるいはコンバートする
    7171 * openEHRシステムにCEN 13606標準に準拠したアーキタイプを参照し、GENERIC_ENTRYのインスタンスとしてデータをインポートする
    72  * データを望み通りのアーキタイプを元にした形式や、OBSERVATION、ACTION、ECALUATION、INSTRUCTIONなどといったopenEHRのENTRYサブタイプにコンバートする。このコンバートは「アーキタイプインターフェース」を利用することに依存して実現するものである。つまり、アーキタイプのインターフェース定義によるものであって、その内部構造によるものではない
     72 * データを望み通りのアーキタイプを元にした形式や、OBSERVATION、ACTION、ECALUATION、INSTRUCTIONなどといったopenEHRのENTRYサブタイプにコンバートする。このコンバートは「アーキタイプインターフェース」を利用することに依存して実現するものです。つまり、アーキタイプのインターフェース定義によるものであって、その内部構造によるものではありません
    7373
    7474    * export or convert data from original source, e.g. RDBMS, HL7v2 messages to an intermediate XML or comma-separated value format
     
    7676    * 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.
    7777
    78 データはEN13606 Extractsの形式で簡単にシステムに入力することができ,EN13606 Extracsの形式で出力することもできる。これについて簡単に図示したプレゼンテーションがある
     78データはEN13606 Extractsの形式で簡単にシステムに入力することができ,EN13606 Extracsの形式で出力することもできます。これについて[http://www.openehr.org/downloads/EN13606_Entry.ppt 簡単に図示したプレゼンテーション]があります
    7979
    8080Data 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.
     
    8383Do archetypes replace terminology?
    8484
    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 このアーキタイプ]を参照してください(''オントロジー''セクションまでスクロールしてください)。
    8686
    8787Not 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).