Principlesの翻訳である。内容の正確性については保証しないので,適宜原文を参照してください。openEHRの情報やサービス,そのドメインでの知識をモデル化するアプローチは以下に記述するような多くの設計原則を元にしている。これらの原則を適用することで,openEHRアーキテクチャモデルを分離することができ,高レベルのコンポーネント化ができるようになった。これにより保守性や拡張性,柔軟な配備が可能となった。Separationどのモデル化する体系でももっとも基本的な種類の特徴はオントロジーによる(例えば,現実世界の抽象化レベルなど)ものである。すべてのモデルはある種の意味論的内容を持つが,その意味するところは同じカテゴリーであっても同じではない。SNOMED-CT1用語体系は細菌感染の種類を体のどこの部位か,症候の種類はどうかで記述している。情報モデルは論理型の「量」を指定する可能性がある。内容モデルは内科医による出生後の診察で得られた情報のモデルを定義することができるかもしれない。これらの「情報」の型は質的に異なり,すべての生態系モデルとは分離して開発し,維持される必要がある。​図4はこれらの差異を図示し,どの部分がソフトウェアやデータベースとに直接構築されるかを示している。databases.この図では,情報のオントロジーを第一に分類して示している。情報の内容モデルと「現実のオントロジー」であり,表現と現象の分類ということでもある。これらの二つのカテゴリーは作者や表現,その目的の種類が完全に異なるために分離しなければならない。医療情報学では,用語体系や分類の開発が進められたためにこの分離は既に大きく存在している。classifications.情報側からの第2のオントロジー的分離は情報モデルとドメイン内容モデルの間にある。情報構造)に対応する。子の分離は一般にはあまり理解されていないが、歴史的には多くのドメインレベルセマンティクスがソフトウェアやデータベースに組み込まれており、比較的に維持できないようなシステムにも導入されている。systems.情報モデル、ドメイン内容モデル、用語体系の3つのカテゴリーを明確に分離することにより、openEHRアーキテクチャは明確で、限定されたスコープと、整理されたインターフェースをそれぞれに持つことができている。これにより、お互いの依存関係を制限することができ、維持しやすく、より適合性の高いシステムとなっている。ArchetypesopenEHRの基礎となっている重要なパラダイムの一つは、「2段階」モデリングとして知られている2。2段階アプローチでは、安定した参照情報モデルが第1段階のモデリングであり、さらに臨床内容をアーキタイプ形式やテンプレートで定義して構成することが第2段階のモデリングである。第1段階(参照モデル)をソフトウェアに実装するだけで、デプロイされるシステムと様々な内容で定義されるデータの依存関係を有意に減らすことができる。モデル全般の別の部分でさえも極めて安定した言語やモデルにより表現することができる(​図4の最下部)。結果として、システムは1段階のシステムよりもはるかに小さく、維持しやすいものとすることができる。将来に向けてアーキタイプとテンプレートを使って開発してくことで、システムはまた本質的に自己適応するものとなる。future.アーキタイプとテンプレートはまた、用語体系や分類、コンピュータ化された臨床ガイドラインに対してセマンティクスを与えるものである。過去には他の方法で、システムの機能を固有のソフトウェアと用語体系の組み合わせだけで構築しようと試みられていた。この手法には欠点がある。humans).openEHRでアーキタイプを使っていくことで、​図5のように情報とモデルの新しい関係を作り出すことができる。5.この図では、通常の情報システム(​図5一番左下)で知られているような「データ」は通常ではオブジェクトモデル(一番左上)に相当する。「旧来」の方法(例えばすべてのドメインセマンティクスがソフトウェアやデータベースのどこかでコード化されているようなもの)で開発されたシステムは、この種のアーキテクチャに限定されている。2段階モデリングを利用することにより、実行時のデータはアーキタイプとセマンティクスが一致し、参照モデルに対しても具体的に整合性を持つことになる。Language)で表現される。(ADL).アーキタイプやテンプレートがどのようにopenEHRで機能しているのか詳細については55ページのアーキタイプとテンプレートに記述されている。Engineering2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー(典型的には「ユースケース」法として知られている方法)による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、その設計を元に実装が進められ、引き続きテストとデプロイが行われ、最終的にはライフサイクルの維持期となる。この手法では相次ぐ変更による実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル(保存や問い合わせ、キャッシュなどの一般ロジックを含む)が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ(再利用可能)やテンプレート(ローカルでの利用)や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは​図6に示されている。このプロセスではIT開発者はデータマネジメントや相互可用性のための汎用コンポーネントに集中し、一方でドメインの専門家グループはソフトウェア開発プロセスから離れてシステムが実働する時に使われる定義を生成していくことになる。runtime.アプリケーションは完全に汎用なものとなりえないということは明らかであり(多くのデータを集めてそれを閲覧するソフトウェアは別として)、意思決定支援や業務管理、スケジュール管理など多くのアプリケーションはカスタマイズ工数が必要となる。そのようなアプリケーションもすべて、今ではアーキタイプとテンプレートによる開発プラットホームに依存させることができる。この手法による重要な結果はアーキタイプが技術に中立であり、ドメインのセマンティクスを単一のよりどころとして表現でき、セマンティクスの技術的表現を進めるために利用することができることである。ResponsibilitiesopenEHRで使われている第2の重要な設計パラダイムはコンピュータ環境における責任の分離である。複雑なドメインは機能性が関心の及ぶ広い範囲を最初に切り分けること(例えば「システムの中のシステム」)ができたときにだけ扱うことができる3。この原理はコンピュータサイエンスでは長い間「疎結合」、「カプセル化」、「コンポーネント化」として教科書的に理解されており、フレームワークや標準として大きな成果をあげている。OMGのCORBA仕様書やオブジェクト指向言語の発展、フレームワークやライブラリといったものがその成果でもある。機能性の各分野で、その分野を形式的に記述するモデルの組み合わせが重要なものとなっており、明確な情報システムやサービスに対応して一まとめに考えられている。service.​図7は丸で示された数多くのサービスによる医療情報環境を概念的に図示している。データのような)である。図で示したサービスを持つopenEHRはEHRやデモグラフィクをはじめととした中心的な仕様のためだけに現在は仕様を提供している。Extracts、サービスをベースとした相互可用性や日付/時間の形式や文字エンコードなどの多くの規格)があるため、openEHR仕様は既存の標準を統合する機構としてしばしば利用されている。ViewpointsopenEHRで使われている第3のコンピュータパラダイムは、責任の分離から当然の結果として導かれるもの、すなわち視点の分離である。責任がコンポーネントとして個々に分離された場合、a)それぞれが処理する情報や、b)それぞれがどのように通信するのかを定義する必要がある。RM/ODPモデルの2つの中心的な「視点」により構成される。following:エンタープライズ用途:ビジネス活動(たとえば、特定のシステムの目的や使用範囲、方針)に関連があるもの。情報:システムに保存されたり処理されるべき情報のセマンティクスに関連があるもの。constructed.したがって、openEHRの仕様は情報視点(openEHRの参照モデル)とコンピュータによる視点(openEHRのサービスモデル)を網羅している。工学視点はopenEHRの実装技術仕様モデル(83ページの実装技術仕様?を参照)に対応しており、技術的視点は用語体系や実際にデプロイされるときに使われるコンポーネントや技術に対応している。この部門の視点における重要な側面は、モデルの仕様と視点とが通常は1体1で対応していないということである。concept)の概念があったとする。情報視点では、それは多くのクラスを持つモデルとなるものである。コンピュータによる視点では、情報視点で定義される情報構造は、複数のサービスを繰り返すようなものであり、「健康についての指示書」サービスになりうるものでもあり、なりえないものでもある。コンピュータ視点で定義されるサービスの粒度は、事業あるいは地域の役割の分野に強く関連するものであり、情報視点でのコンポーネントの粒度は問題空間における精神的な概念の粒度に対応する。情報視点でのコンポーネントの粒度はより細かいものとなる傾向がある。athttp://trac.edgewall.org/。