wiki:Archtectural Overview Aims

TOC PREV NEXT

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

3 Aims of the openEHR Architecture

この文書はArchtectural Overview3 Aims of the openEHR Architectureの翻訳である。内容の正確性については保証しないので,適宜原文を参照してください。

3.1 概要

3.1 Overview

このセクションではopenEHRアーキテクチャの基盤となる要件について簡単な概要を示す。openEHRアーキテクチャは,世界中にある数多くのプロジェクトや標準についての15年にわたる研究を具体化したものである。何年にもわたり集められた要件をもとに設計されている。

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に関する主な要望の一つは、ケアを共有するために統合された情報フレームワークによって提供される「統合されたケアの記録」である1

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.

openEHRによるアプローチの結果として、コンポーネントとアプリケーションは統合され、共有されたケア記録による要件を満たすために作成されており、(例えば)部分的な放射線記録システムとしても作成されている。

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.

GEHRからopenEHRへ発展させる間に重要であった要件のいくつかを,次のセクションで列挙する。主要な要件のいくつかについては図2に示した通りである。

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

openEHRの基本的かつ一般的なケア記録に対応する要件は以下の通りである。

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

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)

以下の要件はopenEHRがローカル健康記録つまり電子カルテに対して重視するものである

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

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.

ケアを共有するEHR

Shared Care EHR

以下の要件は統合的にケアを共有するEHRにおいてopenEHRが重視するものである。

  • 匿名化された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 診療での目的

3.2 Clinical Aims

診療でケアを行う上で具体的な見通しを持つため(記録を保持するという視点ではなく),以下の要件がopenEHRの開発の過程で明らかとなった。

  • 患者中心で,生涯にわたる健康記録。特定分野の問題を解決するという視点とは反対に患者の要求を全体的な観点から見通す視点が必要となる。意志決定支援技術や限定的に診断目的でも利用される。
  • 患者についての異なる見解(GP,救急や急性期ケア,病理,放射線,オーダーエントリーシステムなど)を利用できる膨大な知識資産(用語体系,臨床ガイドラインやコンピュータ化された資料類)をもって統合すること
  • 臨床における決断を支援して患者の安全性を高め,繰り返し行われる医学的調査のコストを減らすこと
  • 標準をもとにしたコンピュータアプリケーションにアクセスすること

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.

統合されたケアEHRには大きく期待されることがある。別々の環境でそれぞれ独立して示されていたコンピュータ化によるメリットを最大限利用し,一般化することである。これは要約すると以下のようなことである。

  • 相互作用や重複,不適切な治療などの医学的エラーにより引き起こされる不利なイベントやこれらに関連して上昇するコストを減らすこと
  • 重要な情報にタイミングよくアクセスすることができ,臨床家が情報を探す時間を減らすこと
  • コンピュータシステムに情報が伝わらずに見落としが起こるという患者インシデントを減らすこと
  • ローカルなコンピュータ環境では結果が利用できないために繰り返される患者についての診察や検査の重複を減らすこと
  • 質の高いEHRデータにより実現されうる予見的なリスク要因解析に基づいた早期発見により予防効果が増大すること
  • 患者の完全なEHRにアクセスする意志決定支援ツールを使って意思決定を向上させること
  • コンピュータ化された根拠に根差したガイドラインへのアクセスをサポートすること
  • 患者の基準を基にした効率的であるとされている,目標となる健康イニシアチブを増やすことができること
  • 入院期間や再入院を減らすことができること

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.

上記の多くを網羅するEHRに関する要件のわかりやすい説明がISO技術レポート180382であり,openEHRの概略にそって作られた3。上記の要件についてのまとめはopenEHR EHR情報モデルの文書に詳しく記載されている。

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 デプロイ環境

3.3 Deployment Environments

最終的に,すべてのソフトウェアと情報アーキテクチャはデプロイされたときにのみ提供される。openEHRのアーキテクチャはさまざまな種類のシステム構築を支援するために設計されている。統合的に共有されるケア記録においてもっとも重要なもののひとつは,図3に示している。

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.

この形式ではopenEHRサービスは既存のITインフラストラクチャに組み込まれ,患者のために数多くの医療従事者がそのコミュニティ内でそれを閲覧することができる安全な健康記録を共有することができる。openEHRを利用できるシステムはEMR/EPRの機能をその場所で利用することができる。全体として,システムにとって重要な部門はopenEHRを使い以下のことを実装することができる。

  • ケアを共有するコミュニティや地域における健康サービスのためのEHR
  • 国家,州,県などと同等の規模で集約化されるEHR
  • 小さなデスクトップ上のGPシステム
  • 病院の電子カルテ(EMR)
  • レガシーデータの浄化と検証を行うゲートウェイ
  • 携帯端末から患者がアクセスできるWebベースの安全なEHRシステム

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.
  1. The Integrated Care EHR is described in ISO/TR 20514 (2005)
  2. see http://www.openehr.org/downloads/ISOEHRRequirements.zip
  3. see http://svn.openehr.org/specification/TRUNK/publishing/requirements/iso18308_conformance.pdf

TOC PREV NEXT

Last modified 11 years ago Last modified on Feb 10, 2008, 11:46:30 AM

Attachments (2)

Download all attachments as: .zip