[wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Aims" PREV] [wiki:"Archtectural Overview Package" NEXT] = 4 設計原則 = [[TOC]] 4 Design Principles この文書は[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/front.html Archtectural Overview]の[http://svn.openehr.org/specification/TAGS/Release-1.0.1/publishing/html/architecture/overview/Output/design_principles.html 4 Design Principles]の翻訳である。内容の正確性については保証しないので,適宜原文を参照してください。 openEHRの情報やサービス,そのドメインでの知識をモデル化するアプローチは以下に記述するような多くの設計原則を元にしている。これらの原則を適用することで,openEHRアーキテクチャモデルを分離することができ,高レベルのコンポーネント化ができるようになった。これにより保守性や拡張性,柔軟な配備が可能となった。 The openEHR approach to modelling information, services and domain knowledge is based on a number of design principles, described below. The application of these principles lead to a separation of the models of the openEHR architecture, and consequently, a high level of componentisation. This leads to better maintainability, extensibility, and flexible deployment. == 4.1 オントロジー的分離 == #ontology 4.1 Ontological Separation どのモデル化する体系でももっとも基本的な種類の特徴はオントロジーによる(例えば,現実世界の抽象化レベルなど)ものである。すべてのモデルはある種の意味論的内容を持つが,その意味するところは同じカテゴリーであっても同じではない。例えば,SNOMED-CT[[FootNote(See http://www.snomed.org)]]用語体系は細菌感染の種類を体のどこの部位か,症候の種類はどうかで記述している。情報モデルは論理型の「量」を指定する可能性がある。内容モデルは内科医による出生後の診察で得られた情報のモデルを定義することができるかもしれない。これらの「情報」の型は質的に異なり,すべての生態系モデルとは分離して開発し,維持される必要がある。[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles4.gif 図4]はこれらの差異を図示し,どの部分がソフトウェアやデータベースとに直接構築されるかを示している。 [[Image(design_principles4.gif)]] The most basic kind of distinction in any system of models is ontological, i.e. in the levels of abstraction of description of the real world. All models carry some kind of semantic content, but not all semantics are the same, or even of the same category. For example, some part of the SNOMED-CT[[FootNote(See http://www.snomed.org)]] terminology describes types of bacterial infection, sites in the body, and symptoms. An information model might specify a logical type Quantity. A content model might define the model of information collected in an ante-natal examination by a physician. These types of "information" are qualitatively different, and need to be developed and maintained separately within the overall model eco-system. FIGURE 4 illustrates these distinctions, and indicates what parts are built directly into software and databases. この図では,情報のオントロジーを第一に分類して示している。たとえば,情報の内容モデルと「現実のオントロジー」であり,表現と現象の分類ということでもある。これらの二つのカテゴリーは作者や表現,その目的の種類が完全に異なるために分離しなければならない。医療情報学では,用語体系や分類の開発が進められたためにこの分離は既に大きく存在している。 This figure shows a primary separation between "ontologies of information" i.e. models of information content, and "ontologies of reality" i.e. descriptions and classifications of real phenomena. These two categories have to be separated because the type of authors, the representation and the purposes are completely different. In health informatics, this separation already exists by and laubuntu x60srge, due to the development of terminologies and classifications. 情報側からの第2のオントロジー的分離は情報モデルとドメイン内容モデルの間にある。前のカテゴリー(情報モデル)はドメインと常に直交する(例えばコード化された用語のような基本的データ型や、IDやリストのようなデータ構造)セマンティクスに対応しているが、後者(ドメイン内容モデル)は実世界で起こる実際の現象(例えば、微生物による感染)というよりもむしろ、様々なドメインレベルの内容を表現するもの(情報構造についての表現、例えば「微生物学的検査」の情報構造)に対応する。子の分離は一般にはあまり理解されていないが、歴史的には多くのドメインレベルセマンティクスがソフトウェアやデータベースに組み込まれており、比較的に維持できないようなシステムにも導入されている。 A secondary ontological separation within the information side is shown between information models and domain content models. The former category corresponds to semantics that are invariant across the domain (e.g. basic data types like coded terms, data structures like lists, identifiers), while the latter corresponds to variable domain level content descriptions - descriptions of information structures such as "microbiology result" rather than descriptions of actual phenomena in the real world (such as infection by a microbe). This separation is not generally well understood, and historically, a great deal of domain-level semantics has been hard-wired into the software and databases, leading to relatively unmaintainable systems. 情報モデル、ドメイン内容モデル、用語体系の3つのカテゴリーを明確に分離することにより、openEHRアーキテクチャは明確で、限定されたスコープと、整理されたインターフェースをそれぞれに持つことができている。これにより、お互いの依存関係を制限することができ、維持しやすく、より適合性の高いシステムとなっている。 By clearly separating the three categories - information models, domain content models, and terminologies - the openEHR architecture enables each to have a well-defined, limited scope and clear interfaces. This limits the dependence of each on the other, leading to more maintainable and adaptable systems. === 2段階モデリングとアーキタイプ === Two-level Modelling and Archetypes openEHRの基礎となっている重要なパラダイムの一つは、「2段階」モデリングとして知られている[[FootNote(Beale T. Archetypes: Constraint-based Domain Models for Future-proof Information Systems. OOPSLA 2002 workshop on behavioural semantics. Available at http://www.deepthought.com.au.)]]。2段階アプローチでは、安定した参照情報モデルが第1段階のモデリングであり、さらに臨床内容をアーキタイプ形式やテンプレートで定義して構成することが第2段階のモデリングである。第1段階(参照モデル)をソフトウェアに実装するだけで、デプロイされるシステムと様々な内容で定義されるデータの依存関係を有意に減らすことができる。モデル全般の別の部分でさえも極めて安定した言語やモデルにより表現することができる([http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles4.gif 図4]の最下部)。結果として、システムは1段階のシステムよりもはるかに小さく、維持しやすいものとすることができる。将来に向けてアーキタイプとテンプレートを使って開発してくことで、システムはまた本質的に自己適応するものとなる。 One of the key paradigms on which openEHR is based is known as "two-level" modelling, described in [2]. Under the two-level approach, a stable reference information model constitutes the first level of modelling, while formal definitions of clinical content in the form of archetypes and templates constitute the second. Only the first level (the Reference Model) is implemented in software, significantly reducing the dependency of deployed systems and data on variable content definitions. The only other parts of the model universe implemented in software are highly stable languages/models of representation (shown at the bottom of FIGURE 4). As a consequence, systems have the possibility of being far smaller and more maintainable than single-level systems. They are also inherently self-adapting, since they are built to consume archetypes and templates as they are developed into the future. アーキタイプとテンプレートはまた、用語体系や分類、コンピュータ化された臨床ガイドラインに対してセマンティクスを与えるものである。過去には他の方法で、システムの機能を固有のソフトウェアと用語体系の組み合わせだけで構築しようと試みられていた。この手法には欠点がある。用語体系はドメイン内容の定義を含まず、元実世界の事実(例えば、微生物の種類とそれが人体に与える影響)をむしろ定義するものであるからである Archetypes and templates also act as a well-defined semantic gateway to terminologies, classifications and computerised clinical guidelines. The alternative in the past has been to try to make systems function solely with a combination of hard-wired software and terminology. This approach is flawed, since terminologies don't contain definitions of domain content (e.g. "microbiology result"), but rather facts about the real world (e.g. kinds of microbes and the effects of infection in humans). openEHRでアーキタイプを使っていくことで、[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles3.gif 図5]のように情報とモデルの新しい関係を作り出すことができる。 The use of archetyping in openEHR engenders new relationships between information and models, as shown in FIGURE 5. [[Image(design_principles3.gif)]] この図では、通常の情報システム([http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles3.gif 図5]一番左下)で知られているような「データ」は通常ではオブジェクトモデル(一番左上)に相当する。「旧来」の方法(例えばすべてのドメインセマンティクスがソフトウェアやデータベースのどこかでコード化されているようなもの)で開発されたシステムは、この種のアーキテクチャに限定されている。2段階モデリングを利用することにより、実行時のデータはアーキタイプとセマンティクスが一致し、参照モデルに対しても具体的に整合性を持つことになる。アーキタイプはすべて、一般的なアーキタイプ定義言語(ADL; Archetype Definition Language)で表現される。 In this figure, "data" as we know it in normal information systems (shown on the bottom left) conforms in the usual way to an object model (top left). Systems engineered in the "classic" way (i.e. all domain semantics are encoded somewhere in the software or database) are limited to this kind of architecture. With the use of two-level modelling, runtime data now conform semantically to archetypes as well as concretely to the reference model. All archetypes are expressed in a generic Archetype Definition Language (ADL). アーキタイプやテンプレートがどのようにopenEHRで機能しているのか詳細については55ページの[wiki:"Archtectural Overview Archetypes" アーキタイプとテンプレート]に記述されている。 The details of how archetypes and templates work in openEHR are described in Archetypes and Templates on page 55. === ソフトウェア工学のための結論 === Consequences for Software Engineering 2段階モデリングはシステム開発プロセスに大変革をもたらしている。通常のITを集約したプロセスでは、要件はユーザー(典型的には「ユースケース」法として知られている方法)による場当たり的な議論を通じて集められ、設計やモデルは要件から構築され、その設計を元に実装が進められ、引き続きテストとデプロイが行われ、最終的にはライフサイクルの維持期となる。しかし、この手法では相次ぐ変更による実装コストが高くなり、常にシステムの能力と要求の間に大きな差が開くことになるのが一般的である。このアプローチを使う限り、システムのユーザーとの場当たり的会話では、潜在的な内容やワークフローが明かになることはあまりないために苦しむことになる。2段階パラダイムでは、システムのコアの部分が極めて安定している参照モデルとアーキタイプモデル(保存や問い合わせ、キャッシュなどの一般ロジックを含む)が基礎となる。そこで、そのドメインでのセマンティクスはアーキタイプ(再利用可能)やテンプレート(ローカルでの利用)や用語体系(一般的に利用)を構築したそのドメインの専門家に委ねられている。このプロセスは[http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principles2.gif 図6]に示されている。このプロセスではIT開発者はデータマネジメントや相互可用性のための汎用コンポーネントに集中し、一方でドメインの専門家グループはソフトウェア開発プロセスから離れてシステムが実働する時に使われる定義を生成していくことになる。 [[Image(design_principles2.gif)]] Two-level modelling significantly changes the dynamics of the systems development process. In the usual IT-intensive process, requirements are gathered via ad hoc discussions with users (typically via the well-known "use case" methodology), designs and models built from the requirements, implementation proceeds from the design, followed by testing and deployment and ultimately the maintenance part of the lifecycle. This is usually characterised by ongoing high costs of implementation change and/or a widening gap between system capabilities and the requirements at any moment. The approach also suffers from the fact that ad hoc conversations with systems users nearly always fails to reveal underlying content and workflow. Under the two-level paradigm, the core part of the system is based on the reference and archetype models (includes generic logic for storage, querying, caching etc.), both of which are extremely stable, while domain semantics are mostly delegated to domain specialists who work building archetypes (reusable), templates (local use) and terminology (general use). The process is illustrated in FIGURE 6. Within this process, IT developers concentrate on generic components such as data management and interoperability, while groups of domain experts work outside the software development process, generating definitions that are used by systems at runtime. アプリケーションは完全に汎用なものとなりえないということは明らかであり(多くのデータを集めてそれを閲覧するソフトウェアは別として)、意思決定支援や業務管理、スケジュール管理など多くのアプリケーションはカスタマイズ工数が必要となる。しかし、そのようなアプリケーションもすべて、今ではアーキタイプとテンプレートによる開発プラットホームに依存させることができる。この手法による重要な結果はアーキタイプが技術に中立であり、ドメインのセマンティクスを単一のよりどころとして表現でき、セマンティクスの技術的表現を進めるために利用することができることである。 Clearly applications cannot always be totally generic (although many data capture and viewing applications are); decision support, administrative, scheduling and many other applications still require custom engineering. However, all such applications can now rely on an archetype- and template-driven computing platform. A key result of this approach is that archetypes now constitute a technology-independent, single-source expression of domain semantics, used to drive database schemas, software logic, GUI screen definitions, message schemas and all other technical expressions of the semantics. == 4.2 責任の分離 == #responsibility 4.2 Separation of Responsibilities openEHRで使われている第2の重要な設計パラダイムはコンピュータ環境における責任の分離である。複雑なドメインは機能性が関心の及ぶ広い範囲を最初に切り分けること(例えば「システムの中のシステム」)ができたときにだけ扱うことができる[[FootNote(Maier M. Architecting Principles for Systems-of-Systems. Technical Report, University of Alabama in Huntsville. 2000. Available at http://www.infoed.com/Open/PAPERS/systems.htm)]]。この原理はコンピュータサイエンスでは長い間「疎結合」、「カプセル化」、「コンポーネント化」として教科書的に理解されており、フレームワークや標準として大きな成果をあげている。OMGのCORBA仕様書やオブジェクト指向言語の発展、フレームワークやライブラリといったものがその成果でもある。機能性の各分野で、その分野を形式的に記述するモデルの組み合わせが重要なものとなっており、明確な情報システムやサービスに対応して一まとめに考えられている。 A second key design paradigm used in openEHR is that of separation of responsibilities within the computing environment. Complex domains are only tractable if the functionality is first partitioned into broad areas of interest, i.e. into a "system of systems" [6]. This principle has been understood in computer science for a long time under the rubrics "low coupling", "encapsulation" and "componentisation", and has resulted in highly successful frameworks and standards, including the OMG's CORBA specifications and the explosion of object-oriented languages, libraries and frameworks. Each area of functionality forms a focal point for a set of models formally describing that area, which, taken together usually correspond to a distinct information system or service. [http://www.openehr.jp/attachment/wiki/Archtectural%20Overview%20Design%20Principles/design_principlesa.gif 図7]は丸で示された数多くのサービスによる医療情報環境を概念的に図示している。典型的なつながりは実線で示されており、丸が中央に近ければ近いほど、臨床でケアを提供するために中核となる要求に対応したサービス(EHRや用語体系、デモグラフィック/個人識別、医学参照データのような)である。図で示したサービスを持つopenEHRはEHRやデモグラフィクをはじめととした中心的な仕様のためだけに現在は仕様を提供している。 FIGURE 7 illustrates a notional health information environment containing numerous services, each denoted by a bubble. Typical connections are indicated by lines, and bubbles closer to the centre correspond to services closer to the core needs of clinical care delivery, such as the EHR, terminology, demographics/identification and medical reference data. Of the services shown on the diagram, openEHR currently provides specifications only for the more central ones, including EHR and Demographics. [[Image(design_principlesa.gif)]] 多くのサービスのある側面で利用できる標準(用語体系や画像形式、メッセージやEHR Extracts、サービスをベースとした相互可用性や日付/時間の形式や文字エンコードなどの多くの規格)があるため、openEHR仕様は既存の標準を統合する機構としてしばしば利用されている。 Since there are standards available for some aspects of many services, such as terminology, image formats, messages, EHR Extracts, service-based interoperation, and numerous standards for details such as date/time formats and string encoding, the openEHR specifications often act as a mechanism to integrate existing standards. == 4.3 視点の分離 == #viewpoint 4.3 Separation of Viewpoints openEHRで使われている第3のコンピュータパラダイムは、責任の分離から当然の結果として導かれるもの、すなわち視点の分離である。責任がコンポーネントとして個々に分離された場合、a)それぞれが処理する情報や、b)それぞれがどのように通信するのかを定義する必要がある。このモデルの二つの側面は、以下に太字で示すISO RM/ODPモデルの2つの中心的な「視点」により構成される。 The third computing paradigm used in openEHR is a natural consequence of the separation of responsibilities, namely the separation of viewpoints. When responsibilities are divided up among distinct components, it becomes necessary to define a) the information that each processes, and b) how they will communicate. These two aspects of models constitute the two central "viewpoints" of the ISO RM/ODP model [4], marked in bold in the following: * エンタープライズ用途:ビジネス活動(たとえば、特定のシステムの目的や使用範囲、方針)に関連があるもの。 * '''情報''':システムに保存されたり処理されるべき情報のセマンティクスに関連があるもの。 * '''コンピュータによる''':システムを分散させることができるように、インターフェースとして仲介するオブジェクトの集合であるシステムの記述に関連があるもの * 工学:システムが分散していることを支援する機構に関連するもの * 技術的:分散したシステムを構築するコンポーネントの詳細に関連するもの * Enterprise: concerned with the business activities, i.e. purpose, scope and policies of the specified system. * Information: concerned with the semantics of information that needs to be stored and processed in the system. * Computational: concerned with the description of the system as a set of objects that interact at interfaces - enabling system distribution. * Engineering: concerned with the mechanisms supporting system distribution. * Technological: concerned with the detail of the components from which the distributed system is constructed. したがって、openEHRの仕様は情報視点(openEHRの参照モデル)とコンピュータによる視点(openEHRのサービスモデル)を網羅している。工学視点はopenEHRの実装技術仕様モデル([wiki:"Implementation Technology Specifications" 83ページの実装技術仕様]を参照)に対応しており、技術的視点は用語体系や実際にデプロイされるときに使われるコンポーネントや技術に対応している。この部門の視点における重要な側面は、モデルの仕様と視点とが通常は1体1で対応していないということである。例えば、事業視点での「健康についての指示書」(CEN ENV13940 Continuity of Care concept)の概念があったとする。情報視点では、それは多くのクラスを持つモデルとなるものである。コンピュータによる視点では、情報視点で定義される情報構造は、複数のサービスを繰り返すようなものであり、「健康についての指示書」サービスになりうるものでもあり、なりえないものでもある。コンピュータ視点で定義されるサービスの粒度は、事業あるいは地域の役割の分野に強く関連するものであり、情報視点でのコンポーネントの粒度は問題空間における精神的な概念の粒度に対応する。情報視点でのコンポーネントの粒度はより細かいものとなる傾向がある。 The openEHR specifications accordingly include an information viewpoint - the openEHR Reference Model - and a computational viewpoint - the openEHR Service Model. The Engineering viewpoint corresponds to the Implementation Technology Specification (ITS) models of openEHR (see Implementation Technology Specifications on page 83), while the Technological viewpoint corresponds to the technologies and components used in an actual deployment. An important aspect of the division into viewpoints is that there is generally not a 1:1 relationship between model specifications in each viewpoint. For example, there might be a concept of "health mandate" (a CEN ENV13940 Continuity of Care concept) in the enterprise viewpoint. In the information viewpoint, this might have become a model containing many classes. In the computational viewpoint, the information structures defined in the information viewpoint are likely to recur in multiple services, and there may or may not be a "health mandate" service. The granularity of services defined in the computational viewpoint corresponds most strongly to divisions of function in an enterprise or region, while the granularity of components in the information view points corresponds to the granularity of mental concepts in the problem space, the latter almost always being more fine-grained. 1See http://www.snomed.org [[FootNote]] [wiki:"Archtectural Overview index" TOC] [wiki:"Archtectural Overview Aims" PREV] [wiki:"Archtectural Overview Package" NEXT]