wiki:openEHR Primer

openEHR入門

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の資金援助を受けてヨーロッパで行われたRICHEEDITHHANSAPICNICといった実装プロジェクトが元になっている。

モデル,データ,用語

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

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

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

ターミノロジーはアーキタイプやテンプレートといった技術を仲介して用いられる。これによりドメイン特有のモデル(例えば「血圧測定」、「理学所見」、「生化学検査結果」といったようなもの)をターミノロジーに中立的に定義することができ、必要に応じて複数のターミノロジーとモデルを関連付けることもできる。

EHRは少数の用語をそのモデルを利用するために開発を進めている(openEHRターミノロジーはこちらを参照。)

openEHRのアプローチ

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

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

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

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 available from the specification page; online UML.

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

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

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. The openEHR Archetype Model specifications are available from the specification page; online UML.

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

これはopenEHRのアーキテクチャではコンピュータで扱うという視点にたっている。サービスモデルは、EHRに関連したコンピュータ環境における主要なサービスを定義するものとして構成されている。これらのノウハウは、OMG CorbamedやCEN HISAにおいて実際行われた業績や実装経験に由来している。

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)

アーキタイプを基盤技術として実現されるhealth recordシステムはhealth recordに記載される概念や用語のセマンティクスを定義する語彙、ターミノロジーやオントロジーといった知識資産である。アーキタイプは複数のターミノロジーを利用することができ,どの自然言語でも利用できるものである。

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.

openEHRによって形式的構造の関係を以下に示す。

The relationship of the formal artefacts of openEHR is shown below.

クリックして拡大

アーキテクチャの概要("The Architecutural Overview")(PDF, HTML, 日本語参考訳)はopenEHRの技術的アーキテクチャの概要について良くまとめられた資料である。

The Architectural Overview (PDF, HTML) provides a good summary of the technical architecture of openEHR.

openEHRは医療をどのように改善するのか

参照モデルを使ってシステムを構築しているが、臨床モデルを別の表現で処理するというシステムを利用することについての効果はいくつかある。

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.

  • アーキタイプの変更がなければ、臨床データモデルの一部が変更されてもソフトウェアを変更しなくてすむので、ソフトウェアメンテナンスが減った
  • アーキタイプがEHRに入力される全てのデータを検証するのに用いられるため、データがより正当なものとなった。臨床からみても、データの信頼性が向上した。
  • システム間でデータが公開された参照モデルのインスタンスという標準に準拠してのみ通信するため、相互可用性が飛躍的に向上した。同様に、知識の相互可用性はコンピュータシステム間でアーキタイプを共有することで実現した。アーキタイプはデータの検証にも問い合わせにも利用することができる。相互可用性が向上したことにより、病院の中の臨床家や、地域のケアネットワークなどで情報を共有できる距離がひろがっていった。
  • 標準に準拠した。openEHRの参照モデルはISOやCEN EHR標準から発展したものであり,HL7やEDIFACTメッセージ標準とも相互可用性を持っている。これによりopenEHRベースのソフトウェアは他のソフトウェアやシステムと統合することが可能である。
  • 既存システムやレガシーシステムとの統合ができる。標準に準拠しているため,openEHRソフトウェアはデータの相互可用性ができるよく知られた標準規格を使用している多くのシステムと統合することができる。さらに、アーキタイプを用いて,レガシーなリレーショナルデータベースからコンバートして、その例外レポートを精製し,データの間違いを指摘することで「精製した」ものにすることができる。

つまり、臨床データはより正確なものとなり、より広範囲に共有することが出来,ソフトウェアはベンダーロックイン問題を回避することができる。全てにおいて、質の向上がなされ,医療における費用対効果を高めることにつながる。

  • 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.

セキュリティ、プライバシーと同意

