HL7v3とHL7 FHIRの比較

次の記事は、私の無料の翻訳比較です。HL7v3の短所とHL7 FHIR（Fast Healthcare Interoperability Resources）の長所を指摘しています。 記事「 The HL7 Games：Catching FHIR 」はBCホームズによって書かれました（その方法ですが、私は彼女を個人的に知らないため、「BC」という名前の意味を尋ねる方法はありませんでした）、抽象的な例ではなく、特にHL7v3について、またそのドメインとメッセージの多くを実装するという観点から知っています。 さらに、彼女はHL7v3 開発ツールの 1つのマネージャーでした。



この点に関して、記事には詳細が豊富に含まれているため、この分野での経験が少ない場合、またはv3にまったく精通していない場合、その内容を理解することは非常に困難です。 たとえば、XMLスキーマでRMIMモデリングツールとそれ以上のシリアル化を使用したことがない場合、クラスがActRelationshipsモデルで「componentOf2」と呼ばれ、XMLスキーマで「Component6」タイプであるときに名前付けの問題が発生する理由を理解することは困難です。 （たとえば、CMET COCT_RM360000UV01-MedicationOrder Universalで行われます。他の同様の例があります。「subjectOf1」のタイプは「Subject4」などです）



当然、BCホームズの記事全体を翻訳するつもりはありませんが、注意深く読んでください。 各コメントからの抜粋のみを以下に示し、FHIRがそれらを解決するために提供するものを示します。 私の記事の終わりに、1つの興味深い「面白い」があります。 私のコメントは、前回同様、角括弧で囲まれています。



それでは始めましょう。



当初、BCホームズは、カナダでHL7v3の多数の実装に参加した人にとっては、v3規格がほぼ普遍的に失敗していると考えられることは誰にとっても驚くべきことではないと主張します。 一般的な場合、私は、次の理由で規格が失敗したと主張します。



•HL7v3モデルとメッセージは、他のXMLベースのメッセージング標準よりもはるかに複雑です。

•より複雑で理解しやすいドキュメントを書くことで、この複雑さを排除することはできません。 実装ガイドは、UV [ ユニバーサル ]実装ドキュメント[ v3標準自体 ]、Canada Health Infowayのカナダ実装標準、特定の管轄区域または州の実装標準とガイドラインなど、さまざまなソースから接着する必要があります。

•HL7v3標準には、拡張機能を作成するための有用なモデルがありません。 したがって、特定の管轄区域のニーズに対する標準を「制約」する公式プロセスは、必要な目標をめったに達成しません。 最終的に、すべての管轄区域は、既存の医療プロセスを維持するために、公開された標準とはある程度異なる実装を行いました。

•HL7v3標準で定義されたデータ型は、HL7v3互換システムを実装するための多くの困難を提示します。 [ この記事でデータ型について書いた。 ]

•最後に、用語はかなり複雑な領域であることが証明されています。



次に、これらのステートメントをより詳細に検討し、ホームズを書き、FHIRがこれらの問題をどの程度解決するかを検討します。



難易度



HL7v3標準が複雑すぎるということは、現時点では既成事実として受け入れられるべきです。 この意味でのIntelliwareは、最初のPOSアプリケーションの1つを実装した後、2007年にこのことを予言した最初のCassandraでした。 それ以来、このエコーは他の開発者の間で何度も反応してきました。 そのため、v3の実装に遭遇したことがある人なら誰でも、その複雑さについて疑いの余地がないと確信しています。



典型的なv3メッセージのネストレベルを計算する際のこの複雑さを定量化する方法の1つは、原則として5〜10倍のXMLノードを持つことです。 ] Interactive Financial eXchange（IFX）やAmazon EC2 SOAP APIなど、他のXMLベースの標準よりも優れています。 ヘルスケアのビジネスプロセスは、金融分野、特に本の出版よりもはるかに複雑で、意味的に豊かだと言う人がいるかもしれません。 私の意見では、これは問題ではありません-XMLで提示されたHL7v2ベースのシステムをアップグレードした経験があります（ v2メッセージはスティックとキャップだけでなく、XML形式でも表すことができます）これをHL7v3に置き換えると、桁違いに複雑さが増していることがわかりました。 したがって、これはおそらくHL7v3の特徴的な機能です。 いずれにせよ、開発者は複雑さのレベルが以前に見ることができるすべてを超えるメッセージに直面しています。 [ v3のみを見た開発者が何を言ってから、別のものに切り替えたのだろうか。 おそらく、他のすべてはアスファルト上の2バイトのようになります。 ]



