HL7 FHIR：Fast Healthcare Interoperability Resources

この短い記事では、新しいHL7 FHIR（Health Level 7-Fast Healthcare Interoperability Resources）標準が登場した理由と、その過程で予想される困難について説明します。



そのため、開発者コミュニティ（たとえば、 こちら ）からの批判の結果として、また米国HITECH（経済および臨床健康のための健康情報技術）によるHL7v3の開発のための資金削減の可能性とともに、2011年1月にHL7理事会からの新しい傾向が示されましたHL7メッセージング標準をどのように改善できるか。 これにより、独立したHL7アーキテクトのグループの手（および創造性）が解放され、医療システムで情報を共有するための新しいアプローチが議論されました。



この新しいアプローチは、RESTfulの原則に基づいています。これは、第5章の偉大なロイトーマスフィールディングにふさわしいものです。 理論上（標準の開発者）、FHIRはHL7の実装を簡素化および加速するように設計されており、実装がはるかに簡単になり、同時に信頼性が高く、可能な限りオープンなインターネット標準に基づいています。



HL7v2とは大きく異なり、HL7v3とは異なり、FHIRのドキュメントには、すべてのアーティファクト（リソース）の実装例と、インターネットで利用可能なテストサーバーを含むさまざまなプラットフォーム上のサードパーティプロジェクトでの使用へのリンクが含まれています。 HL7グループは、HL7v3が死んだテクノロジーのゴミに捨てられることはないと主張し、FHIRはv3の経験に基づいて作成されたことを強調しています。



FHIR開発プロセス



HL7v2はアドホック手法（「神がそれを置く方法」とも呼ばれます）を使用して開発され、HL7v3はHDF（HL7開発フレームワーク）と呼ばれる堅牢なモデルベースのプロセスに従いましたが、FHIRは標準の開発（通常、沼地から沼地へと進んでいます）。 インクリメンタルアプローチの特徴は、単位時間あたりの標準の小片の開発であり、すぐにテストされ、成功した場合は開発プロセスに組み込まれ、その後プロセス全体が繰り返されます。



FHIRアーティファクト



FHIRは、蜂蜜データの交換でさらに活用するために、医療分野の主要なエンティティをリソースとして識別することを目指しています。 したがって、各リソースは、患者、個人、場所、組織など、明確に識別可能な個別のエンティティです。 hl7.org/fhirにあるFHIR仕様では、次のリソース属性について説明しています。



•リソースには、1つ以上の論理領域に対応する明確な境界が必要です。

•リソースは、使用の種類ではなく、意味が異なる必要があります。 そのため、ラボ分析の結果をさまざまに使用する可能性は、多くのリソースの作成につながるべきではありません。

•リソースには明確な識別子が必要です。

•リソースは、さまざまな医療/ビジネス分野で使用できるように、かなり一般的なエンティティを表す必要があります。

•リソースは、さまざまな医療/ビジネス分野での使用を妨げないように、具体的すぎたり、詳細すぎたりしてはなりません。

•リソースは相互に排他的である必要があります[ただし、そのように宣言されていますが、実際にはこれは表示されません。そのため、患者と人は何らかの方法で交換可能です。 おそらく、PatientリソースにPersonリソースへの参照としてperson要素が含まれていれば論理的でしょう。] [1]

•リソースは他のリソースを使用する必要がありますが、これは個々のリソースを構成するだけでなく、新しいコンテンツを作成する必要があります。

•リソースは、リソースの共通性とそれらが関連付けられている内容に基づいて、論理構造に編成する必要があります。

•リソースは、意味のあるコンテキストを提供するのに十分な大きさでなければなりません。 リソースに含まれる属性が2つしかない場合、ハニーデータの適切な表現を提供するには小さすぎる可能性があります。



この記事の執筆時点で、89のリソースが特定されており、この数は増加する可能性があります。 HL7消防士（FHIRman）は、最終的に約150のリソースがあると推定しています。 リソースの開発はv3と同様に実行されると述べられていますが、同時にリソースの表示は非常にシンプルなままです。 HL7v3では、リソースに類似した構造が長い間定義されており、CMET（Common Message Element Types）と呼ばれていることを思い出してください。 HL7v3の最初のバージョンでCMETの数が27であった場合、私の最新バージョン（NE 2014）では181でした。そこから、すべてのリソースがまだ定義されていないか、消防士がいくつかのCMETの本質を再考し、リソースをより効率的に開発したと結論付けることができます。



FHIR批判



