openEHR文書翻訳プロジェクト

# FHIRとopenEHRの違いについて

(この記事はThomas Beale氏によるブログ記事[FHIR compared to openEHR](https://wolandscat.net/2017/01/29/fhir-compared-to-openehr)を翻訳したものです）

![](openehrvfhir.png)

openEHRについて多くの個人や団体がこれまでの標準がどう違うのかについての質問を投げかけてきました。今日ではHL7 FHIRとopenEHRがどう違うのか、どんな関係があるのかというような質問が増えてきました。

この問題について時折考え直してみるのは楽しいことです。特にeHealthの標準の歴史について知りすぎていない一部の質問者の立場で考えてみるのは特に楽しいものです。この質問を理解するためには、いくつかの基本的な医療情報の概念に注目する必要があります。以下に私の回答を書いておきます。できるだけ客観的に回答しようとしましたが、私はいうまでもなくopenEHRの方を詳細についてFHIRよりもよく知っています。

## 相互運用性についての要求はどのように解決されますか？

従来から、システム内部はコントロールできないので、システム間で流れるデータ、たとえばメッセージを標準化の対象とする必要があると考えられてきました。それがHL7やEDIFACTなどの基本となる考え方です。この考え方は明確に定義された特定のデータすなわち、検査結果や処方箋では非常にうまく機能しています。まさに私がこれを書いている間にも、数百万のHL7 v2.3やv2.5のメッセージがいまだに多くのシステムから流れています。

しかし、私は以下のように（これはほとんどのopenEHR、13606やHL7 CIMIコミュニティも同意すると私が信じていることです）主張します。

* 過去20年間で、分散したeHealth環境を実現するためには、メッセージに格納される特定のデータセットよりはるかに広い範囲にわたって共有する必要があります。そして実際にそのセマンティクスは特定のベンダーによる製品の内部（たとえば画面の入力フォーム）や特定のメッセージフォーマットでさえ維持できないくらい複雑なものです。それらが意味するものはそれぞれの新しいフォーマット（UI表示、モバイルデータの取り込み、さまざまな文書フォーマットなど)や、技術（多様なデータベースやJavaScriptなど）で再現されなければなりません。

* データベーステーブルを画面に表示させることが多くのソリューションであった20年前とは違って、今日ではシステムを構築する人は内部データで必要となるセマンティクスについて熟知しています。

* そのドメインでのセマンティクスを理解する人々は、ITの人々ではなく、そのドメインの専門家であり、深い専門知識を持つ医療情報の専門家です（最近の[記事](https://wolandscat.net/2015/11/29/why-it-people-cant-build-information-systems/)でこのことについて書きました ）。

私の見解では、セマンティクスレベルでの相互運用性に関する仕様を策定するため唯一のスケーラブルな方法は、そのベンダーの製品や特定の通信フォーマットの外部で制作することです。これは、独自のフォーマットやツール、コミュニティにある既存のモデルを使った、 **単一のソースによるモデルベース**のアプローチを意味します。「モデル」の例としては、例えばICDx、SNOMED、ICFなどのターミノロジーです。 openEHRのアーキタイプやテンプレート、そしてHL7 CIMIのような他のグループによる機械処理可能なガイドラインや、医薬品集などもそうです。これらの多様なモデル（（openEHRののものを含む）には2つの重要な特性があります。

* そのドメインでのセマンティクスを理解する専門家によって直接作成されます。

* メッセージフォーマットを含む、任意の合理的なフォーマットに機械的に変換することができます。

![](layers_of_models_annot.png)

[セマンティックスケーラビリティについてのこの記事](https://wolandscat.net/2014/12/15/semantic-scalability-the-core-challenge-in-e-health/)には、ソースが単一であることや草の根的なアプローチの必要性について、図示して説明しています。

## 「システム理論」対「メッセージ理論」

上記の方法は相互運用性についての「システム」理論とされるものでしょう。セマンティクスはそのドメインで形式化され、システムやツールなどで使われる具体的な形（たとえばXSD、JSONベースの画面フォームなど）に機械的に変換され、メッセージやその他の保存形式としても利用されます。

相互運用性のメッセージ理論では、メッセージの （一般的な形式や通信プロトコルではなく）内容を標準化して、システムの適合要件とするか、または少なくともそのメッセージを通信チャネルの一部とします。この方法ではシステムからデータを取り出す一部の利用者から見るとよく機能する可能性がありますが、システム独自、あるいはモデルベースのセマンティクスを出力しようとするシステムにとっては、何らかの障害となりえます。標準化されたメッセージチャネル上で通信しようと準備するには、メッセージを作るために必要とされる構造と彼らのシステム内のデータを変換するためにプログラムを書かなければなりません。システム内のデータとメッセージは異なっていてもよく、それらの間でのマッピングは自明ではないこともありますが、**どのようなマッピングでも、パフォーマンスや正確性、患者の安全性へのリスクがあります**。メッセージとしてはデータセットが小さくシンプルなものであれば、問題はあまりないでしょうが、「何でも通信」することを可能にするためには非常に大きな問題を抱えることになります。

それでも、データをシリアライズして、それを特定の場所に届けなければいけないことがあります。システム理論では、モデルを最初に定義します。openEHRでは、ターミノロジーとの結合を含み、モデルから機械的に生成されてメッセージの定義ともなるテンプレートのことです。これは[RPCgen](http://linuxcommand.org/man_pages/rpcgen1.html)のころから実際に行われていたことで現在でもたいした作業ではありません。したがって、 モ**デルベースのエコシステムでは特定のメッセージは必要なく、一般的なメッセージ技術があればよい**のです 。この方法では、たった一つの形式だけが有効であるということではないと言うところに注目してください。データの受け渡しはXMLであっても、JSON,バイナリなど、あるいはPDFやOpenDocなどのような文書フォーマットでもよいのです。

したがって、 **相互運用性のこれら二つの理論では、それぞれ二つの異なる場所にモデルがあります**。openEHRが採用する「システム理論」では、モデルは製品や実際の通信フォーマットとは別の場所に置かれています。「メッセージ理論」では、特定の通信フォーマットの中にモデルが組み込まれています。

システム理論のやり方は技術的にはやや困難ですが、将来性もあり、よりスケーラブルです。メッセージ理論でやろうとすると、より手軽に成果を得ることができますが、フォーマットの変更が必要となったり、扱う内容が非常に大きくなった場合に問題に直面することになります。

メッセージ理論の限界については[最近のこの記事](https://wolandscat.net/2016/04/05/e-health-standards-beyond-messages/)にも書いています。

## 理想的な世界 - ユニバーサルモデル

eHealthの世界で最も理想的な方法は普遍的な臨床モデル(前に述べているとおり、「モデル」にはターミノロジーや、そのサブセット、アーキタイプ、テンプレート、ガイドラインなどを含みます)を開発することでしょう。そして、それらのモデルをシステムコンポーネントやデータベース、メッセージなどの資産として利用できるように構築するツールを開発することです。この理想的な方法についてはStan Huff先生により、2011年にCIMIが始まったときに[明確に示されています](http://opencimi.org/)。これは、私たちが90年代後半から考えてきたことであり、Stan Huff先生がIntermountain Healthcareで考えてきたことでもあります。そして、私達はずっと同じように探求していくことでしょう。（CIMIはいまはHL7技術委員会となっていますが、私はまだ同じような目的を持っていると考えています）。

言い換えてみると、「メッセージを送受信する」方法は、「モデルを構築」して、そして特定の状況に合わせたいずれかのメッセージあるいはそのほかのシリアライズ形式を生成することと同じこととなるでしょう。

しかしながら、国際標準における政治的力学やニーズの違い、それにともなう時系列やそのほかの多様な圧力によってこのモデル中心の手法は妨げられてきました。技術的に可能であり、現実に実装されていて世界的に使われているにもかかわらずです。

この種の作業にとって理想的な方法として、旧態依然とした標準化団体がやっているような「委員会により設計」されるものではなく、オープンソーススタイルでより開かれたプロジェクト形式（あるいは多くのプロジェクトによる共同作業)で開発を進めていく方法を私は提案したいと思います。そして、これがopenEHRで採用している方法です。

## 現実

私たちが実際に住んでいるこの世界では、物事はより複雑です。まず、人々はさまざまな課題を解決しようとしています。一つの課題は、これは統計的に間違いなくもっともよくある問題ですが、（一般的には契約であったり知的財産権といった理由で）使い続けなければいけないが、**中身がよくわからないシステム**があって、その限定的な商用インターフェースかRDBMSのテーブルから直接データを取り出すような課題です。もう一つの課題は、たとえば情報やその処理、業務規則や臨床支援システムなどのヘルスケアにおける新しい理解を組み込んだ新しい世代のシステムやコンポーネントを構築することです。これらの試みはそれぞれ別個の方法に対応しています。

eHealthの標準の世界では、HL7は15年間HL7 v3の開発を続けてきましたが（新しい技術をうまく取り込むことができずに複雑になりすぎましたが、HL7 v2は非常によく機能していました)、2012年よりFHIRの開発を始めました。

私たちはopenEHRで、上記の「システム」理論で開発し続けててきました。関連するEN 13606コミュニティや、より最近ではCIMIコミュニティは、同様の基盤で開発してきましたし、いうまでもないですが、IHTSDOや薬剤DBを提供する会社やさまざまなガイドラインを発効している会社は同じような基盤をもって開発してきました（つまり、これらの組織が提供する製品の内容は特定のベンダーの製品や通信フォーマットに依存していません）。

## FHIRと比べてopenEHRはどう違うのですか？

FHIRの主目的は、特定のシステムを仮定しない条件でシステム間（B2B）とシステムとアプリケーション（B2C）間の通信を解決することです。FHIRにおけるB2Bの部分は基本的に21世紀的なメッセージの方法です。 B2Cの部分はプログラミングに適したAPIを構築することが含まれ、要望の多くに対応しています。つまり、FHIRは現代的なeHealthアプリケーションを簡単に構築できるようにします。課題としては、APIを構築するためにはシステムが前提としているビジネスロジックや格納されるコンテンツが何かと言うことについて仮定するところから始めなければならないというところです。

openEHRの最初の目的は長期にわたってバージョン管理された患者についての記録を分散して機械可読な状態でデータを保存するという問題を解決することにあります。そして、それは将来性がありセマンティクスを有効に活用することができるプラットフォームアーキテクチャを開発することです。我々は、形式的セマンティクスに基づいたフレームワークで当然に得られる技術的成果として相互運用性について考えています。もちろん、openEHR自体では、単にこのようなプラットフォームの部分的な要素を提案しているだけで、ターミノロジーや、オントロジー、薬品データベース、サービス・インターフェースなどとあわせて使われるべきものであります。

### 技術的表現

FHIRは[「リソース」のライブラリ](http://build.fhir.org/resourcelist.html)（web-dataで用いられるmicro format) を定義しています。そして、技術的方法として「プロファイリング」と「拡張（extension)」(これらの用語は[FHIRのWebサイト](http://build.fhir.org/)ですべて定義されています）をローカライゼーションのために用意しています。言い換えれば、FHIRには開発中である水準に達した「臨床モデリング」がありますが、それはFHIR XMLマスター形式の内部で定義されたものです。リソースは、RESTのAPIを介してインスタンス化され、アクセスされるように設計されています。

openEHRには、[標準的な参照モデル](http://www.openehr.org/releases/RM/latest/docs/index)があり、アーキタイプやテンプレートターミノロジーのサブセットを含むさまざまな層にわたるモデルが上位にあります。openEHRの参照モデルは、全世界で通用する標準であり、内容にかかわらず全てのopenEHRデータを表現することができます。openEHRと他のADLベースのコミュニティでは、 モデルはメッセージやWebマイクロフォーマットとは切り離されており その代わりに、必要に応じていずれかのフォームに機械的に変換されます。このためより多くのツールをつかいます。たとえば、基本的なXML、JSON、 Googleの[ProtocolBuffers](https://developers.google.com/protocol-buffers/)形式など何でもよいのですがそれらを生成するツール群です。しかし、実際にはこれらのフォーマットについての具体的な好みは変化しつつあります。FHIRが開発されているこの5年間でXMLからJSONが主流となり、優先されるようになってきました。

[openEHRのアーキタイプ](http://www.openehr.org/ckm/)は[アーキタイプ定義言語（ADL）/アーキタイプオブジェクトモデル（AOM、ISO規格）](http://www.openehr.org/releases/AM/latest/docs/index)で表現されます 。ADLはまた、HL7 CIMIモデルを表現するものでもあります。ADLとAOMは、一般的なモデルを特定の形式やローカライズした形式に適応させることができるように、合成や特殊化、再定義することをサポートしています。

構築されたモデルのスタイルにも違いがあります。openEHRおよびその関連技術では、モデルは臨床医学分野の専門家のコミュニティでその要求に基づいて、要件、つまり「私たちが本当に望むもの」に基づいて設計されます。FHIRでは、レガシーシステムにあるデータのスーパーセットをモデルとして各FHIRリソースを生成して、開発者のニーズに直接応えていくことを基本的な戦略としています。これは、異なる結果につながる - FHIRのモデルは、開発者が直接利用することができるものではありますが、たとえばUIフォームの生成など異なる技術体系の元では簡単に再利用できません。openEHRではツールを使ってXSDやJSON、Xforms、そして開発者が必要とする任意のフォーマットを生成します。

さらにopenEHRでは、EHRを構築するための基板となる参照モデルを利用した張性の高い[EHRのための理論的基礎](http://www.openehr.org/releases/AM/latest/docs/index)があります。私はFHIRに同等のものがあるとは認識していません。そのため、FHIRをeHealthのインフラストラクチャとした場合の臨床プロセスにおける相互運用性で重要な問題となるのではないかと私は考えています。

最近の記事では[HL7とFHIRユーザーのためのopenEHRの技術的な基礎](https://wolandscat.net/2016/04/10/openehr-technical-basics-for-hl7-and-fhir-users/)についてFHIRについて興味がある人向けにopenEHRについて詳しく書いています。