Structureの翻訳である。内容の正確性については保証しないので,適宜原文を参照してください。Overview​図8はopenEHR公式仕様のパッケージ構造を図示している。3つの主要なパッケージは、rm、am、smと定義されている。詳細なモデルを定義するすべてのパッケージは、これらの外部パッケージのどれかの中に存在しており、名前空間と同じように考えられている。名前空間はorg.openehr.namespaceの範囲で概念的に定義されており、他のパッケージとしてUMLでも表現できる。いくつかの実装技術(たとえばJava)では、org.openehrという名前空間がプログラムの中で実際に使われている。texts.openEHRの重要な設計目的の一つは、科学や健康分野でのコンピュータ利用のために、一貫性があり、矛盾なく再利用可能なタイプのシステムを提供することである。したがって、参照モデル(ほぼ最下層に位置する)の「core」では参照モデルの上位層でも普遍的に利用できるIDやデータ型、データ構造や様々な共通のデザインパターンを提供しており、AMやSMパッケージでも同じように利用できる。​図9ではパッケージ間の関連が図示されている。依存関係は上位パッケージから下位パッケージに対してにのみ存在する。(RM)パッケージはそれぞれクラス定義のために局所的な文脈を定義している。​図10はRMパッケージの構造を図示している。略式の区分として、「domain」、「pattern」、「core」に分けられている。後者のグループのパッケージは、汎用的であり、すべての外部のパッケージに含まれているopenEHRモデル全部で利用されている。それと同時に、ID、知識資産へのアクセス、データ型や構造、セマンティクスへの見解、アーキタイプのサポートを提供している。前者のグループのパッケージは事業レベルでの医療情報タイプのセマンティクスを定義しており、EHRやデモグラフィックも含めている。Model)について記載している1つのopenEHR仕様文書に対応している1。スキーマ、JavaやC#、Eiffelといったコンピュータ言語やWSDLやIDL、.Netのような相互可用性のための定義)で繰り返されるような一般的なものである。Overview以下のサブセクションはRMパッケージについて概要を簡潔に示すものである。Modelこのパッケージはほとんどの基本的概念が表現されており、他のすべてのパッケージでも必要とされるものである。Definition、Identification、Terminology、Measurmentパッケージから構成されている。これらのパッケージで定義されているセマンティクスは他の全てのモデルでIDを付与したり、用語体系や他の参照データといった知識サービスへアクセスするために利用可能である。支援パッケージは外部の型システムにどのような基本型があるのかopenEHRが想定しているものを記述しているassumed_typesという特別なパッケージが入っている。このパッケージはopenEHRモデルを実装技術の型システムに適切に統合するためのガイドである。Model明確に定義された型タイプ一式によりが他の全てのモデルの根底となっており、全ての種類の医療情報で要求される汎用的で臨床特有の型を提供している。次のカテゴリーのデータ型は、データ型参照モデルで定義されている。序数を含め、("+"、"++"、"+++"といった順序を表現する記号として使われるような)順序をつける型や、測定された量を示す値や単位など。日付(date)、時刻(time)、日時(date-time)を示す型や、日時(date/time)No一部分を示す型。ModelほとんどのopenEHRの情報モデルでは、汎用データ構造が特殊な構造をアーキタイプで定義される内容を表現するために用いられている。汎用構造は以下のようなものである。身長や体重などの単一の値を持つもののために使われる。病理検査結果などの名前のついたアイテムの線形リスト。名前がついていて順番に並べられた行と、名前がつくこともある列による無制限あるいは制限された大きさの表。概念的にはリストのリストであるか、他の深い構造をもつもの。おいて、上記の構造型の一つにより表現されるどの複雑さを持つデータ構造の全てがとりうるもの。時点と間隔のサンプルがサポートを受けている。Modelいくつかの概念は高次パッケージにも再び現われる。LOCATABLEやARCHETYPEDクラスは情報とアーキタイプモデルの間をつなぐ働きがある。ATTESTATIONとPARTICIPATIONクラスは参照モデルのあちこちに出てくる汎用ドメインコンセプトである。デモグラフィックやEHRサービスで、change_controlパッケージは情報が以前どういう状態であったのかを示すことができるような更新管理について形式モデルを定義している。openEHRの更新管理の重要なセマンティクスについては45ページの第8章に書かれている。Modelセキュリティ情報モデルはEHRにおけるプライバシー条件やアクセス管理についてのセマンティクスを定義している。ModelEHR情報モデルはEHR、COMPOSITION、SECTIONとENTRYの概念における文脈上のセマンティクスと制約について定義している。[EN13606:2005の同じ名前のクラスと直接対応している。EN13606:2005の同じ名前のクラスと直接対応している。2.0で同じ名前で扱われるものと非常に近い意味である。ExtractがCOMPOSITIONやデモグラフィック,EHRからのアクセス制御情報といったものから,どのように構築されるのかに付いて定義している。openEHR"や,openEHR/openEHR同期Extractもサポートされている。Model統合モデルは、GENERIC_ENTRYクラスを定義している。GENERIC_ENTRYはENTRYのサブタイプであり、レガシーデータや外部データを木構造で表現するために使われている。このENTRY型自身も「統合アーキタイプ」として知られるアーキタイプを持っており,ツールを用いたデータ統合システムの基盤としての臨床アーキタイプと強調して用いることができる。14章の79ページに詳細が記載されている。relashonshipの全ての型の記述にアーキタイプを利用している。PIDS標準で認められたデモグラフィック属性に柔軟性を持たせている。(future)ワークフロー(workflow)は臨床ケアの動的側面であり、取消しなどの処理のセマンティクスを表現するモデルでもあり、ガイドラインを実行した結果としてのケア処置も含まれる。(AM)openEHRのamパッケージにはアーキタイプとテンプレートのセマンティクスを記述するのに必要なモデルが含まれており,openEHRで使用されている。Language)や、アーキタイプとテンプレートパッケージ,アーキタイプパッケージで汎用アーキタイプモデルのprofileを定義しているopenehr_profileパッケージが含まれている。(SM)openEHRのサービスモデルでは、医療情報環境の基本的なサービスの定義がなされており、EHRの中心的な存在である。内容は図12に図示している。サービスの中には、間違いなく改良されていくものもはいっているので、この図では断定的なものとなってはいない。APIはコンポジションやそれ以下のレベルでの細粒度のEHRデータインターフェースを定義している。アプリケーションが新しいEHR情報を作成することをできるようにしたり、既存のEHRについて部分的に問い合わせをしたり修正するようなことができるようにしている。このAPIを使えばアーキタイプによる細粒度のデータ操作が可能となる。EHRへの変更はEHRサービスを通じて実施される。ModelEHRサービスモデルはEHRサービスの粗粒度のインターフェースを定義している。粒度のレベルはopenEHRのCONTRIBUTIONとCOMPOSITIONである。interface.モデルのある部分はサーバ側の問い合わせのセマンティクスを定義している。平均を求めたり,ある特定の条件の合致する患者IDのくみあわせなどの小さく集約された回答を得る場合のように,大規模なデータ処理が発生するような問い合わせなどである。Modelアーキタイプサービスモデルはアーキタイプのオンラインレポジトリに対するインターフェースを定義しており,人間が閲覧できるようにデザインされたGUIアプリケーションとしても、EHRのような他のソフトウェアサービスからアクセスするようにも利用できる。Model用語体系インターフェースサービスは医療情報環境で利用できる全ての用語体型にアクセスするための全てのサービスに対する手段を提供する。用語体系にはICDxやICPCなどの基本的な分類についての語彙や、さらに進んだオントロジーベースの用語体系も含まれている。システムのシステムという文脈で責任の分割という概念にならうと,用語体系インターフェースは各用語体系の基礎となるアーキテクチャの違いを抽象化し,標準的手法で用語にアクセスするための環境を他のサービスに提供するものである。その環境において用語体系サービスは,このようにオントロジーや用語体系をベースとした知識サービスへのゲートウェイとして働き,ガイドラインや薬剤情報など,そのほかの「参照データ」にアクセスすることができるサービスを提供し,推論を行ったり意思決定支援を実現するための環境を整えることができる。EHRの例外に伴いCopositionパッケージはいずれもEHR参照モデルドキュメントに記載されている。athttp://trac.edgewall.org/。