FHIRなどのリソース指向の環境では、基本的なアーティファクトを実装し、あるシステムから別のシステムに転送して保存するのは非常に簡単です。 RESTアーキテクチャに精通している人なら誰でも、テストFHIRサーバーで数分でこれを行うことができます。 ただし、単純なリソースをどのように組み合わせて多数のリンクを持つより大きな構造にするかはまだ明確ではありません。 また、標準的なCRUD操作以外の診療所での作業プロセスのサポートについては何も言われていません。 これは実装の違いにつながり、HL7v2の例とHL7v3の例の両方で見たように、 相互運用性の欠如（言い換えれば、医療システムの互換性）につながります。



たとえば、コンポジションやバンドルなどの他のリソースのセットに関連するリソースは、標準ではかなり明確に定義されていますが、請求書などのより複雑な集計は記述されていません。 （これは標準で規定されるべきではないと言うことができますが、ビジネスプロセスの実際の実装の最初の週に同様の質問が表示されます。）この執筆の時点で、ドキュメントやメッセージなどの概念、および集計との違い（構成など） ）も明確に記述されていません。 さらに、FHIRはこれらすべてのメッセージをまったく必要としないと主張されています。 RESTアーキテクチャは別のアーキテクチャです。



ただし、このような批判は、標準の開発の枠組みで完全に解決可能であり、FHIRグループのメンバーのみに依存しています。 ただし、それらに依存しないのは外部要因であり、次のサイクルで追跡できます。



1.開発者は、現時点で考えられる最高の標準を作成しています（これは、HL7v2、HL7v3、CDA、およびFHIRの場合です）。 誰もが幸せで、誰もが幸せです。

2.しかし、さまざまな実装で標準を再現することはかなり難しい作業であり、ここでのポイントは、ほとんどの場合、使用されている技術ではありません。 個人データの保護、さまざまなグループの内部の政治的利益、投資利益率の実証などを考慮して、標準が組織の日常の仕事/ビジネスプロセスにどのように適合するかを示すことがはるかに重要です。 など

3.しかし、私たちは困難を恐れていません。したがって、誰もが標準の明るい未来のために戦うために1つとして利用します。 しかし、この道路はほとんどの場合最短ではなく、失望した人の死体が点在しています。 最強のものだけが残っており、多くの開発者は退屈しています。

4.外部要因との闘いにおいて、標準の開発者は、標準自体と連携するのに十分な開発ツールを作成する時間がない場合があります。 しかし、彼らは常に何かを改善したいので、彼らを取り始めます...彼らを取り巻く最も先進的なテクノロジーを見てください。

5.（true）ステップ＃1に戻ります。



この無限のサイクルの2番目のポイントが最も重要であることに気付くことは難しくありません。 FHIRを成功させるために、特に米国では、医療システムの分野の一部のモンスターは、開発者が客観的な理由（たとえば、財務コストの削減）のためにFHIRに切り替えることを期待して、HL7v2 / HL7v3およびFHIRをサポートするパラレルインターフェイスを実装することを決定する必要がありますインターフェイスのサポート）。 この観点から、多くの人がCerner CorporationのSMART-on-FHIRの開発を見ていると思います。 これには、Epic、Cerner、Meditech、McKesson、Mayo Clinicなどの有名なプレーヤーがサポートするArgonaut Projectが含まれます。 また、公開されたIHEプロファイルのドラフトバージョンであるMHD （健康文書へのモバイルアクセス）およびPDQm （モバイルの患者人口統計クエリ）にも興味があるかもしれません。



最後に、テストFHIRサーバーにふけるために、コードを書く必要さえありません。fhirtest.uhn.caは、HL7v2のHAPIを作成するのと同じ人で、現在はHAPI-FHIRです。



私の側では、FHIRに基づくHL7システムの典型的な（そしてそうではない）アーキテクチャについて、できれば「そうだった」という例とともに、fhirbaseの人たちからの話を見てみたいと思います。



それまでは、DOSで純粋なCで記述され、同じ年齢のメインフレームで動作するクライアントのインターフェイスをテストします。 FHIRからの煙は、金銭的にも技術的にも臭いがしません。 はい、HL7v2には非常に強力な非標準のアクセントがあります（目の波紋のZセグメントから）。



=====

1.患者と人、およびなぜFHIR DSTU2に表示されるのかについて、ロイドマッケンジーからコメント。 「 ほとんどのシステムはPersonを実装しません。Personは、Personレジストリを維持して、Patientレコード、Practitionerレコード、RelatedPersonレコード、または上記の組み合わせを可能にするシステムを対象としています。Patientに関する情報の多くは役割固有です。Personは役割に依存しません。 」