問題タブ [hl7-v2]

訪問終了通知を Hl7 メッセージとして送信する場合、終了訪問通知を送信するときに Hl7 メッセージ (ADT^A03) に以下のセグメントを含めることはできますか?

• AIL - 予約情報 - ロケーション リソース
• AL1 - 患者のアレルギー情報
• CON - 同意セグメント
• CTD - 連絡先データ
• DG1 - 診断
• DMI - DRGマスターファイル情報
• FAC - 施設
• IAM - 患者の副作用情報
• LAN -言語の詳細
• NTE -- メモとコメント
• ODS -- 食事の注文、サプリメント、好み
• PD1 -- 患者の追加の人口統計
• PID - 患者の識別
• PR1 -- 手順
• PRA -- プラクティショナー詳細
• PRB -- 問題の詳細
• PRD プロバイダー データ
• PV1 患者訪問
• PV2 患者訪問 - 追加情報
• RF1紹介情報
• TCD テスト コードの詳細

また、知りたかったのですが、単一の HL7 メッセージでのセグメント数の使用に制限はありますか?

これについての助けは本当に感謝していますか？

ありがとうラマナ

HL7 v2 ファイルを使用した後、それらを HAPI HL7 オブジェクトにマーシャリングしようとしています。ルートのサンプルは次のようになります。

残念ながら、私は例外を取得します:

解析される各メッセージの先頭に \u000B 記号があることがわかりました。これにより、パーサーは "MSH" ヘッダーを見つけられません。

もちろん、次のような単純な文字列操作で修正できます。

しかし、これは最善の解決策ではないように思えます。MLLP プロトコルが使用されている場合、同じシンボルがメッセージの前にあり、HL7 コーデックがそれを処理する必要があることがわかりました。http://camel.apache.org/hl7.html

質問: HL7Codec for File または FTP コンポーネントを使用して、文字列/解析への変換を処理することは可能ですか?

私たちの DICOM モダリティ ワークリスト サーバーは現在ORM^O01、病院の RIS から HL7 の注文を受けています。各注文をモダリティにマッピングするために、現在OBR-24メッセージ内のフィールドを使用しています。に含まれるコードOBR-24は、MWL サーバーのルックアップ テーブルによって AE タイトルとモダリティにマッピングされます。現在のOBR-24値は、「LOC_STATION」の行に沿ったものです。ここで、LOC はスケジュールされたステーションの場所 (建物レベル) であり、STATION は現在のオーダーのスケジュールされたステーションです。

現在、同じ受信メッセージ フィードを別のシステムに転送して、注文に基づいて低速の長時間アーカイブから以前の研究をプリフェッチする必要が生じています。プリフェッチ エンジン ルールの重要な入力パラメーターは、順序付けられた調査のモダリティです。したがって、ルックアップ テーブル システム全体を複製して 2 か所で別々に管理したくないため、DICOM モダリティ コードを受信オーダー メッセージに追加したいと考えています。

この種の情報に最適なフィールドはORM^O01、HL7 標準の v2.3.1 で定義されている構造内にありますか? 私は標準をすくい取り、MWL サーバー ベンダーの参考資料を調べましたが、最も近いものは同じOBR-24分野であり、私たちのソリューションで既に使用されています。それとも、ある種のカスタム Z セグメントの実装を検討する必要がありますか?

さらに、私たちは独立した PACS サービス プロバイダーであるため、病院での HIS/RIS ソフトウェアの開発を管理しておらず、ほとんどの場合、病院側で最小限の変更を加えて既存のシステムと統合する必要があるため、状況はさらに複雑になっています。したがって、メッセージング標準の既存のフィールドを変更または移動することは非常に困難ですが、新しい目的のために新しい未使用のフィールドを実装する方が簡単です。

HL7v2 メッセージの次の PV1 セグメントについて考えてみましょう。

PV1|1|E|MYLOC||||55555^Doctor^Doc^D^^Dr^^DOCT|||||||HO||||ER||BC|||||||||||||||||||VALUE||REG|||201406270627||||||||55555^Doctor^Secondary^H^^Dr^^DOCT2|

そこには52のフィールドがあります。私たちの Meditech システムは、このインターフェイスで常にフィールド 52 (PV1_52_OtherHealthcareProvider) を送信します。これは、ここでは で表され55555^Doctor^Secondary^H^^Dr^^DOCT2ます。Allow Trailing Delimitersが ONになるように設定しました。ご覧のとおり、このセグメントには末尾の区切り文字がありますが、これはセグメントの最後のフィールドの後にあり、たまたま上記のデータが含まれています。

これは常に当てはまります。Meditech は常にこのインターフェイスの末尾に区切り文字を追加しています。

他のセグメントはいずれも最終フィールドにデータを持っていないため、末尾に区切り文字があるにもかかわらず、この問題は発生していません。PV1 セグメントで、次のエラーが表示されます。

デリミタを手動で削除して再送信すると、エラーは発生しないため、これは末尾のデリミタが原因であることが判明しました。また、スキーマを変更してダミー(PV1_53_ExtraField) フィールドを追加すると、メッセージが許可されます。

私の質問は次のとおりです。この場合、末尾の区切り文字を許可するとどのような動作が期待されますか? すべての場合に末尾の区切り文字を許可することになっていますか、それとも最終フィールドにデータがないセグメント (つまり、セグメントの最後の余分なフィールド) にのみ適用されますか?

現在、Apache Camel 2.13.2 および Apache Hapi とのヘルスケア相互運用性のために HL7 を使用しています。新しい Meta Data Annotation@Terserとカスタマイズされたプロセッサを作成しようとしているときに、突然 eclipse の自動提案が私の集中力を壊してしまいました。@org.apache.camel.component.hl7.Terser注釈が既に存在することがわかりました。その時以来、私は試していますが、キャメルドキュメントやグーグルで例が見つからないため、使用できません。そのようなタイプのコードを実装している機関があれば、私を助けてください。