wiki:Archtectural Overview Aims

Version 20 (modified by KOBAYASHI, Shinji, 14 years ago) ( diff )



3 openEHRアーキテクチャが目指すもの

3 Aims of the openEHR Architecture

3.1 概要

3.1 Overview


This section provides a brief overview of the requirements underpinning the openEHR architecture. The openEHR architecture embodies 15 years of research from numerous projects and standards from around the world. It has been designed based on requirements captured over many years.

アーキテクチャは極めて一般的あり,特にアーキタイプ駆動であるので,「clinical EHR」本来のコンセプト以外の多くの要件を満たしている。例えば,同じ参照アーキテクチャであれば、獣医学分野の保健や「ケア」においてさえも公共のインフラストラクチャや指定建造物として利用することができる。これは参照モデルが「ケアの対象に関連したサービスや管理イベント」に関連する概念のみを具象化しているという事実によるものである。ケアイベントやケア対象の種類を詳細に定義しているものがアーキタイプとテンプレートである。別の特徴として,openEHRによるEHRの要件の一つが「患者中心で長期にわたりケアEHRを共有できること」でありながら,これに限らず単に一時的な情報や専門家の立場からの情報も扱うことができる。例えば放射線部門の記録システムのようなものでも適用することができる。「health care record」のさまざまな意味合いに対する要件は二つの側面から分類することができる。図2に示すようにスコープと対象の種類である。

Because the architecture is highly generic, and particularly due to being archetype-driven, it satisfies many requirements outside the original concept of the "clinical EHR". For example, the same reference architecture can be used for veterinary health or even "care" of public infrastructure or listed buildings. This is due to the fact that the reference model embodies only concepts relating to "service and administrative events relating to a subject of care"; it is in archetypes and templates that specifics of the kinds of care events and subjects of care are defined. In another dimension, although one of the requirements for the openEHR EHR was a "patient-centric, longitudinal, shared care EHR", it is not limited to this, and can be used in purely episodic, specialist situations, e.g. as a radiology department record system. Requirements for various flavours of "health care record" can be categorised according to the two dimensions, scope, and kind of subject, as shown in FIGURE 2.

この図では丸で囲んだところが要件のセットを表しており,それらを囲んだ丸はそのすべての要件のスーパーセットになっている。ローカルに展開した場合に対象となる全ての種類のケアについての汎用記録に関する要件は左上の丸で囲んだ所にある。次に生きている対象つまりヒトという対象のために加えられた要件に対応するのは左下の図に丸で囲んだ部分である。左側の一番大きな丸で囲んだところに対応する要件は"local health records for human care"であり、放射線記録や病院の電子カルテシステムなどのようなものである。図を横断して横長の丸で囲んだところは,それに加えた仕様のセットでありケア記録を,まずすべての個別対象(患者中心で長期にわたる健康記録に現れる)から,公衆衛生の研究で利用されるような住民やコホートを対称にしたものまでにスコープを拡張していることに対応している。(人間を対象とした)保健という観点からすると重要な用件は図の一番下の行に展開されているすべての手法に対応するグループである。

In this figure, each bubble represents a set of requirements, being a superset of all requirements of bubbles contained within it. Requirements for a generic record of care for any kind of subject in a local deployment are represented by the top left bubble. The subsequent addition of requirements corresponding to living subjects and then human subjects is represented by the bubbles down the left side of the diagram. The requirements represented by the largest bubble on the left hand side correspond to "local health records for human care", such as radiology records, hospital EPRs and so on. Additional sets of requirements represented by wider bubbles going across the diagram correspond to extending the scope of the content of the care record first to a whole subject (resulting in a patient-centric, longitudinal health record) and then to populations or cohorts of subjects, as done in population health and research. From the (human) healthcare point of view, the important requirements groups extend all the way to the bottom row of the diagram.

図の下になればなるほど,ケアの対象の特異度が(「すべて」から「ヒト」へと)増加する。これはopenEHRではアーキタイプによってほとんど実装される。図を横切って要件は記録内容の範囲が(部分的なものから全体へと)ひろがり、さまざまな場所に配備されることで主に表現され、単独での利用から相互利用可能な形式として徐々に利用される。今日のEHRに関する主な要望の一つは、ケアを共有するために統合された情報フレームワークによって提供される「統合されたケアの記録」であるFootNote(The Integrated Care EHR is described in ISO/TR 20514 (2005))

Going down the diagram, requirements corresponding to increasing specificity of subject of care (from "any" to "human") are mostly implemented in openEHR by the use of archetypes. Going across the diagram, the requirements corresponding to increasing scope of record content (from episodic to population) are mainly expressed in different deployments, generally going from standalone to a shared interoperable form. One of the key aspirations for EHRs today is the "integrated care record" sought by many health authorities today1, which provides an informational framework for integrated shared care.


As a result of the approach taken by openEHR, components and applications built to satisfy the requirements of an integrated shared care record can also be deployed as (for example) an episodic radiology record system.


Some of the key requirements developed during the evolution of GEHR to openEHR are listed in the following sections, corresponding to some of the major requirements groups of FIGURE 2.


