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/)には、ソースが単一であることや草の根的なアプローチの必要性について、図示して説明しています。

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