HL7メッセージを使用する場合、どのような問題が発生する傾向がありますか？

私はヘルスケア事業向けの製品をテストしていますが、HL7メッセージを使用しています。HL7の問題について別の質問でうめき声をあげているが、詳細については言及していない。誰かが私たちが特に探しているべき問題や問題のクラスのアイデアを教えてもらえますか？

解析によく使用されるライブラリを使用しています。これらの詳細や私たちがやっていることが役立つ場合は、コメントで知らせてください。できれば質問に追加します。

testing parsing hl7

— エセル・エヴァンス
ソース

回答:

HL7 v2.xを扱っていると思います

HL7は自発的に非常に柔軟です。これには大きな利点がありますが、課題も生じます。留意すべき基本的なルールは、すべての実装が異なることです。2つの異なる環境（たとえば2つの病院）にまったく同じ製品を展開する場合、データ交換ルールはおそらく異なるでしょう。相互作用するHL7インターフェイスの数をスケーリングできるようにするには、製品がこれらの隠された要件を満たす準備ができている必要があります。

HL7を扱うほとんどの医療システムでは、次の共通の課題の部分的なリストに直面しています。

各システムは、各データの意味を解釈できます。また、コンテキストとワークフローはセマンティックに影響を与える可能性があります。アカウント番号（PID.18）または訪問番号（PV1.19）を使用して、いくつかの臨床ワークフローに準拠する患者を特定するシステムを見ました。このタイプのセマンティックギャップは、おそらく、システムがこのデータを処理する方法を受信する方法に何らかの影響を与えます。
必須とオプション：いくつかの異なるコンテキストでいくつかの目標を達成するためにデータを交換できるため、ほとんどのセグメントとフィールドは公式ドキュメント（および一部のパーサー）でオプションとしてドキュメント化されています。ただし、特定のワークフローを満たすために、ヘルスケア製品はおそらくデータ制約ルールを追加し、他のいくつかを緩和します。ほとんどの場合、ケースバイケースの分析を行ってそれらを特定する必要があります。
表：HL7は、いくつかのフィールドの推奨値のリストを提供します。たとえば、性別の推奨値リストは6です...明らかに、ほとんどのシステムは6つすべてを実装していませんが、前もってサポートしていないものを受け取った場合のマッピング戦略は何ですか？
セグメントとフィールドをカスタマイズできます：フィールドの長さ、データ型、およびその他の定義属性をカスタマイズできます。重要な情報を失うことなく、既知のデータ構造にマップする必要があります。

jlmorin

www.caristix.com

— jlmorin
ソース

私が遭遇したいくつかの問題：

組織によっては異なるバージョンのHL7を使用する場合があるため、互換性の問題（「横断歩道」）が発生します。組織間でのデータ転送に関与する場合、確かにこれに遭遇します。
セマンティック標準はありません（v2.xの場合、v3はこれに対処し始めたと思われます）。したがって、特定のフィールドにどのデータを含めるべきかを知っていたとしても、それらのバイトの正確な意味や表現はわかりません。
HL7は非標準の標準です。Z-segments広く使用され、完全にプロプライエタリなベンダー固有をサポートします。
HL7 v2.x（xの多くの値はまだ野生で使用されています）は非XML独自の形式であるため、それを使用するにはHL7パーサーが必要です。（これは、すでに他の人のためにそれを含むHL7解析ライブラリを既に持っているので、あなたは知っています）

— G__
ソース

それらの最悪は、セマンティクスの欠如です。標準を書いている人々でさえ、「XまたはYを送ることができますが、Zも有効です」と言うとき、あなたは問題を抱えていることを知っています。節約できるのは、パーサー以外の誰もHL7オプションの全範囲を処理する必要がないことです。誰もが実際に顧客が受け取った小さなサブセットを処理します。つまり、新しいアクセプターを作成することは、「標準を実装する」演習ではなく、発見のプロセス（今のところ説明していること）です。ああ、希望する効果を得るために送信する必要があるオプションを推測します。