すべてのゴミ



HL7v3メッセージには、多くの不必要な「ジャンク」が含まれていることが多く、その最も顕著な例は、構造属性「moodCode」および「classCode」です。 99％の場合、これらの属性はメッセージでは意味をなしません。 FHIRでは、そのような属性がすべて船外に残されていたことに満足しています。



命名の問題



ジェームズ・アグニューはかつて、HL7v3がメッセージモデリング[ 私の記事What is HL7 ]の医療情報学者にとっての楽園であると考えられていたが、それは開発者にとって生き地獄になったと述べた。 ある意味で、モデリングプロセスは、前述のように不要な「ジャンク」の出現につながりました。 より深刻な問題は、v3メッセージ内のエンティティの命名方法です。



「処方」[ レシピ ]などの簡単な用語を検索しようとすると、その名前のメッセージまたはその一部を見つける可能性は低くなります。 「処方リクエストをアクティブ化する」など、似たようなものを見つけるかもしれませんが、このメッセージのエンティティの命名を慎重に検討する必要があります。その後、レシピが「併用薬リクエスト」という名前で隠れていることがわかります。



[ この記事では例を挙げていますが、その一部を記事の冒頭に掲載しました。 私自身に代わって、CDAを取得して追加することができます。たとえば、AssignedEntityなどの一部のクラスでは、addr属性がtelecomに先行しているのに対し、組織などの他のクラスでは同じ属性の順序が逆になっている、つまり 最初にテレコム、次にaddr。 XMLでシリアル化すると、要素の順序が重要になり、エラーが発生する可能性があります。 ]



幸いなことに、FHIRではリソースフィールドの指定を明確にすることが最も重要であり、「dob」のような単純で理解しやすいものでさえ、より国際的な「birthDate」に置き換えられています。



ネスティング



CDA文書とほぼ同じ方法で使用する必要があるv3臨床文書メッセージ[ これが何であるかは明確ではありません。他のモデルの不可欠な部分としての臨床意思決定支援、医療記録、別個の臨床声明など、同様のCDA構造を持つ標準がいくつかのドメインにあります。 ]。 HL7v3では、ドキュメントはメッセージの奥深くに隠されているため、非構造化データの構造を記述しようとする構造に画像またはPDFが埋め込まれます。 次に、このデザインは、著者、日付、患者に関するメタデータを含む別のデザインに埋め込まれます。 ネストはこれで終わりではありません。これらはすべて、コントロールアクトラッパー[ フルネームトリガーイベントコントロールアクトラッパー ]およびトランスポートラッパーと呼ばれる他のエンベロープに埋め込まれています。 さらに、通常、v3メッセージはそれ自体でSOAPメッセージにラップされます。 謎に包まれパズルの中に置かれたなぞなぞのように。



対照的に、FHIRの優れた機能の1つは、メッセージのフラットな表示です。 最も困難な場合でも、データは10レベル以下のネストであり、ほとんどの場合、メッセージのルートから5レベルです。 このようなフラットな構造は、データの重複も回避しますが、HL7v3では、メッセージのさまざまな部分でデータを何度も再現することができます。これは、治療プロセスに参加している医師や、処方箋で繰り返すことができる疾患データに特に特徴的です。



v3のさまざまなラッパーが最新のOAuth標準に置き換えられました[ これに精通した人がOAuthを使用する機能についてコメントするのは悪くありません ]。 複数のデータの問題である継続ポインタ（検索条件に一致する次の50人の患者を教えてください）でさえ、既存のAtom標準を使用して実装されます。



ドキュメント



ドキュメントを持つことはHL7v3の頭痛の種の1つでした。 他の技術でドキュメントが十分でないという問題がある場合、v3の場合は正反対です。多くのドキュメントが山ほどあり、多くの場合、さまざまな組織によって開発され、有料アクセスなどにより開発者がアクセスできないことがよくあります。