Generic Care Record Requirements


  • 患者とケアを行う者との関係に重きを置く。(たとえば記録の研究目的での使用よりも)
  • どのようなケアについての条件にも適応する(プライマリケア,急性期など)
  • 医療に関する法規を忠実であり,記録を遡及することができ,監査の手がかりを残していること
  • 技術とデータ形式が独立していること
  • 高度に維持しやすいものであり,柔軟なソフトウェアであること
  • 臨床データ構造をサポートしていること。リスト,表,時系列,ポイントと中間イベント

The openEHR requirements include the following, corresponding to a basic, generic record of care:

  • prioritisation of the patient / carer interaction (over e.g. research use of the record);
  • suitable for all care settings (primary, acute etc.);
  • medico-legal faithfulness, traceability, audit-trailing;
  • technology & data format independence;
  • highly maintainable and flexible software;
  • support for clinical data structures: lists, tables, time-series, including point and interval events.


Health Care Record (EPR)


  • 正常範囲とその他の単位系などを含む病理データのすべての側面をサポートすること
  • すべての自然言語をサポートし,その言語間での翻訳も同様に記録としてサポートすること
  • 任意の/複数の用語体系を組み込むこと。

The following requirements addressed in openEHR correspond to a local health record, or EPR:

  • support for all aspects of pathology data, including normal ranges, alternative systems of units etc.;
  • supports all natural languages, as well as translations between languages in the record;
  • integrates with any/multiple terminologies.


Shared Care EHR


  • 匿名化されたEHRを含めて患者プライバシーが守られること
  • データレベルや知識レベルでの相互歌謡性を持ってEHRを共有することを促進すること
  • CEN 13606やCorbamedといったメッセージングシステムと互換性を持つこと
  • 半分散された業務フローの支援を半自動的,あるいは自動的に行えること

The following requirements addressed in openEHR correspond to an integrated shared care EHR:

  • support for patient privacy, including anonymous EHRs;
  • facilitate sharing of EHRs via interoperability at data and knowledge levels;
  • compatibility with CEN 13606, Corbamed, and messaging systems;
  • support semi-automated and automated distributed workflows.


3.2 Clinical Aims


  • 患者中心で,生涯にわたる健康記録。特定分野の問題を解決するという視点とは反対に患者の要求を全体的な視点で見通す支店が必要となる。決断支援技術や限定的に診断目的でもあ利用される。

From a more specifically clinical care perspective (rather than a record-keeping perspective), the following requirements have been identified during the development of openEHR:

  • The need for a patient-centric, lifelong electronic health record that entails a holistic view of patient needs as opposed to niche problem-solving and decision-support techniques for limited diagnostic purposes;
  • Integration of different views of the patient (GP, emergency and acute care, pathology, radiology, computerised patient-order entry, etc.) with the vast body of available knowledge resources (terminologies, clinical guidelines and computerised libraries);
  • Clinical decision-support to improve patient safety and reduced costs through repeated medical investigations;
  • Access to standards-based computing applications.

The Integrated Care EHR holds great promise: to generalise and make widely available the benefits of computerisation that have been demonstrated individually and in isolated settings. These can be summarised as:

  • Reducing adverse events arising from medication errors such as interactions, duplications or inappropriate treatments and the flow-on costs associated with these;
  • Improving the timely access to critical information and reduced clinician time searching for information;
  • Reducing the incidence of patients being overlooked in the healthcare system due to information not being communicated;
  • Reducing the duplication of investigations and other tests and procedures due to results not being available in the local computing environment;
  • Improved prevention and early detection, based on predictive risk factor analysis, which is possible with quality EHR data;
  • Improved decision making through decision support tools with access to the patient's whole EHR;
  • Improving access to and computation of evidence based guidelines;
  • Increasing targeted health initiatives known to be effective, based on patient criteria; and
  • Reduced hospitalisations and readmissions.

One comprehensive statement of EHR requirements covering many of the above is the ISO Technical Report 183082 for which an openEHR profile has been created3. The requirements summarised above are described in more detail in the openEHR EHR Information Model document.

3.3 Deployment Environments

Ultimately any software and information architecture only provides utility when deployed. The architecture of openEHR is designed to support the construction of a number of types of system. One of the most important, the integrated shared care health record is illustrated in FIGURE 3.

In this form, the openEHR services are added to the existing IT infrastructure to provide a shared, secure health record for patients that are seen by any number of health providers in their community context. openEHR-enabled systems can also be used to provide EMR/EPR functionality at provider locations. Overall, a number of important categories of system can be implemented using openEHR including the following:

  • shared-care community or regional health service EHRs;
  • summary EHRs at a national, state, province or similar level;
  • small desktop GP systems;
  • hospital EMRs;
  • consolidated and summary EHRs in federation environments;
  • legacy data purification and validation gateways;
  • web-based secure EHR systems for mobile patients.

1The Integrated Care EHR is described in ISO/TR 20514 (2005) 2see 3see



Attachments (2)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.