診療情報に置けるセキュリティの要件は膨大なものになり、財務を含め他の種類のデータに対してよりも満たすことが難しいものとなっている。こうなっている理由の一つが、診療記録に関する大きく二つにわけられる利害関係者の要求が衝突し矛盾を生んでいることによる

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:

  • 臨床家: ケアの内容を共有するため、臨床かはより開かれたEHRを必要とする
  • 患者: プライバシーが必要となるため,より閉じられたEHRが好ましいと考える。
  • clinicians: to do shared care, clinicians need more open EHRs;
  • patients: need privacy, and are likely to prefer more closed EHRs.

健康情報の不適切な利用による潜在的な脅威は数多い。医師や患者が過去のデータを書換えることや、保険会社や雇用者が個人の健康に関する情報を仕事や契約方針の判断に利用することまで幅広く存在する。Ross Anderson'sBMA Security paperは脅威に関する問題や健康情報セキュリティに関連した解決策を掲載しており一読の価値がある。

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.

openEHRのセキュリティへのアプローチはBMAにより示された前提条件に準拠している(上記サイトより引用):

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.

セキュアな医療環境で実現したこの前提条件により、臨床家の情報に対するアクセスに関連した第2の前提条件が提示される:

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.

openEHRの仕様この前提条件の両方と、Andersonが論文に記載した原則にほぼ準拠している。特に,プライバシーに関する設定は、EHRの選択された部分に適用するものであり全てに対するものではない。

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.

標準

openEHR Foundationは高品質な医療情報やシステムの将来性を高めるには標準化は絶対的に重要であると考えているが、「仕様書だけ」の標準には欠陥があるとも考えている。標準は実装による検証と、広く認められたフィードバック経路による標準化プロセスを通じてのみ有用なものとなる。したがって、openEHRのメンバーはヨーロッパや(CEN TC/251)や国際的(HL7、ISO)な医療情報の標準化に関する仕事に深く関わっている。しかしながら、openEHRはさらに、標準に基づくだけでなく、実装の経験により完成されたよいモデリングや工業技術的原則によりシステムの仕様を策定している。これらの実績はすべて仕様に還元され、言うまでもなく標準そのものとして利用することもできる。

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.

アーキタイプ定義言語(ADL: Archetype Definition Language; ADL1.4仕様; ADL 2.0仕様)はopenEHRのメンバーにより書かれた形式のよい例であり、以前にCEN TC/251とHL7を採用していると表明されていたソフトウェアでアーキタイプやテンプレートをそれぞれ使用してテストされている。

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.

openEHR標準のページはこちらから閲覧できる。(ISO, CEN, HL7)

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

知的財産権とオープンソース

openEHRのオープンソースへのアプローチは単純である。相互可用性のためのコンポーネントはオープンソース形式で利用できるものでなければならず,仕様もまたオープンソース形式で利用できなければならない。これがソフトウェア産業のベンダが競争によってシステム間の相互可用性をなくしてしまうのではなく、可用性のあるコンポーネントで協同作業するための唯一の方法である。これにより、信頼性が高く相互可用性があり,オープンに開発され認定されたコンポーネントをシステムが持つことができ、ベンダはその代わりにアプリケーションやその基盤の質について競争している。

penEHR'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.

openEHRの仕様はオープンに利用することができ(openEHRの著作権表示のもので)、ソフトウェアもオープンに利用することができる(Mozilla "tri-license"の条件による)。詳細はライセンスのページを参照すること。

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.

研究と教育

執筆中。

to be continued

The openEHR Community

openEHRコミュニティは成長しつつあり,メーリングリストの登録者によって示されるように50ヶ国以上の数百人が参加している。興味を持った団体の参加を全面的に歓迎する。参加は無償であり自由である。現在の会員には、臨床、IT、教育、政府や個人的な参加などさまざまな背景を持った人が集まっている。

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.

Last modified 8 years ago Last modified on Mar 16, 2010, 9:24:51 AM

Attachments (4)

Download all attachments as: .zip