@ +1の回答、そして私はOP（私）以外の人の情報を含めるために+1を与えることができました。@moz-小さなサブセットのみが必要な点。それがまさに私たちの状況です。また、顧客データと比較することが重要であるという私の疑念を確認しています。

— エセルエヴァンス

@ethelと@moz、それはまさにHL7を扱うのを非常に困難にする一種の考え方です。時間をかけて可能な限りプログラムを柔軟にしてください。HL7はYAGNIがまったく適用できない場所の1つです。

— ピーターターナー

さて、これは理にかなっています。価値を提供するために使用できるHL7メッセージのタイプを拡大することを前もって計画しているため、このアプリケーションがYAGNIの問題を引き起こすとは思わない。将来必要になるものがわからないことがわかっています。

— エセルエヴァンス

だから私は、少なくとも受信側でオープンソースライブラリ（HAPI / NHAPI）を使用するのが好きです。「有効なHL7メッセージは受け取ったが、それを処理するためのコードを書いていない」というレベルを高くする方が、「そのメッセージを予期していなかったため、パーサーが失敗した」よりもはるかに優れています。残念ながら、全員が小さな「Xを送信してYを受信する」だけなので、新しい要件が到着するたびに何かを一緒にハックする方がはるかに簡単です。

最初の問題は、誰もがHL7が何であるかを確実にすることです。

[医療|請求|保険]コーダーを交換し、[薬局|銀行|保険会社]のお金を節約する方法です。

これは、ソフトウェア開発のすべての通常の問題のしわです。

スコープクリープ
不完全な仕様
「変更できません」という無効な独自仕様

したがって、あなたは、[薬局|銀行|保険会社]に連絡し、HL7インターフェースからあなたのソフトウェアを使用する施設に彼らができる限りのお金をこき出したいと思うでしょう。あなたの契約は施設との契約であり、彼らの契約は薬局との契約であり、[薬局|銀行|保険会社]はあなたのソフトウェアがどのように機能するのか見当もつかない。ソフトウェアにバグがあることを常に伝えます。

HL7の問題は、ほとんどが安価で行われることだと思います。HL7 3.0は収益化されないため、実現しない可能性があります。

「HL7の支払い」を行う場合は、HL [1-6]の支払いも行っていることを忘れないでください。SOAPインターフェースはHL7ではありません。HL7メッセージパーサーはHL7ではなく、メッセージジェネレーターでもありません。

— ピーター・ターナー
ソース

HL7は薬局だけのものではありません。ほとんどの場合、HL7は、EMRなどの異種システムを課金システムに接続するために使用されます。

— ビル

当社の製品は、間接的であっても薬局を対象としておらず、回答に対するサポートがほとんどなく、反応は非常に偏っています。

— エセルエヴァンス

@Ethelいくつかの正規表現を追加しますが、質問はより具体的にする必要があります。100％自作のHL7実装で薬局以上のことを行いますが、開発の背後にある原動力は常に「大きな薬局」です。

— ピーターターナー

@ピーター：なぜこれが役に立たないと思うか、より具体的にしようと思います。まず、強調表示された引用は、非常に偏っており、サポートされていないようです。第二に、番号付きリストの項目は曖昧であるか、他の回答がより明確に述べているものを超えて追加しないでください。第三に、あなたのシナリオ例は非常に具体的であり、私（および他の人たち）が扱っているシナリオのように見えないため、有益ではありません。第4に、HL7は安値で行われているというあなたの声明は偏っており、サポートされていないようです。第5に、「HL7」を実行しておらず、HL7メッセージを処理しているため、最後の段落のポイントが失われます。

— エセルエヴァンス

@Ethel、私は自分の主張をどのようにサポートすることになっていますか、HL7については何のメリットもありません、いくつかのベンダーと働いた最後の経験から私が知っていることは、誰かが私のソフトウェアに送信し、「テストメッセージ」を送信して、表示されるはずのメッセージを処理できるようにします。メッセージの周りに何らかのORMを作成し、それで機能します。これは良くない。私の答えが他の答えと異なるように思える場合、それは確かにあなたに真実を言っていないからではありません。HL7は主にお金に関するものです。

— ピーターターナー