次の記事は、電子ジャーナルJournal of Health Informatics 2010 Vol 5に掲載されているHL7およびopenEHR規格の比較（かなり表面的な）分析の無料翻訳です。 記事自体は、言うまでもないことですが、著者の1人によって親切に提供されましたが、出版物の制限により、追加の質問は控えました。
記事全体から、各標準のプラスとマイナスの側面のみが著者の観点から取られており、著者（著者）はopenEHRの支持者であり、読者がopenEHRにHL7よりも明確な利点があるという考えに導かれるべきです。
明らかに、何人の人がこれほど多くの比較を行っていますか（アダム・ボスワースの「 標準はどうあるべきか 」をご覧ください）、私にとっては、ソフトとグリーンの比較に似ています。 HL7とopenEHRには異なる目標があり、それらの開発は異なる原則に基づいており、それらの間で何らかの対応を識別できた場合、これはそれらが同等であることを意味しません。 それにもかかわらず、この比較が行われ、著者自身が標準（openEHR）を開発しているので、彼らの意見は興味深いはずです。 私の珍しいコメントは角括弧で囲まれています。 何かが完全に明確ではない場合は、ソースを参照することをお勧めします。多分あなたの翻訳がより良いでしょう。 また、この記事にはCDAとCEN EN13606のプラス面とマイナス面が含まれています。私の意見では、これらの比較はそれほど重要ではありません。 先祖の標準を参照してください。
Hl7v2
肯定的な側面：
•HL7v2標準のデータ型は非常に表現力があり、ランダムに構造化されたオブジェクトを送信できます。 その結果、HL7v2に基づく既存のインフラストラクチャを使用して、さまざまな意味的に豊富なデータを転送できます。 [これはHL7v3にはさらに当てはまりますが、そこには言及されていません。]
•以降のバージョンで追加されたセグメントは、基本的にユーザーが追加のセグメントを定義する必要を回避しました。
•使いやすさと広範な配布は、サードパーティベンダーのさらなる使用と比較的安価な実装に貢献します。 [比較には、白紙で始まる人は含まれません。]
マイナス面：
•メッセージセグメントの解釈におけるオプション性とあいまいさにより、普遍的な互換性が阻害されます;メッセージングを成功させるには、請負業者間の事前の合意が必要です。
•明示的なセマンティクスの欠如は、メッセージングを複雑にします。 標準でしっかりと記述されていることを除いて、セマンティックコンテンツを記述する手段はありません。 メッセージの異なる部分間の関係を確立することはできません。
•地域の実装は、限られた成功しか収めていません。 [そして、これは、使いやすさと幅広い配布に関する彼ら自身の声明とどのように一致していますか？]
•EMCに必要な機密性とアクセス権[同意構造]の問題。 [これらの問題は、たとえば、本体のHK7メッセージが送信されるSOAPで急落する可能性があります。]
•HL7v2発現ツールは、複雑な臨床試験のコーディングには不十分です。 [質問-複雑な臨床試験のメッセージを送信する必要がありますか？]
Hl7v3
肯定的な側面：
•柔軟で豊富なセマンティクスにより、医療のあらゆる分野を表現できます。
•この標準は、医療データで実際に発生する多くの問題（情報の欠如、不正確さ、記録の複製など）を解決します。
•HL7 RIMは、ハチミツの現実を記述するためのツールを提供しますが、用語またはオントロジーを使用してこれを行うワーキンググループに任されています。
•さまざまな開発ツールがあります。 [開発ツール（モデリングツール、統合ツール、XMLツール）の正確な意味は明確ではありません。]
•分析的意思決定システムで使用できます。
•「医療分野（米国）でのほとんどの作業はv3に基づいています。」[明らかにCDAおよび他のドキュメントテンプレートが意図されています。]
•HL7v3は、一度理解すればそれほど複雑ではなく、ほとんどの実装は標準のすべての微妙さを必要としません。 動的モデルは、HL7v2の同様のモデルほど複雑ではありません。 [より複雑ではないかもしれませんが、これは要求と応答では難しい場合がありますが、多くの場合、HL7v2に直接対応していません。]
マイナス面：
•v3スペシャリストの間でも、その目標に対する適合性に自信はありません。
•アラート、薬物チェックなど、多くの医療プロセスでv3に切り替えても、v2と比較して明らかな利点はありません。 つまり 投資収益率は十分に透明ではありません。 [繰り返しますが、白紙で始まる人はどうでしょう。]
•最初の規制に関する公開は2005年でしたが、それ以降、この規格は絶えず更新されています。 [実際には、これはあらゆる標準に適用されます。]
•v3メッセージの構造は非常に複雑で理解しにくいため、かなり長い学習プロセスが必要であり、この標準の専門家の数に影響を与えます。
•v2-v3マッピングは統合エンジンによって自動的に実行できると言うのは誤りです。v2メッセージの一部のフィールドはv3メッセージのフィールドと簡単に一致し、相互作用プロセス自体とその原因（トリガーイベント）は2つの標準で異なります。 [実際には、さらに悪いことに、マッピングを自動的に行うことはほとんど不可能です。v2とv3のメッセージのトリガーイベントは異なります。]
•v3メッセージからすべてのアーティファクトを受信することは、送信するよりもはるかに困難です。 v3メッセージの意味を分離するには、より多くの労力が必要です。 [これは、メッセージよりも複雑なセクションテンプレートを持つCDAに関連しています。 私の意見では、これはこの比較の欠点の1つにすぎません。 著者は常にメッセージとドキュメントを作成します。]
•RIMは、情報モデル（エンティティ-ドキュメント-エンティティ）と参照オントロジー（エンティティの説明としてのエンティティ）の不一致に悩まされています。 [ロシア語で説明してください！]
•RIMは行為と記録を混同し、文書自体はほとんど構造化されていません。 文書の階層はなく、文書間の関係を表現するための正式なモデルもありません。また、臨床の文脈でデータを表現する手段もありません。 [そして、ここに文書があり、ここにCDAから継承された文書テンプレート間の関係がありますか？]
•一部の定義は非論理的であり、「診断」、「評価」、「予後」などの概念はありません。 [PRPAドメイン全体はこれ専用であり、すべての概念がそこに存在します。]
•ドキュメント（CDA）とメッセージに含まれる情報の扱いは異なります。 文書は実際の声明を作成することを許可されていますが（物語のセクションではありますが）、メッセージでは観察法クラスの間接的な声明のみが可能です。 [多分、これらは異なる概念だからです。 CDAはHL7v3 NEドメインの1つにすぎません。]
•v3は、EMCの情報を保存するためのモデルとしては適切ではなく、規格自体はアーキテクチャモデルを記述しません（アーキテクチャではなく、システムの機能を記述するEHR-S FMをカウントしません）。 [これについては以前の記事で書いたので、繰り返しません。]
•v3 XMLメッセージのコンテンツは非常に低く（5％以下）、メッセージ自体は非常に大きくなります。
•モデルの複雑さとSNOMED CTなどの外部辞書との相互作用は、ステートメントを複数の方法で表現できることを意味しますが、メッセージ受信者にとっては、情報を同じ方法で解釈する独自の方法はありません。
•メッセージコンテンツのセマンティクスは、メッセージ自体のセマンティクスと混在しています。
•v3メッセージリポジトリをどのようにリクエストできるかは不明です。 [誰かがここで話していることを説明できますか？]
•HL7v3の設計は、ドキュメントの説明よりもプロセスの説明言語に近い。 これにより、ドキュメントとプロセスの関係が作成されます。ドキュメントのコンテンツは、それらに関連付けられたプロセス要件に制限されます。 [そしてASTM CCRについて話しましょう、その内容はそれが使用されるプロセスに限定されませんか？ CCRはHL7 CCDの前駆体です。 または、CDAドキュメントテンプレートのプロトタイプである他のHITSPドキュメント。]
•メッセージを実装するには、多くのリソースが必要です。 通信に関与するすべてのシステムで、メッセージは同じ方法で実装する必要があります。 [非常に奇妙な声明です。ロシア語で誰かとコミュニケーションをとれば、話し手が勉強するのに多くの時間を要するとしても、彼らもロシア語で答えることを期待しています。]
openEHR
肯定的な側面：
•モデルは直感的で、医師が理解しやすいものです。 通常、アーキタイプは理解、議論、設計が容易です。 使用される用語は、臨床記録と簡単に関連付けられます。
•使用されるアプローチは、医師の観察とこれらの記録の要求を記録するためのものです。
•モデルはISO / TS 13808に完全に準拠しています。
•リクエストはHL7v2メッセージで送信できます。 [おそらくHL7v3に転送してCDAに保存することもできます。]
•サブジェクト指向のセマンティクスは宣言型のアーキタイプと辞書にあるため、参照モデルは長期にわたって安定している必要があります。
•アーキタイプは、XSLTを使用してCDAに変換できます。
マイナス面：
•使用されるアプローチにはセマンティックな厳密さが欠けており、オントロジーも含まれていません。 参照モデルは、セマンティックの互換性の基礎を提供しません。臨床セマンティクスと概念間の関係を提示するには、別のモデルが必要です。
•アーキタイプ間の意味関係の十分なサポートを提供しません。 アーキタイプ内で、セマンティクスはこのアーキタイプの作成者によって決定されます。
•標準は、中規模および大規模システムの実装にはまだ使用されていません。
•十分な耐用年数にもかかわらず、標準は実際には普及していません。 [おそらく変更があったため、この記事は2010年に作成されました。]
•標準の仕様は安定しておらず、常に変化しています。 [彼女はどこへ行くのか。]
•相互接続され、論理的に重複しないモデルを作成するのはかなり問題です。 国内のリポジトリのセマンティックの重複と競合を回避するには、現在存在するものよりも高度な開発ツールが必要になる場合があります。
•SNOMET CTやISO 13606などの公式の標準開発者からのサポートは非常に弱いです。
大まかに言って、HL7とopenEHRは同じ分野に対して正反対のアプローチを使用しています。 HL7が彫刻家として機能し、RIMのブロックを取り、そこから余分なものをすべて切り離して、ある種の蜂蜜領域を表現している場合、システムがRIMの概念で動作できる場合、切り捨てられたRIMモデルで構築されたメッセージを解釈できることを意味します。 理論的には。 実際には、すべてがやや複雑です。
対照的に、openEHRはアーキタイプブロックを取得し、無制限の回数クローンを作成し、それらから仮想EHRを構築しようと試み、情報モデルに裏付けます。
HL7とopenEHRの比較分析
All Articles