[wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Design Principles" PREV] [wiki:"Design of the openEHR EHR" NEXT] [[TOC]] = 5 openEHRのパッケージ構造 = 5 openEHR Package Structure == 5.1 概観 == 5.1 Overview [http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Package/package_structurea.gif 図8]はopenEHR公式仕様のパッケージ構造を図示している。3つの主要なパッケージは、rm、am、smと定義されている。詳細なモデルを定義するすべてのパッケージは、これらの外部パッケージのどれかの中に存在しており、名前空間と同じように考えられている。名前空間はorg.openehr.namespaceの範囲で概念的に定義されており、他のパッケージとしてUMLでも表現できる。いくつかの実装技術(たとえばJava)では、org.openehrという名前空間はプログラムの中でも実際に使われている。 FIGURE 8 illustrates the package structure of the openEHR formal specifications. Three major packages are defined: rm, am and sm. All packages defining detailed models appear inside one of these outer packages, which may also be thought of as namespaces. They are conceptually defined within the org.openehr namespace, which can be represented in UML as further packages. In some implementation technologies (e.g. Java), the org.openehr namespace may actually be used within program texts. [[Image(package_structurea.gif)]] openEHRの重要な設計目的の一つは、科学や健康分野でのコンピュータ利用のために、一貫性があり、矛盾なく再利用可能なタイプのシステムを提供することである。したがって、参照モデル(ほぼ最下層に位置する)の「core」では参照モデルの上位層でも普遍的に利用できるIDやデータ型、データ構造や様々な共通のデザインパターンを提供しており、AMやSMパッケージでも同じように利用できる。[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Package/package_structure5.gif 図9]ではパッケージ間の関連が図示されている。依存関係は上位パッケージから下位パッケージに対してにのみ存在する。 One of the important design aims of openEHR is to provide a coherent, consistent and re-usable type system for scientific and health computing. Accordingly, the `core' of the RM (bottom-most layers) provides identifiers, data types, data structures and various common design patterns that can be re-used ubiquitously in the upper layers of the RM, and equally in the AM and SM packages. FIGURE 9 illustrates the relationships between the packages. Dependencies only exist from higher packages to lower packages. [[Image(package_structure5.gif)]] == 5.2 参照モデル(RM; Reference Modeldivision) == 5.2 Reference Model (RM) パッケージはそれぞれクラス定義のために局所的な文脈を定義している。[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Package/package_structure2.gif 図10]はRMパッケージの構造を図示している。略式の区分として、「domain」、「pattern」、「core」に分けられている。後者のグループのパッケージは、汎用的であり、すべての外部のパッケージに含まれているopenEHRモデル全部で利用されている。それと同時に、ID、知識資産へのアクセス、データ型や構造、セマンティクスへの見解、アーキタイプのサポートを提供している。前者のグループのパッケージは事業レベルでの医療情報タイプのセマンティクスを定義しており、EHRやデモグラフィックも含めている。 Each package defines a local context for definition of classes. FIGURE 10 illustrates the RM package structure. An informal division into "domain", "patterns" and "core" is shown. The packages in the latter group are generic, and are used by all openEHR models, in all the outer packages. Together, they provide identification, access to knowledge resources, data types and structures, versioning semantics, and support for archetyping. The packages in the former group define the semantics of enterprise level health information types, including the EHR and demographics. [http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Package/package_structure2.gif 図10]にあるそれぞれの外部パッケージは、「情報モデル」(IM; Information Model)について記載している1つのopenEHR仕様文書に対応している[[FootNote(with the exception of the EHR and Composition packages, which are both described in the EHR Reference Model document.)]]。パッケージ構造は、すべての実装表現(たとえば、XML スキーマ、JavaやC#、Eiffelといったコンピュータ言語やWSDLやIDL、.Netのような相互可用性のための定義)で繰り返されるような一般的なものである。 Each outer package in FIGURE 10 corresponds to one openEHR specification document1, documenting an "information model" (IM). The package structure will normally be replicated in all ITS expressions, e.g. XML schema, programming languages like Java, C# and Eiffel, and interoperability definitions like WSDL, IDL and .Net. [[Image(package_structure2.gif)]] === 5.2.1 パッケージ外観 === 5.2.1 Package Overview 以下のサブセクションはRMパッケージの簡単な概観を示すものである。 The following sub-sections provide a brief overview of the RM packages. ==== 支援情報モデル ==== Support Information Model このパッケージはほとんどの基本的概念が表現されており、他のすべてのパッケージでも必要とされるものである。Definition、Identification、Terminology、Measurmentパッケージから構成されている。これらのパッケージで定義されているセマンティクスは他の全てのモデルでIDを付与したり、用語体系や他の参照データといった知識サービスへアクセスするために利用可能である。支援パッケージは外部の型システムにどのような基本型があるのかopenEHRが想定しているものを記述しているassumed_typesという特別なパッケージが入っている。このパッケージはopenEHRモデルを実装技術の型システムに適切に統合するためのガイドである。 This package describes the most basic concepts, required by all other packages, and is comprised of the Definitions, Identification, Terminology and Measurement packages. The semantics defined in these packages allow all other models to use identifiers and to have access to knowledge services like terminology and other reference data. The support package includes the special package assumed_types, describing what basic types are assumed by openEHR in external type systems; this package is a guide for integrating openEHR models proper into the type systems of implementation technologies. ==== データ型情報モデル ==== Data Types Information Model 明確に定義された型タイプ一式によりが他の全てのモデルの根底となっており、全ての種類の医療情報で要求される汎用的で臨床特有の型を提供している。次のカテゴリーのデータ型は、データ型参照モデルで定義されている。 A set of clearly defined data types underlies all other models, and provides a number of general and clinically specific types required for all kinds of health information. The following categories of data types are defined in the data types reference model. * Text: プレーンテキスト、コード化されたテキスト,段落 * Quantities: 序数を含め、("+"、"++"、"+++"といった順序を表現する記号として使われるような)順序をつける型や、測定された量を示す値や単位など。 * Date/Times: 日付(date)、時刻(time)、日時(date-time)を示す型や、日時(date/time)No一部分を示す型。 * Encapsulated data:マルチメディアや構文解析できる内容 * Basic type: ブーリアンや状態変数 * Text: plain text, coded text, paragraphs. * Quantities: any ordered type including ordinal values (used for representing symbolic ordered values such as "+", "++", "+++"), measured quantities with values and units, and so on. * Date/times: date, time, date-time types, and partial date/time types. * Encapsulated data: multimedia, parsable content. * Basic types: boolean, state variable. ==== データ構造情報モデル ==== Data Structures Information Model ほとんどのopenEHRの情報モデルでは、汎用データ構造が特殊な構造をアーキタイプで定義される内容を表現するために用いられている。汎用構造は以下のようなものである。 In most openEHR information models, generic data structures are used for expressing content whose particular structure will be defined by archetypes. The generic structures are as follows. * Single: 単一のアイテム。身長や体重などの単一の値を持つもののために使われる。 * List: 病理検査結果などの名前のついたアイテムの線形リスト。 * Table: 表形式データ。名前がついていて順番に並べられた行と、名前がつくこともある列による無制限あるいは制限された大きさの表。 * Tree: 木構造データ。概念的にはリストのリストであるか、他の深い構造をもつもの。 * History: 時系列構造。各時点において、上記の構造型の一つにより表現されるどの複雑さを持つデータ構造の全てがとりうるもの。時点と間隔のサンプルがサポートを受けている。 * Single: single items, used to contain any single value, such as a height or weight. * List: linear lists of named items, such as many pathology test results. * Table: tabular data, including unlimited and limited length tables with named and ordered columns, and potentially named rows. * Tree: tree-shaped data, which may be conceptually a list of lists, or other deep structure. * History: time-series structures, where each time-point can be an entire data structure of any complexity, described by one of the above structure types. Point and interval samples are supported. ==== 共通情報モデル ==== Common Information Model いくつかの概念は高次パッケージにも再び現われる。LOCATABLEやARCHETYPEDクラスは情報とアーキタイプモデルの間をつなぐ働きがある。ATTESTATIONとPARTICIPATIONクラスは参照モデルのあちこちに出てくる汎用ドメインコンセプトである。特にデモグラフィックやEHRサービスで、change_controlパッケージは情報が以前どういう状態であったのかを示すことができるような更新管理について形式モデルを定義している。openEHRの更新管理の重要なセマンティクスについては[wiki:"Archtectural Overview Versioning" 45ページの第8章]に書かれている。 Several concepts recur in higher level packages. The classes LOCATABLE and ARCHETYPED provide the link between information and archetype models. The classes ATTESTATION and PARTICIPATION are generic domain concepts that appear in various reference models. The change_control package defines a formal model of change management and versioning which applies to any service that needs to be able to supply previous states of its information, in particular the demographic and EHR services. The key semantics of versioning in openEHR are described in section 8 on page 45. ==== セキュリティ情報モデル ==== Security Information Model セキュリティ情報モデルはEHRにおけるプライバシー条件やアクセス管理についてのセマンティクスを定義している。 The Security Information Model defines the semantics of access control and privacy setting for information in the EHR. ==== EHR情報モデル ==== EHR Information Model EHR情報モデルはEHR、COMPOSITION、SECTIONとENTRYの概念における文脈上のセマンティクスと制約について定義している。これらのクラスは主要な粗粒度のEHRコンポーネントであり、CEN EN13606:2005の同じ名前のクラスと直接対応している。ここでいう「段階(level)」はHL7(CDA) 2.0で同じ名前で扱われるものと非常に近い意味である。 The EHR IM defines the containment and context semantics of the concepts EHR, COMPOSITION, SECTION, and ENTRY. These classes are the major coarse-grained components of the EHR, and correspond directly to the classes of the same names in CEN EN13606:2005 and fairly closely to the "levels" of the same names in the HL7 Clinical Document Architecture (CDA) release 2.0. ==== EHR Extract情報モデル ==== EHR Extract Information Model EHR Extract情報モデルはEHR ExtractがCOMPOSITIONやデモグラフィック、EHRからのアクセス管理情報によりどうこう地区されルカに付いて定義している。数多くのExtractのバリエーションがサポートされていて、統合のためにCEN EN13606を使って単純な形式にした"full openEHR"や、openEHR/openEHR同期Extractもサポートされている。 The EHR Extract IM defines how an EHR extract is built from COMPOSITIONs, demographic, and access control information from the EHR. A number of Extract variations are supported, including "full openEHR", a simplified form for integration with CEN EN13606, and an openEHR/openEHR synchronisation Extract. ==== 統合情報モデル ==== Integration Information Model 統合モデルは、GENERIC_ENTRYクラスを定義している。GENERIC_ENTRYはENTRYのサブタイプであり、レガシーデータや外部データを木構造で表現するために使われている。このENTRY型自身も「統合アーキタイプ」として知られるアーキタイプを持っており,ツールを用いたデータ統合システムの基盤としての臨床アーキタイプと強調して用いることができる。[wiki:"Archtectural Overview Integrating openEHR" 14章の79ページ]に詳細が記載されている。 The Integration model defines the class GENERIC_ENTRY, a subtype of ENTRY used to represent free-form legacy or external data as a tree. This Entry type has its own archetypes, known as "integration archetypes", which can be used in concert with clinical archetypes as the basis for a tool-based data integration system. See section 14 on page 79 for more details. ==== Demographics情報モデル ==== Demographics Information Model デモグラフィックモデルはPARTY,ROLEや連絡先住所などの関連する詳細情報の一般概念を定義しており,アーキタイプモデルはPRTYモデルにセマンティクス上の制約を定義しており,person, organization, role, role relashonshipの全ての型の記述にアーキタイプを利用している。このアプローチでは、OMG HDTF PIDS標準で認められたデモグラフィック属性に柔軟性を持たせている。 The demographic model defines generic concepts of PARTY, ROLE and related details such as contact addresses. The archetype model defines the semantics of constraint on PARTYs, allowing archetypes for any type of person, organisation, role and role relationship to be described. This approach provides a flexible way of including the arbitrary demographic attributes allowed in the OMG HDTF PIDS standard. ==== ワークフロー情報モデル(未定義) ==== Workflow Information Model (future) ワークフロー(workflow)は臨床ケアの動的側面であり、取消しなどの処理のセマンティクスを表現するモデルでもあり、ガイドラインを実行した結果としてのケア処置も含まれる。 Workflow is the dynamic side of clinical care, and consists of models to describe the semantics of processes, such as recalls, as well as any care process resulting from execution of guidelines. === 5.3 アーキタイプモデル(AM; Archetype Model) === 5.3 Archetype Model (AM) openEHRのamパッケージにはアーキタイプとテンプレートのセマンティクスを記述するのに必要なモデルが含まれており,openEHRで使用されている。amパッケージには、openEHR(や他の医療情報をコンピュータで扱う目的)で使用するために、アーキタイプの文法仕様を表現する形式でありアーキタイプとテンプレートパッケージのオブジェクト指向セマンティクスを定義するアーキタイプ定義言語(ADL; Archetype Definition Language)や、アーキタイプとテンプレートパッケージ,アーキタイプパッケージで汎用アーキタイプモデルのprofileを定義しているopenehr_profileパッケージが含まれている。amパッケージの内部構造は[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Package/package_structure3.gif 図11]に示されている The openEHR am package contains the models necessary to describe the semantics of archetypes and templates, and their use within openEHR. These include ADL, the Archetype Definition Language (expressed in the form of a syntax specification), the archetype and template packages, defining the object-oriented semantics of archetypes and templates, and the openehr_profile package, which defines a profile of the generic archetype model defined in the archetype package, for use in openEHR (and other health computing endeavours). The internal structure of the am package is shown in FIGURE 11. [[Image(package_structure4.gif)]] === 5.4 サービスモデル(SM; Service Model) === 5.4 Service Model (SM) openEHRのサービスモデルでは、医療情報環境の基本的なサービスの定義がなされており、EHRの中心的な存在である。内容は図12に図示している。サービスの中には、間違いなく改良されていくものもはいっているので、この図では断定的なものとなってはいない。 The openEHR service model includes definitions of basic services in the health information environment, centred around the EHR. It is illustrated in FIGURE 12. The set of services actually included will undoubtedly evolve over time, so this diagram should not be seen as definitive. [[Image(package_structure3.gif)]] ==== バーチャルEHR API ==== Virtual EHR API バーチャルEHR APIはコンポジションやそれ以下のレベルでの細粒度のEHRデータインターフェースを定義している。アプリケーションが新しいEHR情報を作成することをできるようにしたり、既存のEHRについて部分的に問い合わせをしたり修正するようなことができるようにしている。このAPIを使えばアーキタイプによる細粒度のデー多相さが可能となる。EHRへの変更はEHRサービスを通じて実施される。 The virtual EHR API defines the fine-grained interface to EHR data, at the level of Compositions and below. It allows an application to create new EHR information, and to request parts of an existing EHR and modify them. This API enables fine-grained archetype-mediated data manipulation. Changes to the EHR are committed via the EHR service. ==== EHRサービスモデル ==== EHR Service Model EHRサービスモデルはEHRサービスの粗粒度のインターフェースを定義している。粒度のレベルはopenEHRのコントリビューションとコンポジションである。(例えば,更新管理やセットの変更インターフェース) The EHR service model defines the coarse-grained interface to electronic health record service. The level of granularity is openEHR Contributions and Compositions, i.e. a version-control / change-set interface. モデルのある部分はサーバ側の問い合わせのセマンティクスを定義している。たとえば、平均やある特定の条件の合致する患者IDのくみあわせなどの小さく集約された回答がえられるような大規模なデータ処理が発生するような問い合わせなどである。 Part of the model defines the semantics of server-side querying, i.e. queries which cause large amounts of data to be processed, generally returning small aggregated answers, such as averages, or sets of ids of patients matching a particular criterion. ==== アーキタイプサービスモデル ==== Archetype Service Model アーキタイプサービスモデルはアーキタイプのオンラインレポジトリに対するインターフェースを定義しており,人間が閲覧できるようにデザインされたGUIアプリケーションとしても、EHRのような他のソフトウェアサービスからアクセスするようにも利用できる。 The archetype service model defines the interface to online repositories of archetypes, and can be used both by GUI applications designed for human browsing as well as access by other software services such as the EHR. ==== 用語体系インターフェースモデル ==== Terminology Interface Model 用語体系インターフェースサービスは医療情報環境で利用できる全ての用語体型にアクセスするための全てのサービスに対する手段を提供する。用語体系にはICDxやICPCなどの基本的な分類についての語彙や、さらに進んだオントロジーベースの用語体系も含まれている。 The terminology interface service provides the means for all other services to access any terminology available in the health information environment, including basic classification vocabularies such as ICDx and ICPC, as well as more advanced ontology-based terminologies. Following the concept of division of responsibilities in a system-of-systems context, the terminology interface abstracts the different underlying architectures of each terminology, allowing other services in the environment to access terms in a standard way. The terminology service is thus the gateway to all ontology- and terminology-based knowledge services in the environment, which along with services for accessing guidelines, drug data and other "reference data" enables inferencing and decision support to be carried out in the environment. 1with the exception of the EHR and Composition packages, which are both described in the EHR Reference Model document.GUI applications designed for human browsing as well as access by other software services such as the EHR. Terminology Interface Model The terminology interface service provides the means for all other services to access any terminology available in the health information environment, including basic classification vocabularies such as ICDx and ICPC, as well as more advanced ontology-based terminologies. Following the concept of division of responsibilities in a system-of-systems context, the terminology interface abstracts the different underlying architectures of each terminology, allowing other services in the environment to access terms in a standard way. The terminology service is thus the gateway to all ontology- and terminology-based knowledge services in the environment, which along with services for accessing guidelines, drug data and other "reference data" enables inferencing and decision support to be carried out in the environment. 1 with the exception of the EHR and Composition packages, which are both described in the EHR Reference Model document. [[FootNote]] [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Design Principles" PREV] [wiki:"Design of the openEHR EHR" NEXT]