wiki:openEHR Primer

Version 3 (modified by KOBAYASHI, Shinji, 12 years ago) (diff)

--

Table of Contents

    はじめに

    openEHR primerの内容を翻訳していきます。以下は参考訳であり内容についての責任はおいません。原文と照らしあわせて検討されてください。

    医療情報の現状

    医療情報システムは以下のような多くの重要問題に直面している:

    • 相互に利用することもできず,ベンダー依存となっている
    • 医療分野における情報がその大きさ,そして変更のスピードから維持することが難しくコストがかかること
    • セキュリティやプライバシー,同意に関するサポートがなされていないこと

    これらの欠点は広く認識されているが,それについての対応は容易ではない。膨大な量の医療情報が作り出されており,システムも多く構成も複雑であるからである。もちろん,解決するための銀の弾丸はない。しかしながら,openEHR Foundationはその問題を狭い意味でのITによる実現ということだけではなく,技術的モデリングやドメインモデリング,ソフトウェア工学といった統合フレームワークといった問題領域まで概念を再構築して解決法を提案する。次のセクションではopenEHRが考えていることについてもう少し詳しく解説する。

    The openEHR Foundation

    openEHR Foundationは医療情報システム(特にelectronic health record;電子的保健情報)のための公開された仕様や,ソフトウェアや知識源を開発するために創設された。その仕様や参照実装はオープンソースソフトウェアとして公開されている。「archetypes」とEHRを利用するための述語集についても開発している。

    The EHR

    openEHRでは「電子的保健情報」(electronic health record)の定義はISO/DTR 20514で定義されているIntegrated Care EHRに準拠している。

    • Integrated Care EHRは保健に関する情報をコンピュータ処理のできる形式で集積するものであり,安全に伝送と保管が行われ,認証を受けた複数の利用者がアクセスできるものであると定義されている。EHRシステムとは独立した論理的情報モデルとして一般的に認識されている。過去,現在,そして未来の情報が蓄積された質の高い統合された保健・医療の効率を向上させるために質の高い支援を継続的に行うというのが最初の目的である。

    実際の問題として,EHRは以下のような特徴を持つことが重要である。

    • 患者中心:EHRと診療の目的が一対一で対応し,医療機関で実施される各診療内容のエピソードとは対応しない。
    • 長期的:長期にわたるケアの記録であり,できれば誕生から死までを記録できること。
    • 包括的:全ての医療従事者や医療機関が患者に対して行う診療イベントを含むものであること。一つの専門分野だけに限定しない。言葉を変えると,EHRに記載されない重要な診療イベントがあってはならない。
    • 予見性:過去のイベントの記録だけではなく,計画,目的,指示,評価に関する判断材料となりうるように予見できる情報を持つこと

    健康情報の分散環境

    健康情報をコンピュータで分散処理する環境という概念はopenEHRの理念の大きな鍵となるものである。健康情報をコンピュータ処理する環境はモジュール化されていて,安全なものでありWebで利用できることが求められている。ここに無理なく配備することができる情報サービスの全容を模式化したがある。現在openEHRが考えている健康情報の分散環境の大部分は,OMG Corbamed taskforceの優れた業績や,Distributed Healthcare Environment(DHE)がEUの資金援を受けてヨーロッパで行われたRICHEやEDITH,HANSA,PICNICといった実装プロジェクトが元になっている。

    モデル,データ,用語

    健康情報システムは情報モデルを定義し,データベースやアプリケーションにそれを実装して臨床用語を付け加えることで構築される。しかしながら,生涯にわたって診療情報を共有される健康情報システムを陳腐化しないように構築するには,他にも要件がある。まず、求められる要件について適切なモデリングがなされなければならない。openEHRがベースとする要件は以下のものが含まれている。

    • GEHRプロジェクトの要件
    • オーストラリアGEHRプロジェクトのために書かれたEHRに関する技術的要件
    • Dr Dipak Kalraの博士論文で記述された数年に渡るヨーロッパでのGEHR開発での要件
    • Electronic Health Record Architecutureに関するISO 18308の要件

    openEHRの情報モデルはこれらの要求について何年もの間調査し、その実装について開発してきたものを基盤としており,これらのモデルはアーキタイプを主要な要素とする"two-lebel modelling"アプローチを本に開発されてきたモデルでもある(archtypes FAQ)。

    アーキタイプやテンプレートといった技術を用いてopenEHRで使われる用語は(例えば「血圧測定」、「理学所見」、「生化学検査結果」といったようなもの)ドメインモデルを適応して専門用語を尊重し、中立的に定義されており、必要に応じて複数の用語とモデルを関連付けることもできる。

    EHRは少数の用語をそのモデルを利用するために開発を進めている(openEHR用語,XMLで扱うことができるものはこちらを参照。)

    openEHRのアプローチ

    openEHRはElectronic Health Recordを以下の用語で規定する:

    1. 参照モデル(Reference model; RM)

    これはhealth recordそのものを記述するためのモデルであり,臨床のデータを含まない。参照モデルはフォルダやコンポジションのようなコンテナを扱うものである。コンポジションは文書よりも広い概念であるが,文書を含むものである。コンポジションの例をあげると,心電図レポート,カルテ,検査レポートや紹介状といったものである。コンポジションはEHRにおいて通信と実施の最小の単位である。openEHRの参照モデルの仕様はここにある。

    This is the model that describes the health record itself - not the clinical data that is contained within it. The reference model deals with containers such as Folders and Compositions. Compositions are a broader concept than documents - but include documents. Examples of Compositions are an ECG report, a progress note, a laboratory report and a referral. The Composition is the minimum unit of communication and committal to the EHR. The openEHR Reference Model specifications are here.

    1. アーキタイプモデル(Archetype Mode; AM)

    アーキタイプは有効なエントリーやセクション,コンポジションを記述するものである。これらはシステム間での連携を可能にするための形式的な方法として表現される。血圧を表すアーキタイプは血圧測定に関して臨床家がほしがるかもしれないすべての情報を記述するという意味があり,義務的な側面もある。SOAPアーキタイプは問題志向型の診療記録の各セクションを記述するものである。たとえば診断だけであれば,Aのセクションにしか記載してはならない。テンプレートは利用者の書式についての論理的モデルであり,特定の書式から集められたデータから用語を選択するアーキタイプとして記述される。

    Archetypes are descriptions of valid Entries, Sections and Compositions. These are expressed in a formal manner which enables them to be shared between systems. A blood pressure archetype represents a description of all the information a clinician might want to report about a blood pressure measurement, and may include some aspects which are mandatory. A 'SOAP' archetype describes the sections of a problem oriented health note and which entries are valid under each section - for example only diagnoses may be allowed under the 'A' section. Templates are logical models of user forms - and are described in terms of choices of archetypes whose data are captured on a particular form. See the Archetypes and Templates FAQ.

    1. サービスモデル(Service Model; SM)

    This is the computational viewpoint of the openEHR architecture. The service model consists of service definitions for the major services in the EHR computing environment. These are largely derived from existing work in OMG Corbamed, CEN HISA and implementation experience.

    1. Terminology and other Ontologies

    Underpinning archetype-enabled health record systems are knowledge resources such as vocabularies, terminologies and ontologies, which define the semantics of terms and concepts referenced in the health record. Archetypes enable multiple terminologies to be used, and in any natural language in which they are available.

    The Architectural Overview (PDF, HTML) provides a good summary of the technical architecture of openEHR. How openEHR can Improve Clinical Care

    The effects of using a system whose software is built on a reference model, but whose clinical models are represented and processed separately are several.

    • Software maintenance is reduced, since the software does not have to be changed every time the model of some clinical data changes - only the archetypes change.
    • Data validity is increased, because archetypes are used to validate all data input to the EHR. From a clinical point of view, data is more trustworthy.
    • Interoperability is vastly increased, because data are comunicated between systems only in terms of standard, open reference model instances, while knowledge interoperability is achieved by the sharing of archetypes between computer systems. Archetypes are used at both ends to validate and query the data. Wider interoperability improves the sharing of information among clinicians inside a hospital, in a community care network, and at larger distances.
    • Standards-based. The openEHR Reference Model is based on ISO and CEN EHR standards, and is interoeprable with HL7 and EDIFACT message standards. This enables openEHR-based software to be integrated with other software and systems.
    • Integration with Existing/Legacy? systems. Being standards-based, openEHR software can integrate with the many systems which use well-known data interoperability standards. Further, the use of archetypes enables data from legacy relational databases to be "purified" as it is converted, and exception reports generated, indicating errors in the data.

    In short, clinical data are more likely to be correct, is more sharable, and software is not subject to "vendor lock-in" - all leading to better quality and more cost-effective clinical care.

    Security, Privacy and Consent

    The security requirements of health data are likely to be greater, and more difficult to satisfy than for any other kind of data, including financial. This is partly because of the seeming paradox of conflicting needs of the two primary categories of health data stakeholders:

    • clinicians: to do shared care, clinicians need more open EHRs;
    • patients: need privacy, and are likely to prefer more closed EHRs.

    The potential threats to improper use of health data are numerous, and range from doctors and patients retrospectively modifying data, to insurance companies and employers making decisions on policies and jobs based on private health facts. Ross Anderson's BMA Security paper is worth a read on the subject of threats and solutions for secure health information.

    The openEHR approach to security rests on the same premise proposed by the BMA (quoted in the above paper):

    • Informed consent: patients have a right to expect that you [the clinician] will not pass on any personal information which you learn in the course of your professional duties, unless they agree.

    With this premise realised in a secure health environment, a second premise relating to clinician access can be stated:

    • Relevance of access: clinicians should only have access to the patient's health record if it can be established that they are currently engaged in provision of care for the patient, at the current time.

    The openEHR specifications assume both of these premises, and most of the principles described in Anderson's paper. In particular, privacy settings can be set on selected parts of the EHR, not just the whole thing.

    Standards

    The openEHR Foundation sees standards as vitally important in improving the prospects of high-quality health records and systems, but also sees "paper-only" standards as flawed. Standards are only useful with validation via implementation, and a recognised feedback path into the standards process. Accordingly, openEHR people are heavily involved in health standards work in Europe (CEN TC/251) and internationally (HL7 and ISO). However, openEHR does more: it produces specifications of systems which are based not just on standards, but on good modelling and engineering principles, and which are perfected over time by ongoing implementation experience. The results of all work are fed back into the specifications, which of course are available to standards bodies.

    The Archetype Definition Language (ADL; specification for ADL 1.3; ADL 2.0) is a good example of a formalism which was written by members of openEHR, and tested in software before being proposed for adoption by both CEN TC/251 and HL7 for use in their archetypes and templates standards respectively.

    The openEHR standards pages are available here: ISO, CEN, HL7.

    Open Source

    openEHR's approach to open source is simple: any interoperability component must be available in open source form, and so must its specification. This is the only way to get industry vendors together to cooperate on interoperability components, rather than competing by making their systems non-interoperable. The result is systems which contain trusted interoperability components, developed and certified in the open, and vendors who compete on quality of applications and infrastructure instead.

    All of openEHR's specifications are openly available (under the openEHR copyright notice), as is its software (under the Mozilla "tri-license"). See the licensing pagefor details.

    Research and Education

    to be continued

    The openEHR Community

    The openEHR community is a growing one, as evidenced by the numbers subscribed to the discussion lists - currently some hundreds, from over 50 countries. All interested parties are welcome to join - it's free. Current membership includes people from all backgrounds - clinical, IT, education, government and private individuals.

    Copyright © 2000-2004 openEHR®, All Rights Reserved.

    Attachments (4)

    Download all attachments as: .zip