短く言うと： HL7 v2では、検査依頼（検査、画像検査、薬剤など）は、バージョン2.5.1までのバージョンではORM^O01メッセージとして、バージョン2.4以降ではOML^O21という検査依頼メッセージとして送信されます。どちらも患者（PID）、受診（PV1）、依頼を制御するORCセグメント（新規、キャンセル、保留、ステータス変更、プレースホルダーとフィラー番号付き）、そして何を依頼したか、誰が、いつ依頼したかを記載するOBRセグメントを含んでいます。フィラーシステムはORR（またはOMLの場合はORL）で応答し、後で結果をORUとして返します。ORC+OBRのFHIR相当はServiceRequestです。
検査依頼、セグメントごとに
HL7 v2の検査依頼メッセージ（ORM^O01）は、セグメントで構成されます。MSHはメッセージタイプとバージョンを指定し、PIDは患者を識別し、PV1は受診情報を説明し、ORCは依頼制御コード、依頼者と実施者の依頼番号、優先度、依頼医師を運びます。OBRはLOINCコードと採取時間で依頼された検査名を指定し、DG1は根拠となる診断を提供します。
MSH|^~\&|EHR|GENHOSP|LIS|CENTRALLAB|20260314091200||ORM^O01^ORM_O01|MSG0001|P|2.5.1
PID|1||MRN-00012345^^^GENHOSP^MR||DOE^JANE||19800523|F|||12 High Street^^Leeds^^LS1 4AB^GB
PV1|1|O|CLINIC-3^^^GENHOSP||||42^SMITH^JOHN^^^Dr
ORC|NW|PLC-778812^EHR|||||^^^20260314093000^^R||20260314091200|42^SMITH^JOHN
OBR|1|PLC-778812^EHR||4548-4^Hemoglobin A1c/Hemoglobin.total in Blood^LN|||20260314093000||||||||42^SMITH^JOHN
DG1|1||E11.9^Type 2 diabetes mellitus without complications^I10
- MSH-9
ORM^O01^ORM_O01はメッセージタイプ、トリガーイベント、構造を示します。MSH-12 はバージョンを示します。 - PID は患者を識別します。PID-3 は、割り当て機関とタイプ（
MR、診療記録番号）を持つ識別子を含みます。 - PV1 は受診情報を示します：外来（
O）、場所、担当医。 - ORC-1 は依頼制御コードです：
NW新規依頼、CAキャンセル依頼、OC依頼キャンセル、HD保留、RL解除、SCステータス変更、OK依頼受付、UA受付不可、XO依頼変更、DC中止。ORC-2 はプレースホルダー依頼番号（依頼システムが割り当て）、ORC-3 はフィラー依頼番号（検査室が割り当て、応答があるまで空欄）です。ORC-7 はタイミングと優先度（R定常、S緊急、Aできるだけ早く）を含みます。ORC-12 は依頼医師です。 - OBR-4 はユニバーサルサービス識別子です：依頼されたもの、コード化されたもの（ここではLOINC、
LN）。OBR-7 は観察または採取日時です。OBR-16 は依頼医師を繰り返します。検査依頼では、検体詳細は古いバージョンではOBR-15に、2.5以降では専用のSPMセグメントにあります。 - DG1 は依頼を正当化する診断を含みます。
複数の検査を含む同じ依頼は、検査ごとにORC/OBRペアを繰り返し、それぞれに独自のOBR-1セットIDがあります。
ORM vs OML
ORM^O01は一般的なHL7 v2の依頼メッセージで、検査、放射線、薬局、消耗品のための緩やかな構造です。バージョン2.4で導入されたOMLは、トリガーO21、O33、O35を持ち、検体と容器のための明示的なSPMおよびSACセグメントを持つ、検査に特化した依頼メッセージです。多くの病院から検査室へのインターフェースは依然としてORM^O01を使用していますが、OMLは新しい検査システムやIHEプロファイルで見られます。
ORM^O01 は一般的な依頼メッセージです：検査、放射線、薬局、食事、消耗品に一つの構造を使用しており、それが曖昧さを生んでいました。バージョン2.4から、HL7はOML（検査依頼）を導入し、いくつかのトリガー（O21 検査ごとの依頼、O33 検体ごとの依頼、O35 検体と容器ごとの依頼）と、検体と容器のためのSPMおよびSACセグメントを持つ、より厳格な構造を提供しました。OMG（一般臨床依頼）、OMI（画像）、OMP（薬局）も同様のパターンに従いました。実際には、ほとんどの病院と検査室のインターフェースは、バージョン2.3.1または2.5.1のORM^O01で稼働しており、OMLは新しい検査システムやIHEのLaboratory Testing Workflowプロファイルで見られます。
返信
HL7 v2の依頼には2つの応答があります。即時のACK（MSA-1 AA、AE、またはAR）は、メッセージが受信され解析されたことを確認します。その後、アプリケーション応答として、ORMの場合はORR^O02、OMLの場合はORL^O22が、OKまたはUAを持つORCを繰り返し、実施者依頼番号であるORC-3を記入します。結果は後で、両方の依頼番号を持つORU^R01として返されます。
受信システムは2回応答します。すぐに、ACK（MSA-1 AA 受諾、AE エラー、AR 拒否）でメッセージが受信され、解析されたことを確認します。次に、アプリケーション応答として、ORR^O02（ORMの場合）またはORL^O22（OMLの場合）で、OKまたはUAを持つORCを繰り返し、ORC-3（フィラー依頼番号）を記入します。この番号は両方のシステムで以降使用されます。結果はORU^R01として返され、OBR-2とOBR-3に同じプレースホルダーとフィラー番号が含まれており、これにより結果が依頼に紐づけられます。詳細はHL7 v2メッセージ解説：ADTとORUをご覧ください。
依頼がうまくいかない場合
HL7 v2の依頼は、ORRが処理されなかった場合の依頼者と実施者の番号の不一致、OBR-4のLOINCコードのないローカル検査コード、元の依頼者番号なしで送信されたキャンセル、SPMセグメントが2.3.1受信者に送信されたようなバージョン不一致、そしてORC-7またはOBR-5ではなくNTEの自由テキストで書かれた優先度などが原因で最もよく失敗します。
- 番号の不一致： ORUが、EHRが認識したことのないフィラー番号で返ってくることがあります。これは通常、ORRが処理されなかったためです。
- OBR-4のローカルコード： LOINCコードの代わりに（またはなしで）検査室の内部テストコードが使用されている場合、受信システムはテストをマッピングできません。修正方法は、両方のコードを含めることです：
GLU^Glucose^L~2345-7^Glucose [Mass/volume] in Serum or Plasma^LN。 - 元の番号なしのキャンセル：
CAは、キャンセルする依頼のプレースホルダー番号を含める必要があります。 - バージョンの不一致： 2.3.1受信者に送信されたSPMセグメントはドロップされるか拒否されます。
- 間違ったフィールドでの優先度：
STATが、ORC-7またはOBR-5の代わりにNTEの自由テキストフィールドに入力されている。
FHIRでの同じ依頼
FHIRでは、HL7 v2依頼のORCおよびOBRセグメントは、ステータス、意図（依頼）、優先度、LOINCコード、対象者、受診、依頼者、発生日時、理由コード（診断用）、および依頼者と実施者の番号の識別子を持つ単一のServiceRequestにまとめられます。結果として得られるObservationおよびDiagnosticReportは、HL7のv2からFHIRへの実装ガイドのマッピングを通じて、basedOnで参照します。
FHIRでは、ORCとOBRは一つのServiceRequestに統合されます：status（active、on-hold、revoked、completed）、intent（order）、priority（routine、urgent、asap、stat）、code（LOINCテスト）、subject、encounter、requester、occurrenceDateTime、reasonCode（ICD-10診断）、そしてプレースホルダーとフィラー番号のためのidentifierです。結果のObservationとDiagnosticReportはbasedOnで参照されます。HL7はv2-to-FHIR実装ガイドでフィールドごとのマッピングを公開しています。
Anpheros PlatformはServiceRequest、Observation、DiagnosticReportをサポートしており、その検査室コネクタは結果をHL7 v2 ORU、CSV、またはJSONで受け入れます。依頼の送受信は行わず、依頼は病院または検査室のシステムで行われ、完了した結果が患者の記録に追加されます。
関連ページ
- HL7 v2メッセージ解説：ADTとORU
- HL7 vs FHIR
- PACS vs RIS vs VNA
- 検査室コネクタ：HL7 v2、CSVまたはJSONからFHIRへ
- LOINCコードとは？
- HL7 v2からFHIRへのマッピング（開発者向け）
- 検査情報システムをEHRと統合する方法
- インターフェースエンジン解説
情報源
- HL7 Version 2 product suite
- HL7 v2.5.1 ORM_O01 reference (Caristix)
- HL7 v2.5.1 OML_O21 reference (Caristix)
- HL7 v2-to-FHIR implementation guide
- HL7 FHIR R4: ServiceRequest
- IHE Laboratory Testing Workflow (LTW)
よくある質問
ORCとOBRの違いは何ですか？
ORCは、依頼を管理上のオブジェクトとして扱います：誰が依頼したか、その番号、ステータス、優先度。OBRは、要求されたサービスについてです：どの検査か、どの検体で、いつか。すべてのOBRの前には、そのORCがあります。
プレースホルダーとフィラーとは何ですか？
プレースホルダーは、サービスを要求するシステム（EHRまたは依頼医師のシステム）です。フィラーは、サービスを実行するシステム（検査室または放射線システム）です。それぞれが独自の依頼番号を割り当て、メッセージには両方の番号が含まれるため、どちらの側でも依頼を見つけることができます。
新しい検査室インターフェースにはORMとOMLのどちらを実装すべきですか？
パートナーがバージョン2.5.1以降でOML^O21をサポートしている場合は、そちらを優先してください：検体処理が明確であり、IHEプロファイルがそれに構築されています。パートナーが古いLISの場合は、ORM^O01が使用されており、それに適応します。
HL7 v2の依頼はFHIRにどのようにマッピングされますか？
ORCとOBRは合わせてServiceRequestになります。プレースホルダーとフィラー番号は識別子になります。ORC-1とORC-5はステータスにマッピングされます。OBR-4はコードに、DG1はreasonCodeに、依頼医師はrequesterにマッピングされます。HL7 v2-to-FHIRガイドには、詳細な表が掲載されています。
サンドボックスで無料で試す
5分で最初のFHIR呼び出し. 患者さんの同意が組み込まれたHL7 FHIR R4 APIです。サンドボックスでお試しいただき、ご自身のアプリやクリニックのシステムを接続してください。
無料・合成患者30人・カード不要
Anpherosは、患者が管理し、あらゆるクリニックと共有できる医療記録を、EUを拠点とするHL7 FHIR R4プラットフォーム上で構築しています。これらのガイドは、ご自身の健康を理解し整理するのに役立ちますが、医師の代わりになるものではありません。
Anpherosについて →