FHIRが行った重要なことの1つは、パブリックドメインのすべてのドキュメントをサイトに投稿することでした。 おそらくFHIRのドキュメントは実装を目的としているため、非常に具体的で詳細が豊富です。 [ さて、これまでメッセージングとドキュメントは非常に表面的に書かれてきました。 複雑なリクエストを行う必要がある場合は、URLですべてをブロックしないでください。メッセージングがはるかに良くなります。 ]



拡張性



一般に、HL7v3の世界では、専門家が医療システム間の何らかの相互作用を判断し、モデル交換形式（MIF）ファイルの形式で説明を作成します。 開発者はこのファイルを取得し、そこからメッセージを作成します。 [ 理論的に。 実際には、片手の指のようにMIFファイルを操作するためのツール。 ]多くの場合、元々メッセージに記載されていなかったデータを転送する必要があり、ここで問題が始まります。 [ 問題は、XMLスキーマを変更するときに、これらの変更をMIFで表示する方法も、自動化ツールも存在しないという事実からも始まります。 これにより、特定の実装に対して最初のMIFが規範的ではなくなります。 特に、同じ理由で、CDA MIFは投票版で提示されますが、標準版では欠落しています-CDAスキームが変更されたためです。 ]



おそらく、80/20ルールへの最初のコミットメントのため、FHIRには拡張機能を作成するための非常に優れたメカニズムがあります。 任意のリソースを展開できます。 拡張機能のキーと値の形式は単純です。 値は、単純なデータ型でも、ネストされた拡張機能による複雑なものでもかまいません。



拡張機能はFHIRで最も便利な機能の1つになると思います。



データ型



HL7v3の作業は、XMLなどの最新の標準が生まれる前に始まりました。 HL7v3メッセージはXML形式ですが、HL7v3はXMLと完全に一致することはありません。 データ型はこの一例です。 たとえば、HL7v3では、プリミティブデータ型ST（文字列）およびBL（ブール）が定義されていますが、これらはXML固有のデータ型とは大きく異なるため、商用開発ツールでの使用は困難です。



原始的なデータ型（ブール値、文字列、日付、URIなど）の苦い経験から教えられたFHIRは、XMLと同じものをすべて使用します。 より複雑なデータタイプ（アドレス、コーディング、数量、HumanNameなど）は、同じプリミティブデータに基づいています。 このようなデータ型の変更の副作用は、メッセージの検証とテストの可能性です。



用語



用語は、コード化された形式の特定の概念の表現です。 蜂蜜システムの実装にかなりの時間を費やして、概念のコーディング方法に関する決定に費やします。 ICD-10またはSNIOMED CTを使用して疾患を分類する必要がありますか？ そして、薬物を記録するにはDINまたはRxNormを使用しますか？ さらに、互換性を確保するために、システムの内部コードと外部辞書[ 同じSNOMED CT ] との関係を決定する必要があります。



FHIRは用語の使用にあまり行き過ぎていませんが、メッセージで特定のタイプのコードを使用することは避けています。



スティックと蓋



FHIRに基づいた十分に大きなソリューションが見つかるまで、FHIRがHL7 v2よりも実際の互換性をサポートする点で優れたソリューションであるかどうかはほとんどわかりません。 FHIRは、HL7 v2メッセージを最新のREST / JSONに置き換えるツールになるだけの場合があります。 それが起こったとしても、FHIRはHL7v2またはHL7v3よりも優れたソリューションであると述べます。



おわりに



その斬新さにもかかわらず、FHIRは、特にREST、JSON、OAuthなどの最新の標準に基づいて構築されているため、HL7v3よりも魅力的な代替手段のようです。 変なの？ ]。 したがって、組織には以下をお勧めします。

•環境でのFHIRの適用性を評価します。小規模な概念実証プロジェクトであっても、標準がニーズにどのように適しているかを理解するのに役立ちます。

•独自のAPIを発明するよりもFHIRを使用した方が良い。

•客観的な理由（既存のコード、v3のアクセスポイント）がない場合は、新しいプロジェクトでHL7v3を使用しないでください。

•HL7v2インターフェイスをFHIRに置き換えることを検討してください。



[ これで、BCホームズの記事を締めくくり、続いて私の記事を続けます。 ]



さて、今では約束の「興味深い」。 BCホームズのコメントに関するロイドマッケンジーのコメントがあります。 ロイドが誰なのかわからない、彼はHL7v3標準のアクティブクリエーターの1人、特に彼の発案であるRMIMデザイナーであり、使用前にFHIR標準を提出した3人の消防士（FHIR-man）の1人です。 彼が考えていることを聞くのはさらに面白いです。 できる限り正確にオリジナルに翻訳しようとします。なぜなら、 閉じられたCanada Health Infowayフォーラムへの彼の答えとそこからのアクセスは、そうではないようです。 明確にするために、ロイドはカナダにいるため、彼のコメントの一部はカナダでのv3の実装に関連しています。



「私は思う-[ ロイドを書いている ]-標準の「失敗」を分類する異なる方法がある。 少なくともある程度の互換性を実現することで、v3を（適切なレベルの時間と投資で）実装できることが正確に証明されています。 この観点から、標準は成功していると考えることができます。



ただし、成功を主張するのが難しい他の領域があります。

•市場サポートは当初の予想よりも限定的でした。 CDAに加えて、v3は大規模な国家資金プロジェクトに大きく限定されており、多大な資金と多くの時間と影響力がありました。

•互換性には非常に問題があります。 カナダ、英国、およびオランダは、v3ベースの薬物製剤を実装していますが、[ これらの実装間の ]相互運用性を実現するには、重要なメッセージ変換が必要です。 多少程度は少ないですが、カナダの州間でも同様の相互作用の問題が存在します。 それらのいくつかはさまざまな解決策によって引き起こされますが、それぞれの新しい要素の導入が互換性に違反するという事実は問題を複雑にするだけです。

•開発者の観点からは、HL7v3（またはCDA）との互換性を実装することの容易さ、速度、およびコストに熱心な人を見つけることはかなり困難です。 これを楽しんでいる人の中で、v3コンサルタントが最も頻繁に見つかります。 [ 特に、私のような人々、ロイドは書いています。 ]



私は実際にそれをモデル化するという点でv3が好きです。 結果は、非常に強力なモデリングツールです。 しかし、私は、そこから生まれた方法論と基準は、費やした投資に匹敵する結果をもたらさないという結論に達しました。



FHIRが万能薬になるとは言っていませんが、まだ開発中です。 しかし、トレーニングの複雑さ、過度に複雑なメッセージ、異なる開発者からのメッセージの違い、拡張メカニズムの欠如など、v3で発生するいくつかの問題をすでに解決できています。 さらに重要なことは、誰もが「そうである」と言うことができない環境、異なる開発者が例を見て、「まあ、それができる」と言う環境で、開発者の間でかなりの強さを獲得していることです。 これはv3で起こったことではなく、まれにCDAで起こったことです。



カナダのv3で既に行われた投資とFHIRがまだ規範的ではないという事実を考えると、既存の実装の移行について話すのは時期尚早でしょうが、新しい実装にFHIRを使用する可能性の調査を開始し、その場合に適しているかどうかを判断することはおそらく理にかなっています突然それに切り替えることにした場合。 （FHIRは、異なる管轄区域間でシステムの重要な互換性を確認する唯一の方法だと思います。）



最後に[ ロイドを書きます ]：

•多数のv3モデルと実装ガイドを作成し、世界中でv3をトレーニングし、いくつかのv3プロジェクトに参加しました。 私はv3コンサルタントとしてかなり上手になりました。

•今、私は多くの時間と雇用者の時間を費やし、自主的にFHIRに取り組んでいます。 [ さらに、ロイドは金銭的にはこれはほとんど役に立たないと嘆く。 ] FHIRを実装する人は、v3の場合のように深刻なサポートを必要としません。 一方、賢明な開発者ガイドの作成、利害関係者間のコンセンサスに到達するためのコンサルティング作業はまだ多くあります（結局、互換性とは、情報のどの部分を送信できるかについて利害関係者が同意することです）、用語集などです。



=====



実際には、これを完了することができます。 おそらく誰かが顕微鏡下で2つの基準を点ごとに比較することを期待していたのでしょう。 しかし、今日、FHIRは回答よりも多くの質問を提起しています。 現実ではありませんが、おもちゃではありませんので、比較することは非常に困難です。 （ベンダーのページで宣言されているように、Think！EHRがFHIRをサポートしている程度を示すために、IBSから誰も理解していません。）