ＪＡＨＩＳ標準 ２２－００４

ＪＡＨＩＳ
生理検査データ交換規約
Ｖｅｒ．３．１Ｃ

２０２２年４月
一般社団法人 保健医療福祉情報システム工業会
医療システム部会 相互運用性委員会

ＪＡＨＩＳ

生理検査データ交換規約 Ver.3.1C
ま

え

が

き

生理検査とは、血液、尿など被検者から検体を採取し、それを検査機器で分析を行う検体検査とは異なり、生体に装着された電極やセンサーを用いて生体情報を直接検査機器などに取り込み、記録や表示を行う検査のことであり、心電図検査、脳波検査、呼吸機能検査などがある。HL7 では心電図など一部の生理検査に対するガイドはみられるが、多くの生理検査データ交換に関しては具体的な仕様が決まっていない。また、例えば心電図検査結果に関しても、そのメッセージ記
述には生理学、機器・信号処理、臨床診断に関する知識、経験を必要とし、それらの情報を交換することは容易でない。そのため、そのほとんどは機器メーカや専門メーカによる独自規格で処理されているにすぎなかった。
電子カルテなどの普及が進むにあたり、生理検査結果の相互運用性の要請が高まり、標準化が必須の状況になった。それら市場要求に沿い、一般社団法人 保健医療福祉情報システム工業会（JAHIS）メッセージ交換委員会（当時、現在は改称し相互運用性委員会）において、HL7 V2.5に基づき、生波形形式として ISO/TS として発行された MFER（Medical waveform Format
Encoding Rules）
を用い、各種生理検査におけるデータ交換の規約を検討し、2007 年 8 月に Ver.1.0を発行した。
Ver.2.0(2013 年 4 月発行)では、従来の検査結果の管理・提供だけではなく、検査の業務フロー管理を支援するためのステータス情報の取扱い、レポートや検査結果データの埋込に対応した。
Ver.3.0C(2016 年 12 月発行)では、他のデータ交換規約との共通部分を抽出した JAHIS データ
交換規約共通編への対応・分冊化、MFER や HL7CDA 等の検査結果データファイルの埋込仕様の見直し説明等の見直しを行った。
“C”という接尾辞は共通編を参照している事を意味している。
今回（Ver.3.1C）の改定では最新の JAHIS データ交換規約共通編への対応を行うとともに、内容を実際に運用されている生理検査情報システムにあわせて絞込み、また実装者の理解を助ける
ため HIS、
LIS、
Modality それぞれの立場で使用するメッセージを判りやすくする補足を行った。
本規約が医療資源の有効利用、保健医療福祉サービスの連携・向上を目指す医療情報標準化とデータ交換の円滑化に多少とも貢献できれば幸いである。
2022 年 4 月
一般社団法人 保健医療福祉情報システム工業会
医療システム部会 相互運用性委員会

＜＜

告知事項

＞＞

本規約は利用者が本工業会の会員であるか否かに関わらず、規約の引用を明示すること
で自由に利用することができるものとします。本規約に対する適合性を宣言する際には、部分実装や拡張がある場合を含めその適合範囲を所定のフォーマットに記述した適合性宣言書を作成し、実装したシステムの関係者に提供、公開することを推奨します。
本規約ならびに本規約に基づいたシステムの導入・運用についてのあらゆる障害や損害について、本工業会は何らの責任を負わないものとします。ただし、本工業会の会員は本規約についての疑義を申し入れることができ、担当委員会はこれに誠意をもって対応する
ものとします。

© JAHIS 2022

i

目

次

1.
2.

はじめに...................................................................................................................................... 1
使用している HL7 について ....................................................................................................... 2
2.1. 概要 ...........................................................................................................................................2
2.2. メッセージ ................................................................................................................................2
2.3. フィールド ................................................................................................................................2
2.4. メッセージ区切り文字 ..............................................................................................................2
2.5. データ型 ....................................................................................................................................2
3. 主な用語と参照規格 .................................................................................................................... 3
3.1. 主な用語 ....................................................................................................................................3
3.2. 参照する外部の標準規格・マスタ ............................................................................................3
4. JAHIS 標準テーブル ................................................................................................................... 4
4.1. 本規約で定義する JAHIS 標準テーブル ...................................................................................4
5. 本規約の対象範囲........................................................................................................................ 5
5.1. 基本方針 ....................................................................................................................................55.2. 生理検査概要 .............................................................................................................................55.3. 対象範囲 ....................................................................................................................................8
6. メッセージ構文 ......................................................................................................................... 10
6.1. 生理検査依頼(OMG/ORG) ...................................................................................................... 11
6.2. 患者情報更新(ADT/ACK)........................................................................................................13
6.3. 患者情報照会(QBP/RSP) ........................................................................................................13
6.4. 生理検査依頼照会(QBP/RSP) .................................................................................................13
6.5. 検査ステータス通知(ORU/ACK) ............................................................................................14
6.6. 生理検査結果通知 (ORU/ACK) ..............................................................................................16
6.7. データ保存確認(QBP/RSP) .....................................................................................................17
6.8. 生理検査結果照会(QRY/ORF).................................................................................................18
7. 関連セグメント詳細 .................................................................................................................. 20
7.1. AL1 - PATIENT ALLERGY INFORMATION SEGMENT 患者アレルギー情報セグメント ..............20
7.2. ERR - ERROR SEGMENT エラーセグメント ............................................................................20
7.3. EVN - EVENT TYPE SEGMENT セグメント .............................................................................20
7.4. MSA - MESSAGE ACKNOWLEDGMENT SEGMENT メッセージ応答セグメント ........................20
7.5. MSH - MESSAGE HEADER SEGMENT メッセージヘッダセグメント ......................................20
7.6. NTE - NOTES AND COMMENTS SEGMENT 注釈コメントセグメント ......................................20
7.7. OBR - OBSERVATION REQUEST SEGMENT 検査要求セグメント .............................................21
7.8. OBX - OBSERVATION/RESULT SEGMENT 検査結果セグメント ...............................................30
7.9. ORC ORDER COMMON SEGMENT 共通オーダセグメント .................................................42
7.10. PID - PATIENT IDENTIFICATION SEGMENT 患者識別セグメント ............................................62
7.11. PV1 - PATIENT VISIT SEGMENT 来院情報セグメント .............................................................74
7.12. QAK - QUERY ACKNOWLEDGMENT SEGMENT 照会応答セグメント .......................................74
7.13. QPD - QUERY PARAMETER DEFINITION 照会パラメータ定義 ................................................75
7.14. QRD - QUERY DEFINITION SEGMENT 照会定義セグメント....................................................78
7.15. QRF - QUERY FILTER SEGMENT 照会フィルタセグメント ....................................................82
7.16. RCP - RESPONSE CONTROL PARAMETER SEGMENT 応答制御パラメータセグメント .............85
7.17. TQ1 - TIMING/QUANTITY SEGMENT タイミング/数量セグメント ...........................................86© JAHIS 2022ii

付録‐１．生理検査データ交換規約メッセージの例 ......................................................................... 91
１．各ワークフロー ...........................................................................................................................91
２．メッセージ使用例 ........................................................................................................................98
３．心電図等の波形情報と検査結果情報の記述 ..............................................................................146
付録‐２. 本規約で定義される OID ................................................................................................ 147
付録‐３．作成者名簿 .................................................................................................................... 148© JAHIS 2022iii

1. はじめに生理検査では種々の数値、文字あるいはコードなどで記述される測定値や解析結果と共に波形情報が不可欠である。また、生理検査機器の測定結果を院内総合情報システムや地域医療システムと連携して役立てる
ためには生理検査機器からの情報項目を拡張するだけでは不足で、電子カルテやオーダエントリシステムからの検査依頼を患者属性とともに受信・管理し、検査の業務フローにあわせて検査ステータスを関連する情報システム及び生理検査機器に通知するとともに、結果を管理するといった生理検査情報システムを想定した総合的な連携が必要となる。本規約は、その連携に必要なメッセージ、想定する業務フローを定義するものであり、具体的には以下の仕様を規定している。
１）検査を依頼するためのメッセージ（検査付帯情報、患者情報を含む）
２）受け付けた検査依頼を管理・照会するためのメッセージ
３）検査の進行状況を関連部門と共有するためのメッセージ（ステータス）
４）検査結果を通知するためのメッセージ（計測値、波形を含む）
５）検査結果を他部門に渡す、あるいは参照してもらうためのメッセージ
本改定においては旧版（3.0C）から次の見直し、補強を行った。
（データ交換規約共通編関連）
・ 日本 HL7 協会が 2020 年 6 月に公開した HL7 V2.5 日本語訳見直し版の表現を基に見直した。
・ HL7 V2.5 で CE 型であったデータ項目について CWE 型から元の CE 型に戻した。
・ 新たに共通編に記載することとなったセグメントにあわせて本規約の説明範囲を見直した。
・ 参照している他規約やマスタを「3.2. 参照する外部の規格やマスタ」にまとめた。
・ 外部の規約から本規約で定義したコード表を参照するために採番した OID を記載した。
・ 各ベンダが提供する製品の本規約への適合性を示す「適合性宣言書」に対応した。
（本規約固有）・ 本規約に記載するメッセージ類を実際の生理検査で必要な機能を踏まえて整理し、記載順、サンプ
ル電文などを見直した。
・ 本規約に関連するシステム（モダリティ含む、以下同じ）について付録１に代表的なシナリオとメッセージの利用について記載し、利用者の注目するシステムに関連するメッセージ、利用方法を明確にした。
・ 共通編に対して、本規約固有な仕様の説明である「【生理】」の表記を見直した。
なお、本規約は JAHIS データ交換規約 共通編と差異がある部分だけを記載した資料構成になっているた
め、JAHIS データ交換規約 共通編 Ver.1.3 との併読を前提としている事を留意いただきたい。

© JAHIS 2022

1

2. 使用している HL7 について
2.1. 概要JAHIS データ交換規約 共通編 Ver.1.3「２．使用している HL7 について」を参照のこと。

2.2. メッセージ
JAHIS データ交換規約 共通編 Ver.1.3「２．使用している HL7 について」を参照のこと。

2.3. フィールド
JAHIS データ交換規約 共通編 Ver.1.3「２．使用している HL7 について」を参照のこと。

2.4. メッセージ区切り文字
JAHIS データ交換規約 共通編 Ver.1.3「２．使用している HL7 について」を参照のこと。

2.5. データ型
JAHIS データ交換規約 共通編 Ver.1.3「２．使用している HL7 について」を参照のこと。

© JAHIS 2022

2

3. 主な用語と参照規格
3.1. 主な用語
JAHIS データ交換規約 共通編 Ver.1.3「3．主な用語と参照規格」を参照のこと。
以下は共通編との差異のみを記載する。
Modality
Acquisition Modality：医用画像の撮影や心電図等生体情報の記録機能をサポートする検査装置。本規約
では、システムとして扱う。
生理検査情報システム
生理検査部門で扱う生理検査データにおいて、オーダ情報管理、患者到着時の受付管理、検査進捗管理、
データファイリング、実施管理、レポーティング等の機能を有する部門システム。本規約では、
LIS(Laboratory Information System)と表記する。
機能の詳細は、5.2.3 生理検査情報システムの機能 を参照のこと。

3.2. 参照する外部の標準規格・マスタ
本規約では、以下の外部の標準規格の使用を想定している。
ISO 22077-1:2015 Health informatics — Medical waveform format — Part 1: Encoding rules
標準 12 誘導心電図波形については、MFER 形式でのデータ交換を推奨する。MFER 規格は HELICS（医療情報標準化推進協議会）の HS028 にて採択されている。また、国内の MFER 委員会では、いくつかの心
電 図 計 測 値 に つ い て 、 OID を 定 め て い る 。 本 規 格 を 「 MFER 」 と 略 称 、 略 記 す る 。
(https://www.iso.org/standard/61871.html)
臨床検査マスターコード:JLAC10
一 般 財 団 法 人 医 療 情 報 シ ス テ ム 開 発 セ ン タ ー に て 開 発 さ れ 、 同 じ く HELICS の HS014(http://helics.umin.ac.jp/helicsStdList.html)にて採択されている JLAC10 コードでは、生理検査に関する検査項目コードの一部が定義されている。2019 年 10 月に日本臨床検査医学会(JSLM)から JLAC の次期バージョンである JLAC11 が公開された。JLAC11 には生理検査に関する検査項目コードは定義されていないた
め、本規約では JLAC10 を採用する。
LOINC(Logical Observation Identifiers Names and Codes)
LOINC は Regenstrief 研究所によって 1994 年に運用が開始された、診療名や計測値項目を表すコード集。
HL7CDA 内の各項目を識別するコードにも利用される。(https://loinc.org/)
ISO/HL7 27931:2009 Data Exchange Standards - Health Level Seven Version 2.5 - An application
protocol for electronic data exchange in healthcare environments
本規約が参照するオリジナル規格で、2009 年、HL7 version2.5 が ISO IS として承認された。
(https://www.iso.org/standard/44428.html)© JAHIS 2022

3

4. JAHIS 標準テーブル
4.1. 本規約で定義する JAHIS 標準テーブル
本規約で使用する各種コードは、JLAC10、LOINC や HL7 であらかじめ用意されているものを使用するが、存在しない項目については以下のような項目コードを定義して必要なセグメントに記載する。コーディ
ングシステム名は“JHSSnnnn”（nnnn は 4 桁の表番号）とする。

JHSS表 0001 生理検査結果データ（コーディングシステム名：JHSS0001、OID：1.2.392.200270.4.4.5.1）
Value
DUID

DataUID

Description

MIME

MIMEPackage

MFER

MFER ファイル

XML

付帯情報ファイル

※”MFER”および”XML”は下位互換性のためここに残した。

JHSS表 0002 生理検査メッセージイベントタイプ（コーディングシステム名：JHSS0002、OID：1.2.392.200270.4.4.5.2）© JAHIS 2022

Value
ZS1

Description
生理検査依頼照会メッセージ

ZS2

生理検査依頼照会応答メッセージ

ZS3

データ保存確認メッセージ

ZS4

データ保存確認応答メッセージ45. 本規約の対象範囲
5.1. 基本方針
5.1.1. 文字コード
本規約では、「図 5.3-1 システム間情報伝達イメージ」の構成要素間で使用する文字コードは下記とする。
《HIS⇔LIS》
・JAHIS データ交換規約 共通編 Ver.1.3「5.1.2 文字コード」と同じとする。
《LIS→Modality》
・原則として、JAHIS データ交換規約 共通編 Ver.1.3「5.1.2 文字コード」と同じとする。
注記：Modality で扱えない文字は、LIS にて Modality が扱える文字に置き換えてもよい。その場合、HIS に検査結果を報告する際には Modality から送られてきた文字ではなく、HIS から依頼時に受け取った情報で報告する。

5.2. 生理検査概要
生理検査は、血液、尿などの検体を検査する検体検査とは異なり、生体から直接電極、センサーを用いて生体情報を取り出す検査である。
本規約で扱う生理検査は、以下に述べるような生理機能検査室、病棟、手術室、心臓カテーテル室などで実施される生理検査、あるいは健診などで実施される生理検査を想定している。一方、心臓カテーテル検査、
超音波検査などでの DICOM 通信について、通常それらは JAHIS 他規約に準じる方が適当であるため、本規約の対象範囲としていない。

5.2.1. 生理機能検査室での生理検査データ
生理検査には、循環器系検査（心電図検査、心臓カテーテル検査、超音波検査など）、脳・神経系検査（脳波、筋電図など）、呼吸器系検査（スパイロメトリーなど）、肝臓、消化器、腎臓、産科、婦人科系などの検査（超音波検査など）、サーモグラフィ、眼底検査、（MRI）などの画像検査がある。
生理検査には、予め予約を行い実施する検査と予約をせず行う検査がある。一般的に標準１２誘導心電図
以外は予約が必要であることが多い。予約にあたっては部屋や機器の配置、実施者、前処置等の準備が必要である。
各検査の特徴について、以下に記載する。

5.2.1.1. 心電図検査
安静心電図検査（標準１２誘導心電図）ECG 又は EKG：通常両手両足、胸部に 6 個、合計 10 個の電極を用いて検査する。心筋梗塞、狭心症といった虚血心疾患、心房・心室性期外収縮、心房細動などの不整脈、カリウム・カルシウムなどの電解質異常などの診断に用いる。
マスターステップ（マスター２階段試験）：年齢、体重などにより設定された条件に応じて昇降台（凸状の階段）を上り下りして運動負荷をかけて検査を行い、心筋虚血の有無を診断する。
トレッドミル運動負荷試験 TMT：負荷量を設定可能なベルトコンベア風のトレッドミルによって運動負荷をかけて検査を行い、心筋虚血の有無を診断する。
エルゴメータ心肺運動負荷試験（運動耐容能検査）CPX：自転車エルゴメータに呼気ガス分析を併用して運動予備能力を測定する。主として心肺疾患の重症度、適切な運動療法の確認を行う。

© JAHIS 20225

長時間心電図（ホルター心電図）検査：小型の電子的記録機能を持ったレコーダ（従来はカセットテープを用いた記録装置であったが最近では電子的メモリに記憶する）に主として胸部に貼られた電極から導出された２４時間程度の期間の心電図を記録する。これは日常生活中に発生する不整脈や虚血疾患の診断に使用される。
その他の循環器検査：心音・心機図検査、短期間（３０秒から数分）の心電図記録、遅延心電図（レート
ポテンシャル）、体表面電位図（体表面マッピング）検査、末梢循環検査（指尖脈波）などがある。

5.2.1.2. 神経生理検査
脳波検査 EEG：頭皮に電極を貼り導出、増幅（50μ ボルト程度）、記録する。てんかん、脳腫瘍、脳部障
害、脳死などの判定、診断に用いる。脳波検査とは周波数分析あるいはバイスペクトル分析などを行い、別に術中の麻酔深度などに用いるものもある。
誘発電位検査：音刺激、視覚刺激などを与えることにより、頭部から脳波を加算平均して記録する。それ
ぞれ聴性脳幹反応、視覚誘発電位という。
筋電図検査 EMG：筋肉に針電極などを挿入し筋の電気現象を記録する。
誘発筋電図検査：運動神経を電気刺激して伝導速度などを検査する。
睡眠脳波検査（ポリソムノグラフィ）PSG：脳波、眼球運動、筋電図、呼吸、心電図、SPO2 など睡眠時に測定し、睡眠時無呼吸症候群などの診断を行う。
聴力検査：聴覚測定装置（オージオメータ）や測定者自身によって測定され、難聴、聴覚の異常などの診断を行う。
平衡機能検査（重心動揺計）：三角形や四角形の荷重検出計台により患者の体重移動を測定する。迷路障害や小脳異常などの診断に用いる。
眼振検査：眼球に帯電した電位を測定し眼球運動を測定する。メニエール症候群や脳・中枢神経系の障害診断に用いる。

5.2.1.3. 肺機能検査
スパイロメトリー（換気機能）検査：呼吸の吸排気により、拘束性障害、閉塞性障害などの診断に用いる。
肺胞機能検査：クロージングボリュームなどにより肺胞の分布、拡散について検査する。
基礎代謝検査：換気量、酸素消費量、炭酸ガス産生量を測定しエネルギー代謝を測定する。バセドー氏病、
褐色細胞腫などの診断に用いられる。

5.2.1.4. その他
その他、医用波形を含まないが超音波検査、眼底（写真）検査、内視鏡検査、サーモグラフィ等が生理検査部門で行われる場合がある。

© JAHIS 2022

6

5.2.2. 生理機能検査室以外(病棟等)で発生する生理検査データ
5.2.2.1. 病棟
心電図検査、長時間心電図、脳波・誘発、超音波検査がある。

5.2.2.2. 産科
CTG（胎児心拍陣痛図）、超音波検査がある。

5.2.2.3. 心臓カテーテル検査（含む電気生理検査）
カテーテル手技と並行して、ポリグラフによる電気生理学的検査がある。

5.2.3. 生理検査情報システムの機能
生理検査部門で扱う生理検査データは、通常、生理検査情報システムで管理する。生理検査情報システムには以下の機能があるが、部門システムの規模によって、一部の機能のみを実装している場合もある。
⚫

オーダ情報管理
HISからの生理検査依頼及び患者属性情報を受信し、検査日毎に管理する。さらに、Modalityからのリクエストに応じてそれら情報を配信する。検査実施状況に合わせて検査ステータスをHISへ送ることもできる。

⚫

患者到着時の受付管理
患者到着時に生理機能検査室で使用する受付票の発行や、部門内での患者待受け表示板に表示する場合もある。

⚫

検査進捗管理“検査中”や“検査終了”などの検査進捗を管理して一覧表示する。

⚫

データファイリング
Modalityから検査結果データを受信、ファイリングし、管理する。Modalityからのデータ保存確認に応答し、確実にデータが保存されたことをModalityへ通知することができる。

⚫

実施情報管理
実施した検査項目や手技、使用薬剤情報を管理し、HISへ送信する。
レポーティング
検査結果レポートを作成管理し、必要に応じて検査結果としてHISへ送信する。

⚫

© JAHIS 2022

7

5.3. 対象範囲
本規約は「図 5.3-1 システム間情報伝達イメージ」の範囲を対象とする（実線矢印部が対象、破線矢印部は対象外）。また、取り扱うメッセージタイプおよびトリガーイベントを「表 5.3-1 メッセージとトリガーイベ
ント」に示す。

①生理検査依頼②患者情報更新⑧生理検査結果照会

Modality③患者情報照会④生理検査依頼照会⑤検査ステータス通知⑥生理検査結果通知⑦データ保存確認

HIS

LIS

（病院情報
システム）

（生理検査情報システム）③患者情報照会④生理検査依頼照会⑤検査ステータス通知⑥生理検査結果通知(オーダ管理有)

Modality③患者情報照会⑥生理検査結果通知⑦データ保存確認(オーダ管理無)Modality⑥生理検査結果通知⑦データ保存確認(患者情報取扱
無)図 5.3-1:システム間情報伝達イメージ
表5.3-1 メッセージとトリガーイベント
NO

メッセージ定義①

生理検査依頼②

患者情報更新③

患者情報照会④

生理検査依頼照会⑤

検査ステータス通知⑥

生理検査結果通知⑦

データ保存確認⑧

生理検査結果照会

メッセージ
タイプ
OMG→
←ORG
ADT→
←ACK
QBP→
←RSP

トリガーイベント

イベントタイプ

R/O
(HIS)

R/O
(LIS)
HIS

MOD

R/O
(Modality)

生理検査の依頼

O19/O20
R19/R20

R

R

－

－

患者情報の更新

A08

O

O

－

－

患者基本情報の照会

Q22/K22

O

O

O

O

患者基本情報および所在の照会

ZV1/ZV2

O

O

O

O

ZS1/ZS2

O

O

O

O

R01

O

O

O

O

R01

O

O

O

O

ZS3/ZS4

－

－

O

O

R02/R04

O

O

－

－

QBP→
生理検査依頼の照会←RSP
ORU→
検査ステータスの通知
←ACK
ORU→
生理検査結果の通知←ACK
QBP→
生理検査結果データの保存確
←RSP
認
QRY→
生理検査結果の照会←ORF

本規約では上記のメッセージタイプおよびイベントタイプをサポートする。
「メッセージタイプ」欄の矢印（→、←）は、メッセージの応答関係を表す。上側の矢印（→）が最初のメッセージの送信を意味し、下側の矢印（←）が最初のメッセージに対する応答メッセージの送信を意味する。

© JAHIS 20228

「図 5.3-1 システム間情報伝達イメージ」の各システムによるメッセージタイプおよびイベントタイプのサポートが、必須なのか、オプションなのかを「R/O」カラムに示す。
R ：必須
O ：オプション－ ：非該当システムが「LIS」の場合、HIS-LIS 間と LIS-Modality 間でサポートするメッセージが異なる。そのため、適合性宣言書には、HIS-LIS 間と LIS-Modality 間の 2 つのメッセージに関するサポート状況を記述する必要がある。
メッセージの概要① 生理検査依頼（OMG/ORG）
生理検査依頼のオーダ情報を OMG メッセージで通知し、それに対する応答を ORG メッセージで返す。
② 患者情報更新（ADT/ACK）
患者の更新情報を ADT メッセージで通知し、それに対する応答を ACK メッセージで返す。
③ 患者情報照会（QBP/RSP）
患者情報を QBP メッセージで問合せ、それに対する応答を RSP メッセージで返す。
④ 生理検査依頼照会（QBP/RSP）
生理検査依頼のオーダ情報を QBP メッセージで問合せ、それに対する応答を RSP メッセージで返す。
⑤ 検査ステータス通知（ORU/ACK）
モダリティでの検査開始、検査終了等の検査ステータスを ORU メッセージで通知し、それに対する応答を ACK メッセージで返す。従来の“到着確認”も本メッセージに含まれる。
⑥ 生理検査結果通知（ORU/ACK）
生理検査結果を ORU メッセージで通知し、それに対する応答を ACK メッセージで返す。
⑦ データ保存確認（QBP/RSP）
データ保存確認を QBP メッセージで問合せ、それに対する応答を RSP メッセージで返す。
⑧ 生理検査結果照会（QRY/ORF）
生理検査結果を QRY メッセージで問合せ、それに対する応答を ORF メッセージで返す。

© JAHIS 2022

9

6. メッセージ構文
本規約では、HL7 メッセージを構成するセグメントの省略の可否（[ ]表記）や繰り返しの可否（{ }表記）に加え、JAHIS 仕様での要否を明確にするためコメント Usage に要否等を付記した。
メッセージ構文での表記規則：⚫

Usage（JAHIS仕様での取り扱い）
R - 必須。
RE - 存在すれば必須（送信側アプリケーションは、該当データがあれば送信しなければならないが、存在しなければ省略する）。
O - オプション。
C - トリガーイベントまたはメッセージの使用条件による。
X - 本規約では使用しない。

⚫
⚫

B - HL7の旧バージョンとの下位互換のために残されている。
。
N - 使用しない（関係者の合意のもとに関係システム内限定で使用可）
注記: [ ] は省略可能、{ } は繰り返し可能を示す。
注記: 特にセグメントグループについては、そのセグメントグループの要否等を記し、さらにそのグループに属する個々セグメントの要否等を記した。

© JAHIS 2022

10

6.1. 生理検査依頼(OMG/ORG)
生理検査の依頼時には、一般オーダメッセージ(OMG)を用い、その応答には一般オーダ応答メッセージ(ORG)を使用する。その場合のセグメントと構文規則は以下のとおりである。

6.1.1. OMG – 生理検査依頼メッセージイベント(O19)
生理検査依頼は、一般オーダメッセージ(OMG) イベント（O19）を用いる。
表6.1-1 OMG 生理検査依頼メッセージ
OMG^O19^OMG_O19

General Clinical Order Message

Usage

MSH

Message Header

R[{ NTE }]Notes and Comments(for Header)O

PID

Patient Identifiation

R[{ NTE }]Notes and Comments (for Patient ID)

O

PV1

Patient VisitR[ PV2 ]

Patient Visit 2

N[{ AL1 }]AllergyN

Order Common

R

TQ1

Timing/Quantity

R[{ TQ2 }]Timing/Quantity Order SequenceN

OBR

Observation RequestR[{ NTE }]Notes and Comments (for Detail))O

OBX

Observation/ResultO[{ NTE }]Notes and Comments (for Results)

O

{
ORC
{

}

[{

}]
}

⚫

MSHはオーダの出力単位(メッセージ)に１つ必須である。

⚫

⚫

V2.4以前は、これらオーダは一般オーダ(ORM/ORR)により実施されていたが、V2.4以降はORMが下位互換として残るのみとなった。また一般検査としてOML/ORLが新しく追加されたが、自動臨床検査オーダに特化していると解釈され、JAHIS規格では、生理検査は一般オーダメッセージ(OMG)で行うこととした。
【生理】1患者の一連のオーダにPIDとPV1を必須とする。

⚫

【生理】基本的に生理検査のアレルギー情報は、患者プロファイルとしてAL1に記載することとする。

⚫

ORC(NW)～OBR、ORC(PA)～OBX、ORC(CH)～OBRの順に繰り返すことで親子オーダを構成する。
（「図6.1-1：親子メッセージの関係」を参照）
ORC(CH)～OBRは検査項目の数だけ繰り返す。

⚫
⚫

【生理】OBR-25に”O”をセットする。
親レコード（ORC-1：‘PA’）では、OBR-4 で検査種別を、OBX-3,5 で患者プロファイル情報を記述する。一方、子レコード（ORC-1：‘CH’）では、OBR-4 で検査部位や検査詳細（方向）を記述する。部位などが異なる撮影に関しては、それぞれを子レコードで記述する。そして、親レコードと子レコードをORC-8 やOBR-29
で紐付ける。子レコードの場合、OBR-29：Parent Number（親レコード）の設定を必須とする。患者プロファ
イル情報と、検査種別（Ｘ線撮影、CT 撮影など）、検査部位（胸部、腹部など）、検査詳細（撮影方向など）、検査材料（薬剤、フィルムなど）をすべてOBR/OBX セグメントで記述する。新規オーダを示すORC セ© JAHIS 202211

グメント（ORC-1：NW）は、親レコードを示すORC セグメント（ORC-1：PA）の前に記述する。親子メッ
セージの関係を図6.1-1に示す。
ORC(NW)
ORC(PA)OBR
ORC(CH)OBR
ORC(CH)
OBR

新規オーダ
親オーダ
親オーダの記述（検査種別を指定）
1 番目の子オーダ
1 番目の子オーダの記述（撮影部位、方向等を指定）
2 番目の子オーダ
2 番目の子オーダの記述（撮影部位、方向等を指定）

図 6.1-1：親子メッセージの関係

6.1.2. ORG – 生理検査依頼応答メッセージ(O20)
生理検査依頼に対する応答は、一般オーダ応答メッセージ（ORG）イベント（O20）を用いる。
表6.1-2 ORG

生理検査依頼応答メッセージ

ORG^O20^ORG_O20

General Clinical Order Acknowledgement Message

Usage

MSH

Message Header

R

MSA

Message Acknowledgment

R[{ ERR }]

Error

O

[{ NTE }]Notes and Comments (for Header)O

PID

Patient Identification

RE[{ NTE }]Notes and Comments (for Patient ID)

O

Order Common

O

TQ1

Timing/Quantity

O[{ TQ2 }]Timing/Quantity Order SequenceN[ OBR ]

Observation RequestO[{ NTE }]Notes and Comments (for Detail)

O

[

{
ORC
[{

}]

}
]

⚫

MSHはオーダの出力単位(メッセージ)に１つ必須である。

⚫

V2.4以前は、これらオーダは一般オーダ(ORM/ORR)により実施されていたが、V2.4以降はORMが下位互換として残るのみとなった。また一般検査としてOML/ORLが新しく追加されたが、自動臨床検査オーダに特化していると解釈され、JAHIS規格では、生理検査は一般検査OMGで行うこととした。

⚫

【生理】1患者の一連のオーダにPIDとPV1を必須とする。

⚫
⚫

【生理】基本的に生理検査のアレルギー情報は、患者プロファイルとしてAL1に記載することとする。

⚫

【生理】OBR-25に”O”をセットする。

ORC(NW)～OBR、ORC(PA)～OBX、ORC(CH)～OBRの順に繰り返すことで親子オーダを構成する。
（「図6.1-1：親子メッセージの関係」を参照）
ORC(CH)～OBRは検査項目の数だけ繰り返す。

© JAHIS 2022

12

6.2. 患者情報更新(ADT/ACK)JAHIS データ交換規約 共通編 Ver.1.3「6.2．患者情報通知(ADT/ACK)」を参照のこと。

6.3. 患者情報照会(QBP/RSP)JAHIS データ交換規約 共通編 Ver.1.3「6.1．情報照会(QBP/RSP)」を参照のこと。

6.4. 生理検査依頼照会(QBP/RSP)
生理検査依頼照会は、情報照会（QBP/RSP）で行う。

6.4.1. QBP – 生理検査依頼照会メッセージイベント(ZS1)
生理検査依頼照会は、情報照会(QBP)イベント(ZS1)を用い、そのセグメント構文は以下のとおりである。
表6.4-1 QBP 生理検査依頼照会メッセージ
QBP^ZS1^QBP_Q11

Query for Physical Examination Order

Usage

MSH

Message Header

R[{ SFT }]Software Segment

N

QPD

Query Parameter Definition Segment

R

RCP

Response Control Parameters

R[ DSC ]

Continuation PointerN⚫
⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。
照会パラメータ定義(QPD)はメッセージに一つ必須である。

⚫

MSH-9は「QBP^ZS1^QBP_Q11」とする。

⚫

QPD-1は「ZS1^Order Query^JHSS0002」とする。

6.4.2. RSP – 生理検査依頼照会応答メッセージイベント(ZS2)
生理検査依頼照会応答は、情報照会応答メッセージ(RSP)イベント(ZS2)を用い、そのセグメント構文は以下のとおりである。
表6.4-2 RSP 生理検査依頼照会応答メッセージ
RSP^ZS2^RSP_K11

Query Response for Order Status

Usage

MSH

Message Header

R[{ SFT }]Software Segment

N

MSA

Message Acknowledgement

R[ ERR ]

Error

O

QAK

Query Acknowledgement

R

QPD

Query Parameter Definition Segment

R

PID

Patient Identification

RE[{ NTE }]Notes and Comments (for Patient ID)

O

PV1

Patient VisitR[ PV2 ]

Patient Visit 2

N[{© JAHIS 2022

13

RSP^ZS2^RSP_K11

Query Response for Order Status

Usage[{ AL1 }]AllergyN[{ OBX }]Observation related to the patientO

Common OrderR

TQ1

Timing/Quantity

R[{ TQ2 }]Timing/Quantity Order SequenceN

OBR

Observation RequestR[{ NTE }]Notes and Comments (for Detail))O

OBX

Observation/ResultsO[{ NTE }]Notes and Comments (for Results)

O

{
ORC
{

}

[{

}]
}
}]

⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。

⚫

メッセージ応答(MSA)セグメントはメッセージに一つ必須である。

⚫
⚫

応答時エラーが発生した場合はエラー(ERR)セグメントは必須である。
照会応答(QAK)セグメントはメッセージに一つ必須である。

⚫

照会パラメータ定義（QPD）セグメントはメッセージに一つ必須であり、QBPメッセージで記載されたものをそのまま記載する。

⚫

ORC(NW)～OBR、ORC(PA)～OBX、ORC(CH)～OBRの順に繰り返すことで親子オーダを構成する。
（「図6.1-1：親子メッセージの関係」を参照）
ORC(CH)～OBRは検査項目の数だけ繰り返す。

⚫

MSH-9は「RSP^ZS 2^RSP_K11」とする。

6.5. 検査ステータス通知(ORU/ACK)
検査ステータス通知には検査結果メッセージ(ORU/R01)を用いる。
検査ステータスは、ORC セグメントの ORC-5(オーダ状態)によって表わす。
「HL7 表 0038 - オーダ状態の値と検査ステータスの対応」は以下の通りである。検査ステータス通知で使用する値については、OBR-25
項の「表 7.7-1 OBR-25 と ORC-5 の組合せによる検査ステータス」を参照のこと。
HL7表 0038 - Order Status オーダ状態と検査ステータスの対応
Value
A
CA
CM
DC
ER
HD
IP
RP
SC

Description
Some, but not all, results available 部分的完了
Order was canceled オーダが取り消されたOrder is completed オーダが完了した
Order was discontinued オーダが中断した
Error, order not found エラー、オーダが見つからない
Order is on hold オーダが保留In process, unspecified 進行中、不定
Order has been replaced オーダが取替えられた
In process, scheduled 進行中、予定

検査ステータス【生理】
中止
検査終了
中断
受付（患者到着）、検査中
未受付（患者未到着）

6.5.1. ORU – 検査ステータス通知メッセージイベント(R01)
検査ステータス通知は検査結果メッセージ(ORU)イベント(R01)を用い、そのセグメント構文は以下のとおりである。

© JAHIS 202214

表6.5-1 ORU 検査ステータス通知メッセージ
ORU^R01^ORU_R01

Unsolicited Transmission of an Observation Message

Usage

MSH

Message Header

R

PID

Patient Identification

RE[ PV1 ]

Patient VisitO[ ORC ]

Order common

O

OBR

Observation RequestR{[ NTE ]}Notes and comments

O

TQ1

Timing/Quantity

O[{ TQ2 }]Timing/Quantity Order Sequnece

N

OBX

Observation related to OBRO{[ NTE ]}Notes and comments

O

Continuation Pointer

N

{
[

]
{

[{

}]
{[

]}
}
}
[ DSC ]⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。

6.5.2. ACK – 検査ステータス通知応答メッセージイベント(R01)
検査ステータス通知応答は、応答メッセージ(ACK)イベント(R01)を用い、そのセグメント構文は以下のとおりである。
表6.5-2 ACK 検査ステータス通知応答メッセージ
ACK^R01^ACK

General Acknowledge Message

Usage

MSH

Message Header

R

MSA

Message acknowledgment

R[{ ERR }]

Error

O

⚫
⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。
メッセージ応答(MSA)セグメントはメッセージに一つ必須である。

⚫

応答時エラーが発生した場合はエラー(ERR)セグメントは必須である。

© JAHIS 2022

15

6.6. 生理検査結果通知 (ORU/ACK)
生理検査結果通知には検査結果メッセージ(ORU/R01)を用いる。

6.6.1. ORU – 生理検査結果通知メッセージイベント(R01)
生理検査結果通知時には検査結果メッセージ(ORU)イベント(R01)を用い、そのセグメント構文は以下のとおりである。
表6.6-1 ORU 生理検査結果通知メッセージ
ORU^R01^ORU_R01

Unsolicited Transmission of an Observation Message

Usage

MSH

Message Header

R

PID

Patient Identification

RE[ PV1 ]

Patient VisitO[ ORC ]

Order common

O

OBR

Observation RequestR{[ NTE ]}Notes and comments

O

TQ1

Timing/Quantity

O[{ TQ2 }]Timing/Quantity Order Sequnece

N

OBX

Observation related to OBRO{[ NTE ]}Notes and comments

O

Continuation Pointer

N

{
[

]
{

[{

}]
{[

]}
}
}
[ DSC ]⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。

⚫

【生理】OBR-25（結果状態）に “F” をセットする。

⚫

【生理】生理検査結果通知メッセージ（OBR-25="F"）の場合、TQ1-7（開始日時）、OBX-14（検査日時）を値必須とする。
【生理】データを一意に識別できるユニークなID（DataUID)をOBX-5にセットし、データ保存確認の際の問い合せキーとして使用することができる。その場合、受信側でデータ保存する際はDataUIDにて検索可能
なように検査結果と紐付けて保存管理する必要がある。

⚫

6.6.2. ACK – 生理検査結果通知応答メッセージイベント(R01)
生理検査結果通知応答時には、応答メッセージ(ACK)イベント(R01)を用い、そのセグメント構文は以下のとおりである。

© JAHIS 2022

16

表6.6-2 ACK 生理検査結果通知応答メッセージ
ACK^R01^ACK

General Acknowledge Message

Usage

MSH

Message Header

R

MSA

Message acknowledgment

R[{ ERR }]

Error

O

⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。

⚫

メッセージ応答(MSA)セグメントはメッセージに一つ必須である。

⚫

応答時エラーが発生した場合はエラー(ERR)セグメントは必須である。

6.7. データ保存確認(QBP/RSP)
データ保存確認には、パラメータによる照会(QBP)メッセージを用い、それに対する応答にはセグメント
パターン応答(RSP)メッセージを使用する。その場合のセグメントと構文規則は以下の通りである。

6.7.1. QBP – データ保存確認メッセージ イベント(ZS3)
データ保存確認メッセージ(ZS3)は、DataUID を指定し、データ保存確認を送信するメッセージである。
表6.7-1 QBP データ保存確認メッセージ
QBP^ZS3^QBP_Q11

Query of Document Storage Status Message

Usage

MSH

Message Header

R[{ SFT }]Software Segment

O

QPD

Query Parameter Definition Segment

R

RCP

Response Control Parameters

R[ DSC ]

Continuation PointerO⚫
⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。
照会パラメータ定義(QPD)はメッセージに一つ必須である。

⚫

MSH-9は「QBP^ZS3^QBP_Q11」となる。

⚫

QPD-1は「ZS3^Storage Commitment^JHSS0002」となる

6.7.2. RSP – データ保存確認応答メッセージ イベント(ZS4)
データ保存確認応答メッセージ(ZS4)は、データ保存確認メッセージ(ZS3)に対する応答メッセージである。
表6.7-2 RSP データ保存確認応答メッセージ
RSP^ZS4^RSP_K11
MSH

Query Response of Document Storage Status
Message Header
Message

Usage
R[{ SFT }]Software Segment

O

MSA

Message Acknowledgement

R[ ERR ]

Error

O

QAK

Query Acknowledgement

R

QPD

Query Parameter Definition Segment

R[ DSC ]

Continuation PointerO© JAHIS 202217⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。

⚫
⚫

メッセージ応答(MSA)セグメントはメッセージに一つ必須である。
保存済みの場合、MSA-1=AA 未保存の場合 MSA-1＝NF で応答する。

⚫

応答時エラーが発生した場合はエラー(ERR)セグメントは必須である。

⚫

照会応答(QAK)セグメントはメッセージに一つ必須である。

⚫

照会パラメータ定義(QPD)セグメントはメッセージに一つ必須であり、QBPメッセージで記載されたものをそのまま記載する。

⚫

MSH-9は「RSP^ZS4^RSP_K11」となる。

6.8. 生理検査結果照会(QRY/ORF)
生理検査結果照会時には問合せ(QRY)メッセージを用い、応答は生理検査結果照会（ORF）メッセージを使用する。

6.8.1. QRY – 生理検査結果照会メッセージイベント(R02)
生理検査結果照会メッセージ(QRY)イベント(R02)は、生理検査結果の照会をするイベントである。
表6.8-1 QRY 生理検査結果照会メッセージ
QRY^R02^QRY_R02

Query

Usage

MSH

Message Header

R

QRD

Query Definition

R

QRF

Query Filter

R⚫
⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。
照会定義(QRD)セグメントはメッセージに一つ必須である。

⚫

問合せフィルタ (QRF)セグメントはメッセージに一つ必須である。

6.8.2. ORF – 生理検査結果照会応答メッセージイベント (R04)
生理検査結果照会応答メッセージ(ORF)イベント(R04)は、生理検査結果照会に対する応答をするイベントである。
表6.8-2 ORF

生理検査結果照会応答メッセージ

ORF^R04^ORF_R04

Observational Report

Usage

MSH

Message Header

R

MSA

Message Acknowledgment

R

QRD

Query DefinitionR[ QRF ]

Query Filter

O

PID

Patient ID

RE[{ NTE }]Notes and Comments

O[ ORC ]

Order common

O

OBR

Observation requestR{[ NTE ]}Notes and comments

O

{[

]
{

© JAHIS 2022

18

ORF^R04^ORF_R04

Observational Report

Usage

TQ1

Timing/Quantity

R[{ TQ2 }]Timing/Quantity Order Sequnece

N[ OBX ]

Observation/ResultO[{ NTE }]Notes and Comments (for OBX)O

Clinical Trial Identification

N[{ ERR }]

Error

O

[ DSC ]

Continuation Pointer

N

[{

}]
{

}
{[ CTI ]}}}⚫
⚫

メッセージヘッダ(MSH)セグメントはメッセージに一つ必須である。
メッセージ応答(MSA)セグメントはメッセージに一つ必須である。

⚫

照会定義(QRD)セグメントはメッセージに一つ必須である。

⚫

応答時エラーが発生した場合はエラー(ERR)セグメントは必須である。

⚫

【生理】TQ1-7（開始日時）、OBX-14（検査日時）を本メッセージORF^R04の各セグメント内では値必須とする。

© JAHIS 2022

19

7. 関連セグメント詳細
7.1. AL1 - Patient Allergy Information Segment 患者アレルギー情報セ
グメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

7.2. ERR - Error Segment エラーセグメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

7.3. EVN - Event Type Segment セグメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

7.4. MSA - Message Acknowledgment Segment メッセージ応答セグ
メント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

7.5. MSH - Message Header Segment メッセージヘッダセグメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

7.6. NTE - Notes and Comments Segment 注釈コメントセグメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

© JAHIS 2022

20

7.7. OBR - Observation Request Segment 検査要求セグメント
検査要求(OBR)セグメントは、診断、検査、身体検査あるいは所見などを要求するオーダに特有な情報を伝送する。
検査要求セグメントは、診断要求（例えば生理検査、EKG）あるいは検査要求(例えば生理検査、身体検査)など特定の要求の属性を定義する。依頼者があるまとまった検査を要求する場合、必ずオーダセグメントを指定する。生理検査では通常、個々の検査ごとに１つの独立したオーダセグメントを生成する。
OBR セグメント属性一覧を示す。このセグメント内の(＋)項目は依頼者ではなく実施者が作成し、その値は、OBR セグメントが報告書の一部として返信されたとき必要に応じて設定する。したがって、実施者が新規オーダを受理する場合、(＋)項目の値を設定することはない。ただし実施者がオーダを開始する場合は例外である。その場合、実施者オーダ番号が設定されるが、依頼者オーダ番号はブランクでもよい。
【生理】OBR-7（検査日時）および OBR-8（検査終了日時）は、例えば検体検査の場合、検体採取の開始
および終了を表わすが、生理検査では使用しない。
検査日時の格納にはそれぞれ TQ1-7（開始日時）、
TQ1-8（終了日時）を使用する。
HL7属性表－OBR－Observation Request Segment
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

LEN
4
22
22
250
2
26
26
26
20
250
1
250
300
26
300
250
250

DT
SI
EI
EI
CE
ID
TS
TS
TS
CQ
XCN
ID
CE
ST
TS
SPS
XCN
XTN

OPT
O
C
C
R
B
O
C
O
O
O
O
O
O
B
B
O
O

JAHIS
O
RE
RE
R
B
O
C
O
O
O
O
O
O
B
B
O
O

18
19
20
21
22

60
60
60
60
26

ST
ST
ST
ST
TS

O
O
O
O
C

O
O
O
O
C

23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

40
10
1
400
200
250
200
20
250
200
200
200
200
26
4
250
250
250
30
1

MOC
ID
ID
PRL
TQ
XCN
EIP
ID
CE
NDL
NDL
NDL
NDL
TS
NM
CE
CE
CE
ID
ID

O
O
C
O
B
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O

O
O
C
O
B
O
C
O
O
O
O
O
O
O
O
O
O
O
O
O

© JAHIS 2022

RP/#

TBL#

Y

Y
Y/2

0074
0123
Y
Y
0124
Y
Y
Y
Y

Y
Y
0224
0225

21

検査要求セグメント

ELEMENT NAME
Set ID – Observation Request セットID －検査要求
Placer Order Number 依頼者オーダ番号
Filler Order Number ＋ 実施者オーダ番号
Universal Service ID 検査項目群ID
Priority
優先度
Requested Date/Time オーダ発行日時
Observation Date/Time ＃ 検査日時
Observation End Date/Time ＃ 検査終了日時
Collection Volume 採取量
Collector Identifier 採取者ID
Specimen Action Code 検体処置コード
Danger Code 危険（検体）コード
Relevant Clinical Information 関連臨床情報
Specimen Received Date/Time 検体受理日時
Specimen Source 検体採取元
Ordering Provider 依頼者
Order Callback Phone Number オーダコールバック用電話番号
Placer Field 1 依頼者フィールド１
Placer Field 2 依頼者フィールド２
Filler Field 1 ＋ 実施者フィールド１
Filler Field 2 ＋ 実施者フィールド２
Results Rpt/Status Chng - Date/Time ＋ 結果報告/状態
変更 －日時Charge to Practice ＋ 課金
Diagnostic Serv Sect ID 診断部門IDResult Status ＋ 結果状態
Parent Result ＋ 親結果
Quantity/Timing 数量/タイミング
Result Copies To 結果配布先
Parent Number 親番号
Transportation Mode 患者移動モード
Reason for Study 検査理由
Principal Result Interpreter ＋ 結果判定責任者
Assistant Result Interpreter ＋ 結果判定アシスタント
Technician ＋ 医療技術者
Transcriptionist ＋ 転記者
Scheduled Date/Time ＋ 予定日時
Number of Sample Containers 検体容器数
Transport Logistics of Collected Sample 採取検体搬送
Collector's Comment 採取者コメント
Transport Arrangement Responsibility 搬送調整者
Transport Arranged 搬送調整結果
Escort Required 随行者要否

SEQ
43

LEN
250

DT
CE

OPT
O

JAHIS
O

RP/#
Y

TBL#

44
45
46

250
250
250

CE
CE
CE

O
O
O

O
O
O

Y
Y

0411

47

250

CE

O

O

Y

0411

48

250

CWE

C

C

49

2

IS

O

O

0088

0507

ELEMENT NAME
Planned Patient Transport Comment 計画患者搬送コメ
ント
Procedure Code 手続きコード
Procedure Code Modifier 手続きコード修飾子
Placer Supplemental Service Information 依頼者補足サービス情報Filler Supplemental Service Information 実施者補足サービス情報
Medically Necessary Duplicate Procedure Reason.
医学的に必要な重複検査
Result Handling 結果操作＋：検査依頼の場合は使用しない＃：生理検査では使用しない

注記：これらの項目の完全な説明については、HL7 V2.5 第 4 章を参照のこと。このセグメント定義は利用者のために検査報告メッセージに関する項目を明確にする。
［例］OBR|1|A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...<CR>【生理】OBR-2/3 については値の性質上、値が存在すれば必須とした。

OBR フィールド定義
OBR-1 Set ID – Observation Request セット ID－検査要求 (SI) 00237
定義： 最初の送信オーダには通し番号 1 が割り当てられ、2 番目のオーダには通し番号 2 が割り当てられるものとする。3 番目以降同様。
上位 ORC に対する通番。初期値１、増分１。必要に応じ同一 ORC セグメントに対して１から付番される通し番号（オプション）。

OBR-2 Placer Order Number 依頼者オーダ番号 (EI) 00216
成分： <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID type
(ID)>

定義： ORC-2 依頼者オーダ番号に同じ。
第 1 成分の文字列で個々の OBR を識別する。15 文字以内が望ましいが必須要件ではない。これは依頼アプリケーションによって割り当てられ、ある依頼アプリケーションから送信されるすべてのオー
ダの中から特定のオーダを一意に識別する。第 2 の成分ネームスペース ID は、ユーザによって定義されたコード化された値であり、特定のアプリケーションと一意に結び付けられている。HL7 においては「６文字以内が望ましいが必須要件ではない。
」とされているが、日本における運用では 6 文字以内とする。ORC-2 との関係については ORC-2 の説明を参照のこと。

OBR-3 Filler Order Number 実施者オーダ番号 (EI) 00217
成分： <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID type(ID)>

定義：このフィールドは、実施アプリケーションと関連したオーダ番号である。オーダおよびその関連する検査に対する永久的な識別子。
第 1 成分は個々のオーダセグメント（例えば OBR)を識別する文字列である。これはオーダ実施（受信）アプリケーションによって割り当てられ、ある実施アプリケーション（例えば LIS）によるすべてのオーダの中から特定のオーダを一意に識別する。第 2 の成分はユーザに定義されたコード化された値であって、ネットワーク上の他のアプリケーション中から特定のアプリケーションを一意に識別する。この固有性は長期間継続しなければならない。
第 2 から第 4 までの成分は、実施者アプリケーション ID を含むが、これらは HD データ型の形をしている。第 2 の成分はユーザに定義されたコード化された値であって、ネットワーク上の他のアプリ
ケーション中から特定のアプリケーションを一意に識別する。HL7 においては「6 文字以内が望まし
いが必須要件ではない。
」とされているが、日本における運用では 6 文字以内とする。
ORC-3 との関係については ORC-3 の説明を参照のこと。

© JAHIS 2022

22

OBR-4 Universal Service ID 検査項目群 ID (CE) 00238
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：要求された検査/試験/セットの識別子コード。このコードは、ローカル・コードまたは“汎用”
コードのいずれか、もしくはその両方を基準に設定できる。
“汎用”手順による識別子を使用することが望ましい。
【生理】親オーダの場合は検査分類を指定するコードを設定する。例えば心電図検査、超音波検査、肺機能検査などを指定するコードである。子オーダの場合は検査種別を指定するコードを設定する。
例えば安静時 12 誘導検査、心臓超音波検査などを指定するコードである。汎用コードとしては
JLAC10 コードを推奨する。また、検査結果照会において、該当検査が無い場合、OBR-4 には|””|をセットする。

OBR-5 Priority 優先度 (ID) 00239
定義：このフィールドは下位互換性のためだけに用意されている。

OBR-6 Requested Date/Time 要求日時 (TS) 00240
定義：このフィールドは下位互換性のためだけに用意されている。

OBR-7 Observation Date/Time 検査日時 (TS) 00241
定義：このフィールドは臨床に関連する検査の日時である。
【生理】検査開始日時は、TQ1-7 開始日時を用い指示する。OBR-7 を入力する場合は、TQ1-7 と同じ情報を入力する。

OBR-8 Observation End Date/Time 検査終了日時 (TS) 00242
定義：検査終了日時。
【生理】OBR-8 を入力する場合は、TQ1-8 終了日時にも同じ情報を入力する。

OBR-9 Collection Volume 採取量 (CQ) 00243
定義：検体検査の場合、検体量。

OBR-10 Collector Identifier 採取者 ID (XCN) 00244
定義：検体検査の場合、このフィールドは、検体を採取した個人、部門あるいは施設を識別する。

OBR-11 Specimen Action Code 検体処置コード (ID) 00245
定義：検体検査の場合、このオーダに伴ってあるいは先行して実施される検体処置。

OBR-12 Danger Code 危険(検体)コード (CE) 00246
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：危険であることが知られている、あるいは疑われる患者・検体を示すコードかテキスト、ある
いはその両方(例えば、陽性結核患者、肝炎患者の血液などの感染情報)。コードとテキストのどちらかあるいはいずれも指定しない場合がある。指定する場合、コードは必ず第 1 成分に指定し、任意のフリーテキストを第 2 成分に指定する。したがって、コードだけを省略する場合、成分デリミタをフ
リーテキストの前に指定しなければならない。

OBR-13 Relevant Clinical Information 関連臨床情報 (ST) 00247
定義：このフィールドには、患者に関する追加臨床情報が記述される。このフィールドは、検査結果の診断が要求された場合、疑われる病状や臨床所見を報告するのに使用する。たとえば、血中ガスの二酸化炭素量、パップ試験時の月経周期、および診断・検査に影響を及ぼすその他の条件を報告する場合など。ただし、オーダセグメントの直後に一連の OBX セグメントを追加することで、より構造化された形式でこの種の情報を送ることが可能である。従って、身体情報(身長・体重やバイタルサ
インなど)、検査情報、投薬情報などは OBX セグメントを利用することを推奨する。

© JAHIS 2022

23

OBR-14 Specimen Received Date/Time 検体受領日時 (TS) 00248
定義：このフィールドは下位互換性のためだけに用意されている。

OBR-15 Specimen Source 検体材料 (SPS) 00249
定義：このフィールドは下位互換性のためだけに用意されている。

OBR-16 Ordering Provider 依頼者 (XCN) 00226
成分： <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR)(ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)>^<Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)>^<Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code(ID)> ^ <Name Context (CWE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order(ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>^<Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>

定義： 検査依頼者の ID。ID コードあるいは名前、またはその両方を指定できる。これは ORC－12－依頼者と同じである。検査依頼医師をセットする。

OBR-17 Order Callback Phone Number オーダ問合せ電話番号 (XTN) 00250
成分： <DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)>^<Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code(NM)> ^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text(ST)> ^ <Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone
number (ST)>

定義：状態あるいは結果を標準フォーマットで報告する際の電話番号。可能であれば、内線または呼出番号(あるいはその両方)も併せて指定する。

OBR-18 Placer Field #1 依頼者フィールド 1 (ST) 00251
定義：依頼者フィールド＃1。依頼者によって送られたテキストは、結果と共に返される。

OBR-19 Placer Field #2 依頼者フィールド 2 (ST) 00252
定義：依頼者フィールド＃1 に類似。

OBR-20 Filler Field #1 実施者フィールド 1 (ST) 00253
定義：実施者(診断サービス)により任意の使用目的に定義可能。

OBR-21 Filler Field #2 実施者フィールド 2 (ST) 00254
定義：実施者フィールド＃1 に類似（実施者により任意の使用目的に定義可能）。

OBR-22 Results Rpt/Status Chng Date/Time 結果報告／状態変更－日時 (TS) 00255
成分： <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：結果の報告日時、あるいは状態の変更日時。このフィールドでは、結果を報告書に書込み・発行した日時を示す。あるいはオーダ状態に定義にされたような状態が入力・変更された日時を示す。
通常、依頼側は最後に結果を受信した日時(前回更新日)より後で報告された結果だけ入力すべきである。(電文発信日ではない)

OBR-23 Charge To Practice 課金 (MOC) 00256
成分： <Monetary Amount (MO)> ^ <Charge Code (CWE)>

定義：HIS は検査項目から課金情報を生成する。

OBR-24 Diagnostic Serv Sect ID 診断サービス部門 ID (ID) 00257
定義：診断を実施した診断サービス部門。検査が外部サービスによって実施された場合、そのサービスの ID がここに記録される。取りうる値については、「HL7 表 0074－診断サービス部門 ID」を参照のこと。

© JAHIS 2022

24

HL7表 0074 – Diagnostic service section ID 診断サービス部門ID
Value
AU
BG
BLB
CUS
CTH
CT
CH

Description
Audiology 聴力検査
Blood gases 血中ガス
Blood bank 血液バンク
Cardiac Ultrasound 循環器用超音波
Cardiac catheterization 心臓カテーテル
CAT scan CAT スキャン
Chemistry 化学

Value
OUS
OT
OTH
OSL
PHR
PT
PHY

CP
EC

Cytopathology 細胞検査
Electrocardiac (e.g., EKG, EEC, Holter) 心電関係（例えば EKG、EEC、ホルター）
Electroneuro (EEG, EMG, EP, PSG) 神経筋
電関係（EEG、EMG）
Hematology 血液検査
Bedside ICU Monitoring ベッドサイドの ICU
モニタ
Immunology 免疫検査
Laboratory ラボラトリー
Microbiology 微生物検査
Mycobacteriology ヒト型結核菌検査
Mycology （真）菌検査
Nuclear medicine scan 核医学スキャン
Nuclear magnetic resonance 核磁気共鳴
Nursing service measures 看護サービス検査

PF
RAD

Description
OB Ultrasound 産婦人科用超音波
Occupational Therapy 作業療法
Other その他
Outside Lab 外部検査
Pharmacy 処方
Physical Therapy 物理療法
Physician (Hx. Dx, admission note, etc.)
医（Hx、Dx、入院情報メモなど）
Pulmonary function 肺機能Radiology 放射線学

RXRadiograph 放射線写真

RUS
RC

Radiology ultrasound 放射線超音波
Respiratory Care (therapy) 呼吸療法（治療）

RT
SR
SP
TX
VUS
VR
XRC

Radiation therapy 放射線治療
Serology 血清検査
Surgical Pathology 外科病理学
Toxicology 毒物検査
Vascular Ultrasound 血管超音波
Virology ウイルス検査
Cineradiograph シネ放射線

EN
HM
ICU
IMM
LAB
MB
MCB
MYC
NMS
NMR
NRS

内科

OBR-25 Result Status 結果状態 (ID) 00258
定義：このオーダの結果状態。状態は、オーダに関連する結果すべてに適用される。オーダ状態の照会の際、OBX セグメントで実現されるレベルの応答より詳細なレベルの応答が必要でないときに、このフィールドがよく使用される。このフィールドへは、実施者しか値を設定することができない。
各結果の状態が必要な場合、OBX－11－検査結果状態を使用することができる。取りうる値について
は、「HL7 表 0123－結果状態」を参照のこと。
HL7表 0123 – Result Status 結果状態
Value
O
I
S

Description
Order received; specimen not yet received オーダ受信済；検体未受領
No results available; specimen received, procedure incomplete
結果無し；検体受領済、手続き未完了
No results available; procedure scheduled, but not done
結果利用不可；手続き予定済だが未実施

A

Some, but not all, results available 一部（すべてではない）の結果利用可

P

Preliminary: A verified early result is available, final results not yet obtained
予備的；検証された初期結果利用可、最終結果未取得

C

Correction to results 結果の訂正

R
F

Results stored; not yet verified 結果保存済；未検証
Final results; results stored and verified. Can only be changed with a corrected result.
最終結果；結果保存済、検証済。訂正結果とのみ書き替え可能
No results available; Order canceled. 結果利用不可；オーダ取消
No order on record for this test. (Used only on queries)
この検査のオーダレコードなし（照会でのみ使用される）
No record of this patient. (Used only on queries)
この患者のレコードなし(照会でのみ使用される)

X
Y
Z

Comment

結果状態の送信には、次の 2 つの方法がある。
状態がオーダ全体である場合、ORC-15 オーダ発行日時と ORC-5 オーダ状態を使用する。
状態がオーダ詳細セグメントに関係する場合、OBR-25 結果状態と OBR-22 結果報告書／状態変化－
日付／時間を用いる。
両方が存在する場合、OBR 値は ORC 値を無視する。
OBX セグメントがない場合、オーダ状態照会に対する応答として使用される。

© JAHIS 202225

各結果の個々の状態が必要な場合、OBX-11 検査結果状態で示す場合がある。
【生理】各メッセージと検査の状態を表す OBR-25 と ORC-5 の組合せを以下に示す。
表7.7-1 OBR-25とORC-5の組合せによる検査ステータス
メッセージ
生理検査依頼OBR-25O

ORC-5SC

Comment

検査ステータス通知

IIP

受付（到着確認）

検査ステータス通知

S

IP

検査中

検査ステータス通知

S

DC

検査中断

検査ステータス通知

F

CM

検査終了

生理検査結果通知

FCM

検査結果の送信（オーダの完了）

生理検査結果通知

PSC

検査結果の送信（暫定結果あり）

検査ステータス通知

X

CA

検査中止

オーダ受信

注記：検査終了は、OBR-25 = 'F' 、ORC-5 = 'CM' の組合せで表現ができるが、生理検査結果通知と同じ組合せのため、どちらの意味で使用するのかを関係者間で合意しておくこと。

OBR-26 Parent Result 親結果 (PRL) 00259
成分： <Parent Observation Identifier (CWE) ^ <Parent Observation Sub-identifier (ST)> ^<Parent
Observation Value Descriptor (TX)>

定義：このフィールドは他のタイプ(たとえば毒物学)との連携を可能にするために定義される。この重要な情報は、OBR-29-親番号の情報と組合せて、このオーダに関する親結果の OBX セグメントを一意に識別する。

OBR-27 Quantity/Timing 数量／タイミング (TQ) 00221
定義：このフィールドは下位互換性のためだけに用意されている。

OBR-28 Result Copies To 結果配布先 (XCN) 00260
成分： <ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR)(ST)> ^ <Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority (HD)>^<Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme (ID)>^<Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation Code(ID)> ^ <Name Context (CWE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order(ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^<Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>

定義：検査報告書を受け取る人。ローカルの取り決めによって、ID 番号あるいは名前のいずれかを省略してもよい。報告書送付先として科別や病棟を指示してもよい。

OBR-29 Parent Number 親番号 (EIP) 00261
成分： <Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>

定義：ORC－8－親と同一。但し、ORU メッセージ（到着確認／検査結果）では、OMG メッセージの ORC-2(,ORC-3)と同一。子オーダの場合に、このフィールドが必要になる。
親フィールドには、成分が 2 つある。第 1 成分には親の依頼者オーダ番号が入る。第 2 成分はオプシ
ョンであり、ここには親の実施者オーダ番号が入る。このフィールドは、副成分をもつ、依頼者オー
ダ番号成分と実施者オーダ番号成分の 2 つの成分で伝達される。

OBR-30 Transportation Mode 患者移動モード (ID) 00262
定義：適用可能な場合、患者を移動するかどうか(あるいは移動方法)。取りうる値に関しては、「HL7
表 0124－患者移動モード」を参照のこと
HL7表 0124 – Transportation Mode 患者移動モード
Value
CART
PORT
WALK
WHLC

Description
Cart – patient travels on cart or gurney 患者はカートまたは担架で移動する
The examining device goes to patient's location 検査装置が患者のもとへ移動する
Patient walks to diagnostic service 患者は歩行により移動する
Wheelchair 車いすを使用する© JAHIS 2022

26

Comment

OBR-31 Reason For Study 検査理由 (CE) 00263
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：適切な回答を得るのにこのフィールドを使用しなければならない検査もある。

OBR-32 Principal Result Interpreter 結果判定責任者 (NDL) 00264
成分： <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)>^<Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location
Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

定義：検査を診断し、報告書の内容に責任を負う医師あるいは臨床医の ID。

OBR-33 Assistant Result Interpreter 結果判定アシスタント (NDL) 00265
成分： <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)>^<Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location
Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

定義：この検査の診断を支援した立会臨床医。

OBR-34 Technician 医療技術者 (NDL) 00266
成分： <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)>^<Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location
Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

定義：実施担当臨床技師。

OBR-35 Transcriptionist 転記者 (NDL) 00267
定義：報告書の口述筆記を担当する人。通常、本フィールドは使用しない。

OBR-36 Scheduled - Date/Time 予定日時 (TS) 00268
成分： <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：実施者がスケジュールした検査日時。このフィールドは、ある特定の検査をスケジュールして欲しいという要求に対する結果を表しており、これによりスケジュールされた検査日時を依頼者に通知することができる(結果専用) 。

OBR-37 Number Of Sample Containers 検体容器数 (NM) 01028
定義：検体検査の場合、受領検体容器の数。

OBR-38 Transport Logistics Of Collected Sample 採取検体搬送 (CE) 01029
定義：検体検査の場合、このフィールドは診断サービス実施者への検体到着で意味がある。

OBR-39 Collector’s Comment 採取者コメント (CE) 01030
定義：検体に関する付加的コメント。

OBR-40 Transport Arrangement Responsibility 搬送調整者 （CE） 01031
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：予約検査などで検体搬送の手配などを行った者。例えば依頼者、実施者、患者など。

OBR-41 Transport Arranged 搬送調整結果 (ID) 01032
定義：検体搬送手配の結果状態。
HL7表 0224 – Transport Arranged 搬送調整
Value
A
N

© JAHIS 2022

Description
Arranged 手配済み
Not Arranged 未手配

27Comment

ValueU

Description

Comment

Unknown 不明

OBR-42 Escort Required 随行者要否 (ID) 01033
定義：患者が診断サービス部門へ出向くに必要な随行者の要否。OBR-43 の併用が一般的。
HL7表 0225 – Escort Required 随行者要否
Value
R
N
U

Description

Comment

Required 必要
Not Required 不要
Unknown 不明

OBR-43 Planned Patient Transport Comment 計画患者搬送コメント (CE) 01034
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：患者が診断サービス部門へ出向く際の搬送や随行に関するコメント。

OBR-44 Procedure Code 手続きコード (CE) 00393
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^<Coding System
Version ID (ST)>^<Alternate Coding System Version ID (ST)>^<Original Text (ST)>

定義：このフィールドは、もしあればフィールド 4 において報告された汎用サービス ID と共に関連した手続きに割り当てられた唯一の識別子である。
「HL7 表 0088－手続きコード」に定義されたテーブルの値を使用する。このフィールドは，臨床関連のシステムと互換性を取る為 CE タイプである。

OBR-45 Procedure Code Modifier 手続きコード修飾子 (CE) 01316
定義：このフィールドはフィールド 44 において報告された手続きコードに適用できれば手続きコー
ド修飾子を含む。

OBR-46 Placer Supplemental Service Information 依頼者補足サービス情報 (CE) 01474
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^<Coding System
Version ID (ST)>^<Alternate Coding System Version ID (ST)>^<Original Text (ST)>

定義：このフィールドは、依頼者システムから OBR-4 汎用サービス ID で報告された手続きコードにより実施者システムまで送られた補給サービス情報を含む。このフィールドは OBR セグメントの他の不明なオーダ詳細情報を解決する為に使われる。複数の補助サービス情報の要素が報告されるかもしれない。
「使用者定義表 0411－補助サービス情報値」を参照のこと。
このフィールドは、検査が右、または、左に行われるべきであるかどうかのような詳細について述べるために使われ得る。 たとえば、腕の治療およびオーダは右か左かを区別しないし、また、その治療が対比されるかに関わらない（オーダ基本ファイルがそのような区別をしないとき）。

OBR-47 Filler Supplemental Service Information 実施者補足サービス情報 (CE) 01475
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^<Coding System
Version ID (ST)>^<Alternate Coding System Version ID (ST)>^<Original Text (ST)>

定義：
このフィールドは、OBR-4 汎用サービス ID によって報告された処置コードにより依頼者システムから実施者システムに送られる補足サービス情報として使われる。このフィールドは OBR セグメントの他の不明なオーダ詳細情報を解決する為に使われる。典型的に、それは OBR-46 依頼者補足情報により実施者システムに反映される、そのオーダが修正されないかぎり実施者システムは実際にこれを用いて遂行された物のどちらかのケースを報告するのに使われる。多重補足サービス情報要素は報告される。
「使用者定義表 0411 – 補助サービス情報値」を参照のこと。
このフィールドは、検査が右、または、左に行われるべきであるかどうかのような詳細について述べるために使われ得る。 たとえば、腕の治療およびオーダは右か左かを区別しないし、その治療が対比されるかに関わらない（オーダ基本ファイルがそのような区別をしないとき）。

© JAHIS 202228

使用者定義表 0411 – Supplemental service information values 補助サービス情報値
Value

Description
推奨値なし
個々の実装においては“SNOMED DICOM Micro-glossary(SDM)”のような語彙
または私的な(ローカルな)入力値を使用してもよい。

OBR-48 Medically Necessary Duplicate Procedure Reason 重複検査を要する医学的理由 (CWE)01646
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^<Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^<Original Text (ST)>

定義：この項目は OBR-44(手続きコード)の理由を文書で証明するために使用される。医学的に必要な事項、患者のために同じ日や以前に行われたサービスなどの複写である。理由はコード化された値、もしくはフリーテキストで入力してもよい。
この項目は、重複検査の課金先に関する会計用情報を提供するものである。

OBR-49 Result Handling 結果の取り扱い(IS) 01647

定義： 結果の取り扱いに関する情報を送信する。たとえば、オーダは、リクエスターへのリターンのための患者に結果(たとえば X 線フィルム)が与えられることを明示する。
特別なことが無ければ使用しない。
HL7表 0507 – Observation Result Handling 検査結果操作
Value
F
N

© JAHIS 2022

Description
Film-with-patient 患者へのフィルム提供
Notify provider when ready 準備が出来次第通知

29

Comment

7.8. OBX - Observation/Result Segment 検査結果セグメント
OBX セグメントは単一検査あるいは部分検査を転送するのに使用される。それは分割不可能なレポートの最小単位に相当する。OBX セグメントはまた、CDA ドキュメントや DICOM イメージデータのようなカプセル化したデータも含み得る。
その主な機能はレポートメッセージで検査関連情報を伝達することである。しかし、OBX を検査オーダに含めることもできる（HL7 V2.5 4.4 節オーダメッセージ定義を参照のこと）。この場合、実施者が作成する検査結果を解釈できるように、実施者が必要とする臨床情報を OBX で伝送する。例えば、血液酸素を血液ガス検査室へオーダする場合に吸気酸素を報告するのに OBX は必要であり、あるいはパップ塗沫試験を細胞診検査室へオーダするに場合に含まれているべき月経周期情報を報告するためにも OBX は必要である。
HL7 V2.5 付録 7.A に記述されているコードは、検査結果を適切に解釈するために、検査実施部門が必要とする個々の情報を識別するためのものである。 OBX は、患者の臨床情報を含む必要のある他の HL7 メッ
セージ中にもある。
HL7属性表－OBX－Observation/Result Segment
SEQ
1
2
3
4
5
6
7
8
9
10
11
12

LEN

DT

4
3
250
20
65536
250
60
5
5
2
1
26

SI
ID
CE
ST
*
CE
ST
IS
NM
ID
ID
TS

OPT
O
C
R
C
C
O
O
O
O
O
R
O

JAHIS
O
C
R
C
C
O
O
O
O
O
R
O

13

20

ST

O

O

14
15
16
17
18

26
250
250
250
22

TS
CE
XCN
CE
EI

O
O
O
O
O

RE*
O
O
O
O

19

26

TS

O

O

RP/#

TBL#
0125

Y

Y

0078

Y

0080
0085

Y
Y
Y

検査結果セグメント

ELEMENT NAME
Set ID - OBX セットID
Value Type 値型
Observation Identifier 検査項目
Observation Sub-ID 検査サブID
Observation Value 検査結果値
Units 単位
References Range 標準値
Abnormal Flags 異常フラグ
Probability 確率
Nature of Abnormal Test 異常検査の特性
Observ Result Status 検査結果状態
Effective Date of Reference Range 標準値有効
日付
User Defined Access Checks ユーザ定義アクセス点検Date/Time of the Observation 検査日時
Producer's ID 実施者ID
Responsible Observer 検査責任者
Observation Method 検査方法
Equipment Instance Identifier 機器インスタンス識別子
Date/Time of the Analysis 分析日時

［例］OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM|...<CR>【生理】OBX-3 が同一の OBX セグメントに複数存在する場合、OBX-4（検査サブ ID）は必須とする。また、特に心電図検査では一つの検査日時に対して複数の測定を行うため、OBX-14（検査日時）は値があれば必須とする。

OBX フィールド定義
OBX-1 Set ID - OBX セット ID (SI)00569

定義：このフィールドは、通し番号を含んでいる。ASTM との互換性を維持するためのもの。

OBX-2 Value Type 値型 (ID) 00570
定義：このフィールドは、OBX 内の検査結果値のフォーマットを含んでいる。
「OBX-11 検査結果状態」が「X」でない場合、それは値を持たねばならない。値が CE である場合、結果はコード化入力© JAHIS 202230

値でなければならない。値型が TX または FT である場合、結果はテキスト群である。値型の検査で採りうる値は「HL7 表 0125 - 値型」に列記される。
【共通編】現在は、「HL7 表 0440 - データ型」が使われていると思われる。
検査値は、2.5 節「データ型」で定義されたデータ型のフォーマットに応じて表記されなければならない。例えば、PN は成分デリミタにより分離した 6 つの成分から成る。
NM は有効な型であるが、通常数字として報告される検査では、結果の一部として非数値文字が報告されることが多いので（結果が測定器で計りきれないことを示すために＞300 を使う場合など）、文字列（ST）データ型を持つことがある。例えば”＞300”では、”＞”は記号であり桁”300”
は数値と考えられる。しかしながら、ST タイプのこの使用は推奨されない。なぜなら SN（構造化した数値）データ型は今そのような報告を受入れ、さらに SN データ型によって受信システムが大きさを解釈できるからである。
HL7 データ型はすべて有効であり表 0125 に含まれている。ただし、CM、CQ、SI および ID は除く。CM 定義が意味を持つためには、CM に関する詳細がフィールド定義に含まれていなければならない。
「OBX-5 検査結果値」はデータ型 OBX-3 によって影響を及ぼされる一般的なフィールド定義である。したがって、CM はこの文脈中で定義されない。
CQ は無効である。なぜなら「OBX-5 検査結果値」のためのユニットが、「OBX-6 単位」を備えた
OBX セグメント中で明示的に常に指定されるからである。
SI は無効である。なぜなら、それは単に HL7 メッセージ・セグメントに適用されるに過ぎないからである。
ID は無効である。なぜなら、それは一定のフィールド定義を必要とするからである。
実際の検査値が OBX では送られていないが、他のどこかに存在する場合、RP 値（参照ポインタ）を使用しなければならない。例えば、検査が画像（ドキュメント関連画像あるいは医学関連画像）から成る場合、画像そのものは OBX で送ることができない。その場合送信システムは、参照ポインタを送信するよう選択することができる。受信システム側は、DICOM などの他の標準インタフェース
により、あるいは適切なデータ・ベース・サーバーにより実際の画像へアクセスする必要がある場合
は、いつでもこの参照ポインタを使用することができる。
HL7表 0125 - Value type 値型
Value
AD
CE
CF
CK
CN
CNE
CP
CWE
CX
DT
ED
FT
MO
NM
PN
RP
SN
ST
TM
TN
TS
TX
XAD
XCN
XON
XPN
XTN

Description
Address 住所
Coded Entry コード化された値
Coded Element With Formatted Values 値整形済コード化要素
Composite ID With Check Digit 点検数字付き複合 ID
Composite ID And Name 複合 ID と名前
Coded with No Exceptions 例外なしコード化値
Composite Price 複合価格
Coded with Exceptions 例外を含むコード化値
Extended Composite ID With Check Digit チェックデジット付き拡張複合 ID
Date 日付
Encapsulated Data カプセル化されたデータ
Formatted Text (Display) 整形済みテキストデータ
Money 金額
Numeric 数値
Person Name 人名
Reference Pointer 参照ポインタ
Structured Numeric 構造化数値
String Data. 文字列データ
Time 時間
Telephone Number 電話番号
Time Stamp (Date & Time) タイムスタンプ
Text Data (Display) テキストデータ
Extended Address 拡張住所
Extended Composite Name And Number For Persons 拡張複合 ID 番号および人の名前
Extended Composite Name And Number For Organizations 拡張複合組織名称および識別子番号
Extended Person Number 拡張人名
Extended Telecommunications Number 拡張遠距離通信番号【共通編】CNE、CWE を追加。

© JAHIS 202231

これらのデータ型の完全な定義は 2.5 節「データ型」の中で与えられる。構造化した数値（SN）データ型は、HL7 V2.3 で初めて扱われ、それが提供するものは、報告範囲（例えば 3－5 あるいは 10－20）、力価（例えば 1：10）および範囲外の指示（例えば>50）であって、構造化されコンピュータが解釈できる方法で提供される。
我々は、OBX セグメント中の FT データ型を許可する。しかし、その使用は推奨しない。フォーマッティングされたテキストは意味のある構造を通常意味する。例えば異なるライン上で報告された独立している 3 つの診断のリストを意味する。しかし、理想的には、独立している診断の 3 つの文中の構造は 3 つの個別の OBX セグメントとして報告される。
大量のテキストを送るとき以外、TX は使用してはならない。TX データ型では、反復デリミタは段落の区切りを識別するためだけに使用できる。短い、そして恐らくコード化できるテキスト文字列を送るため ST を使用すること。
CDA ドキュメントは、ドキュメント(MDM または ORU のような)を置き換えることができる任意のメッセージ中で、OBX セグメントで置き換えられる。OBX セグメント内では、MIME パッケージはカプセル化された(ED)データ型としてコード化される。

OBX-3 Observation Identifier 検査項目 ID (CE) 00571
成分:<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは検査を表す一意な識別子を含んでいる。形式は「コード化要素」（CE）の形式と同じ。
例：8625-6^P-R interval^LN

ほとんどのシステム構成では、識別子によって示されるのは、受信システムが受信した検査を処理するのに使用できる他の検査属性を列記したマスタ検査表だろう。そのようなマスタ検査表を送信するためのメッセージ・セグメントのセットについては HV7 V2.5 8 章に記述される。検査 ID とマスタ検査表との関係は、請求コード（請求レコード内の）と料金表の関係に類似している。
【生理】では、下記の通りとする。
DataUID を記述する場合：「DUID^DataUID^JHSS0001」
MIME パッケージを記述する場合：「MIME^MIMEPackage^JHSS0001」
MFER 形式ファイルを記述する場合：「MFER^MFER ファイル^JHSS0001」
付帯情報ファイルを記述する場合：「XML^付帯情報ファイル^JHSS0001」
検査結果情報は Base64 で内包して送信する：
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^ x-hl7-cda-level-one ^A^<CR><LF>
MIME-Version: 1.0<CR><LF>
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"<CR><LF>
Content-Transfer-Encoding: Base64<CR><LF>--HL7-CDA-boundary<CR><LF>
Content-Type: application/x-hl7-cda-level-one+xml<CR><LF>（ここに Base64 エンコードされた CDA 文書）<CR><LF>--HL7-CDA-boundary<CR><LF>
Content-Type: application/mwf<CR><LF>（ここに Base64 エンコードされた MFER ファイル）<CR><LF>--HL7-CDA-boundary<CR><LF>||||||R|||20210201100000<CR>※<CR><LF>コードはエスケープ処理したコード¥X0D0A¥を記述すること。
※「MFER^MFER ファイル^JHSS0001」および「XML^付帯情報ファイル^JHSS0001」は下位互換性のためだけに用意されている。
※検査項目コードとしては、JLAC10 コードを用いることを推奨する。

© JAHIS 2022

32

OBX-4 Observation Sub ID 検査サブ ID (ST)00572

定義：このフィールドは 1 つの OBR の下で編成された複数の OBX セグメントが同じ観察 ID を持つ場合、それぞれの OBX セグメントを識別するのに使う。例えば、胸部 X 線レポートには独立した 3
つの診断が含まれることがある。標準では、3 つの OBX セグメント（1 つの診断所見に 1 つの OBX
セグメント）が必要である。これらの OBX セグメントの 1 番目のサブ ID に 1、2 番目のサブ ID に 2、および 3 番目のサブ ID に 3 を入れることにより、HL7 は、編集あるいは交換に際し各 OBX セグメ
ントを一意に識別することができる。
検査サブ ID 使用の例は付録１参照

OBX-5 Observation Value 検査結果値 (*)

00573

定義：このフィールドは検査実施者により検査された値を含んでいる。検査結果値はこのフィールドのデータ型に応じてフォーマットされるが、そのデータ型は「OBX-2 値型」に含まれる。それは必須ではない。なぜなら一部のシステムは、特に市販後調査を報告する際に、正常／異常（OBX-8）だけを報告するからである。
検査結果項目の長さは「OBX-2 値型」により可変である。このフィールドは、適切なデー
タ型、例えば、CE、TX、および FT データ型を有するマルチパートを構成する単一の結果を繰り返すことができる。
表記
このフィールドには、同じセグメントの「OBX-3 検査項目」の値が含まれる。検査に依存するが、データ型は数値（例えば呼吸数）、具体的なコード（SNOMED で記述された病理所
見など）あるいは日時（1 単位の血液が病棟に送られる日時）のどれかである。検査結果値は、同じセグメントの「OBX-2 値型」で指定されたデータ型として表記される。数値なのかある
いは短いテキストなのかどうかに拘らず、結果は ASCII テキストで記録されるものとする。
論理上独立している検査の報告
放射線検査や「病歴・身体計測」などの書き取りレポートの主要箇所は、個別の OBX セグ
メントとして報告される。また、論理上独立している個々の検査は、個別の OBX セグメントで報告すべきである。つまり、1 個の OBX セグメントには、論理上独立している複数検査の“結果”を含んではならない。この要求事項により、「OBX-6 単位」および「OBX-8 異常フラグ」、および「OBX-9 確率」の内容が明白に解釈できるようになる。例えば電解質およびバイタルサイン・セットは、4 つの個別の OBX セグメントとして報告されるだろう。2 つの診断（うっ血性心不全と肺炎など）は、それが退院時サマリーの一部として報告されたのか
あるいは胸部 X 線レポートの一部として報告されたのかに拘らず、さらに 2 つの個別の OBX
セグメントとして報告されるだろう。同様に、単一の細菌培養内で分離された 2 つの細菌性生物は、2 つの個別の OBX セグメントとして報告されるだろう。
１つの OBX セグメントで、独立した 2 つの診断“記述文”を報告することはできないが、2 つの診断“記述文”がそれぞれ一部（修飾子）として一緒になって 1 つの診断記述文を構築するのであれば、定性値として複数回応答することができる（通常、反復デリミタにより分離された CE データ型として）。例えば、右上葉（1 つのコードとして記録される）と肺炎（別のコードとして記録される）の両方を 1 つの OBX セグメントで報告できるだろう。そのような複数の“値”は反復デリミタにより分離されるだろう。
共通の検査 ID とサブ ID を持つ複数の OBX セグメント
いくつかのシステムでは、単一の検査に複数データ型の“一部”が含まれることがある。
よくある例は、数値結果の後にコード化注記（CE）が続くことである。この場合、検査結果
情報は複数の OBX セグメントで送ることができる。例えば、あるセグメントは、数値結果を表すための数値データ型あるいは文字列データ型であるが、もう 1 つのセグメントはコード化注記を表す CE データ型である場合など。実施者が複数のコード化注記を報告しているとす
ると、その複数のコード化注記はすべて単一の論理検査情報を修正してしまうので、反復デリミタで分離された 1 つの OBX セグメントで送信されるだろう。同じ検査 ID とサブ ID を持
つ複数の OBX セグメントは、最も重要な OBX セグメント（正常なフラグ／単位、および／
あるいは、基準値および状態フラグを持つ OBX セグメント）を最初に指定して、常に連続し© JAHIS 202233

て送信すべきである。OBX6～12 の値は、同じ「OBX-3 検査項目」と「OBX-4 検査サブ ID」を持つ後続の OBX セグメントでは null とすべきである。置換または削除をする場合、同じ検査 ID とサブ ID を持つ複数の OBX セグメントは 1 単位として扱われる。どれか 1 つが置換または削除されると、すべてが置換される。
コード価値
OBX セグメントに CE データ型の値が含まれる場合、検査はコードおよび（または）テキストの組合せとして保管される。HL7 V2.5 7.8.3 節の「CSS-臨床試験スケジュールセグメント」に CE データ型として表した結果の例を示す（「OBR-1」の 1 番目と 2 番目の OBX セグメント、「OBR-2」の 1 番目と 2 番目の OBX セグメントに記述されている結果）。検査は、（推奨検査を表す）検査 ID、（診断を表す）診断コードか所見、または病理学レポートで使う部位、あるいは他の任意の種類のコード化結果などである。
コード化検査に保管された情報は必ずしもコード化する必要はない。例えば、胸部 X 線診
断が CE データ型であったとしても、純粋テキストとして転送することができるだろう。この場合は、例えば以下のように記述して、“結果コード”の第 2 成分として検査を記録しなければならない。
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE. |...<cr>

しかし、個別の診断、指導などは、純粋テキストとして記録するとしても、個別の結果セグメントに記録すべきである。すなわち、うっ血性心不全と肺炎は、
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|...<cr>

ように送信するのでなく、以下のように送信すること。
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE| ...<cr>
OBX|2|CE|71020&IMP|2|^PNEUMONIA|...<cr>

これよりさらによいのは、コンピュータの理解しうるコード（成分 1）を含んでいる完全にコード化された結果である。これはテキスト記述（成分 2）の代わりにまたはそれに追加して必要である。CE 値の中に複数の値を含むようにしてもよい。これらはコードとテキストの混合物でありうる。しかしそれらが 1 つの診断、所見あるいは概念を構築するため必要な場合に限る。テキストが独立している値としてコードの後に来る場合、それはコードの修飾子あるいは追加として解釈される。例えば、
OBX|1|CE|710120&IMP^CXR|1|428.0^CONGESTIVE HEART FAILURE^I9C~^MASSIVE
HEART...<cr>

成分 2 のテキストは成分 1 のコードの正確な記述とするべきである。同様に、もし使用されれば、成分 5 のテキストは成分 4 のコードの正確な記述とするべきである。
OBX への CDA の挿入
CDA ドキュメントは OBX セグメントで交換される。「OBX-2 値型」の値は ED である。
OBX－5 検査結果値にカプセル化されたデータ型としてエンコードされた MIME パッケージを含む。その成分は以下に通りである。
• 「OBX-5.2 データ型値」を 'multipart'に設定• 「OBX-5.3 データサブタイプ値」を'x-hl7-cda-level-one'に設定• 「OBX-5.4 エンコード値」を'A'に設定(注記： MIME パッケージそれ自身は Base64 でエンコードされているわけではない。
MIME パッケージの実体が Base64 でエンコードされる。MIME パッケージ自身は ASCII
テキストで送信される。したがって正しい値の内容は'A'であり'Base64'ではない。)• 「OBX-5.5 データ値」は MIME パッケージと等しいものが配置される。MIME パッケー
ジ内のすべての実体は Base64 でエンコードされている必要がある。2 章にあるように, "データ要素は HL7 のデリミタで分離されなければならない (および 改行のような非印字
ASCII 文字か非 ASCII 文字)、そして 2.4 節でエスケープ文字を定義しているように受信ア
プリケーションはそのデータをディエスケープする必要がある。その結果、は MIME パ© JAHIS 2022

34

ッケージで必要とされる CR/LF シーケンス送信前にエスケープされる (すなわち'¥X0D0A¥'に変換される) 。最初の MIME コンテンツタイプは'application/x-hl7-cda-level-one+xml'に設定されており、CDA ドキュメント自体を含める必要がある。送信される CDA ドキュメントから参照されるマルチメディアオブジェクトはMIME パッケージの連続する実体に配置される。

OBX-6 Units 単位 (CE) 00574
成分:<identifier (ST)> ^ <text (ST)> ^ <name of coding system (ID)> ^ <alternate identifier (ST)>^ <alternate text (ST)> ^ <name of alternate coding system (ID)>

背景：検査の値が連続的な尺度で測定される場合、OBX セグメントの単位項目内で測定単位を報告しなければならない。HL7 V2.2 以降の仕様では、単位を報告する項目はすべてデータ型 CE である。
単位コードのためのデフォルトのコーディングシステムは、単一ケースの単位の ISO の略語（ISO2955-83）、および ISO の省略形と衝突しない拡張子から構成される。我々は ISO+としてこのコーディングシステムを指定する。
ISO 単位の省略形および拡張子の両方が、HL7 7.4.2.6.2 節「ISO および ANSI の慣習的な単位省略形」の中で定義される、ISO+省略形はデフォルトのコーディングシステムのためのコードである。したがって、ISO+単位が使用される場合、ISO+省略形だけを送る必要がある。また、単位項目の内容は、
HL7 V2.1 と下位互換性を持つ。
報告する単位の識別
我々は、ISO+省略単位を排他的に使用するように検査担当者に強く奨励するが、必要な場合米国の慣習的な単位（ANSIX3.50）およびローカルに定義されたコードを含む他のコードシステムの使用を許す。ローカルな単位は L または 99zzz と呼ばれる。ここで z は英数字である（図 7.8.2 および 7.8.3
を参照のこと）。ANSIX3.50-1986 は、これらの規格を丁寧に説明し、またフィートまたはガロンのよ
うな米国の慣習的な単位のための、単一ケース省略形の表を提供している。
我々は当初ANSIX3.50-1986の米国の慣習的な単位をデフォルト値ISO+コーディングシステムの中に含める意図があった。しかしながら、ISO の省略形と米国の慣習的な単位の省略形の間に重複がある。例えば、ft は米国の慣習的な単位でフィートの省略形であり、ISO の中の femtotesla の省略形である；
pt は米国の慣習的な単位で pint(パイント)の省略形であり、ISO の中の picotesla の省略形である（ANSI 文書は、
一部の ISO 単位の省略形に関する ISO の文書とさらに異なることに留意すること）。
潜在的な曖昧さを回避するために、我々はもう 1 つのコーディングシステムすなわち ANS+を定義した。
（図 7.8.6 参照のこと）それに含まれるのは、米国の慣習的な単位（例えばフィート、ポンド）、
ANSIX3.50-1986 に定義された ISO の省略形、図 7.8.6 に列挙された非メートル系の単位、およびこれ
らの単位の ISO の組合せである。一部の ANSI ISO 単位省略形は ISO の中のそれらの省略形と異なることに留意すること（図 7.8.6 の下の注記を参照のこと）。
ANS+仕様は、ISO および米国の慣習的な単位の両方、およびさまざまな非メートル系の単位を含んでいるので、省略形のうちのいくつかは曖昧である。特別の検査の文脈では混同はほとんどないけ
れども、この曖昧さがあるので ANS+単位コードはできるだけ避けた方がよい。
ANS+単位コード（省略形）が送信される場合、ANS+は、項目の第 3 の（第 6 の）成分に含まれていなければならない。もし距離の単位がメーター（ISO+）として送信されれば、ISO+が単位のデフォ
ルト値コーディングシステムなので、それは m として送信される。しかしながら、もし米国の慣習的な単位のフィートで送信されれば、単位は ft＾＾ANS+として送信される。要求されたとき、単位の全文は第 2 の成分として送ることができる。これは CE データ型の規則に従った形である。
ISO および ANSI の両方とも大文字と小文字が混合した省略形のセットを提供する。しかし、これらの省略形は意味の損失なしで単一のケースに変換できない。それゆえこの仕様書内では使用すべきでない。この仕様書の内容は、ケースの如何を問わず（大文字か小文字かに関係なく）解釈できるよ
う要求されているからである。
ISO および ANSI の慣習的な単位省略形
ISO は 7 つの基本次元からその単位を構築している。すなわち、メーター、キログラム、秒、アン
ペア、ケルビン、モルおよびカンデラである（図 7.8-1 を参照のこと）。他の単位は、基本単位に接頭辞を付けて誘導する。これによってスケールを変え、および／または 2 つ以上の基本単位または組み© JAHIS 202235

立て単位を代数的に組合せたものを作る。しかしながら、いくつかの組み立て単位はそれ自身の省略形を持っている（図 7.8-1 を参照のこと）。米国の慣習的な単位の省略形は図 7.8-1 に与えられる。
ISO の規則は、ANSIX3.50 の中でよく説明されており、倍数接頭辞を加えることにより、異なる目盛の単位を作成する方法を提供する。これらの接頭辞は単語または省略形として表現できる。この規格では、省略形だけを扱う。
単位

省略形

アンペア
カンデラ

原子質量単位
ベル
デシベル
度
グラム

単位

省略形

メーター
モル
秒
指定された名前および省略形を持つ組み立て単位
c
Hr
時間
パスカル
d
J
ジュール
ボルト
cel
Min
分（時間の）
ワット
f
N
ニュートン
ウェーバー
hz
Ohm
オーム
年
他の単位
u
gy
グレー
角度の分
b
h
ヘンリー
ラジアン
db
l
リットル
ジーメンス
deg
Lm
ルーメン
ステラジアンg
Lx
ルクス
テスラ
完全なセットに関しては、ISO2955-1983 を参照すること。
a
Cd

クーロン
日
セルシウス度
ファラド
ヘルツ

単位
省略形
基本単位コード／省略形
k
ケルビン
kg
キログラム

図7.8-1

m
mol
s
pal
v
w
wb
ann
mnt
rad
sie
sr
t

ISOの単一ケース単位の省略形

倍数接頭辞の ISO の省略形は図 7.8-1 に与えられる。10-24（1 兆分の 1 のさらに 1 兆分の 1）から 1024
（1 兆×1 兆）の範囲の接頭辞がある。キロ（×1000）の単一ケース省略形は k である。1000 秒から成る単位の省略形は ks であり、1000 グラムは kg であり、1000 メートルは km であり、以下同様である。いくつかの接頭辞は基本単位の省略形を共有する。例えばファラドとフェムト（10-18）は両方とも省略形は f である。混乱を回避するために、ISO は接頭辞だけの単独使用を禁止する。また 1 つの複合単位に 2 つの接頭辞を使用することを推奨しない。
したがって f は常にファラドを意味し、
ff は、
1 ファラドの 100 万分の 1 のさらに 1 兆分の 1 を意味する。複合した接頭辞は許されない。
単位は指数関数的に何乗または何乗分の 1 で表現できる。正の指数はその数を単位の省略形の直後に付ける。つまり平方メーターは m2 によって表示される。負の指数は基礎単位の直後に負数を付ける。例えば、1 平方メートル当たりは m-2 で表される。分数の指数は分数を括弧の中に入れて表す：メーターの平方根は m（1／2）として表現される。単位の掛け算は単位の間の終止符（ .）によって示される。例えば、メーター掛ける秒は ms で表す。スペースが許されないことに留意すること。割り算は 2 つの単位の間の斜線（／）によって示される。例えば毎秒メーターは m／s として表示される。ISO 単位省略形の代数的な組合せであって、基本 ISO 単位の割り算、掛け算または累乗によって作ったものも有効な ISO 省略形単位である。累乗は掛け算または割り算に優先する。例えば、1 ヘル
ツ当たりのマイクロボルトの 2 乗（スペクトルのパワーの単位）は uv2／hz と表され、マイクロボル
トの 2 乗割る 1 ヘルツとして評価される。一方、1 ヘルツの平方根当たりのマイクロボルト（スペク
トルの振幅の単位）は uv／hz（1／2）と表され、マイクロボルト割る 1 ヘルツの平方根として評価される。もし 2 つ以上の割り算演算子が表現中に含まれるならば、結合は括弧内に入れて曖昧さを避ける。しかし最良のアプローチは、a／（b／c）を変換して a.c／b あるいは、a.c.b-1 として表現を単純化することである。
ISO コードは、単位を構築するための文法である。これらの単位の構造の規則は図 7.8-1 と図 7.8-3に基づいている。図 7.8-2 は、英語圏諸国単位だけにつかわれるべきで、それは図 7.8-3 と一緒に使うべきではない。ISO＋表はこの文法から構成された最も一般的な単位（及び重要な非 SO 単位）が含まれている。文法から派生した他の ISO 単位も有効である。
単位

省略形

単位

長さ
インチ
フィート
マイル（法定）© JAHIS 2022

省略形

単位

体積
in
ft
mi

立方フィート
立方インチ
立方ヤード

36

省略形
時間

cft
cin
cyd

年
月
週

yr
mo
wk

単位
海里
ロッド
ヤード

省略形
nmi
rod
yd

単位
省略形
単位
省略形
tbs
d
大さじ
日
tsp
hr
小さじ
時間
pt
min
パイント
分
qt
sec
クォート
秒
gal
ガロン
foz
オンス（流体）
面積
質量
sqf
dr
平方フィート
ドラム
sin
平方インチ
グレーン
gr（常衡）sydoz
平方ヤード
オンス（重量）lb
ポンド
他の ANSI 単位、誘導単位、およびその他**英国の熱単位 btu**華氏の温度 degf**ミリラド mrad
立方フィート/分 cft/min**フィート／分 ft／min**ラド RAD
注記：時間の慣習的な米国の単位の省略形は、年を除いて ISO と同じである。年の場合は ISO=ANN、AMSI=yrである。X3.50 の中のメートル単位は、次のものを除いて ISO と同じである：パスカル（「pa」は ANSI、「pal」は ISO）；ANSI は「min」を時間と角度の両方に使用し、一方 ISO は「mnt」を角度に使用している；
そして秒は ISO では「s」と略され、ANSI では「sec」と略される。
注記：ANS＋の仕様には米国、ISO 両方の慣習的な単位、およびその他の非メートル方の単位が含まれているため、一部の省略形はあいまいである。混乱はほとんどないはずだが、特定の検査に照らして、可能であれば ANS+コードを無効にする良い理由になる。
この一覧表は全部を網羅したものではない。他のメートル系および米国の標準単位については、
ANSIX3.50-1986、テーブル 1 を参照すること。
**ANSI で明示的に列挙されていない非メートル系単位

図7.8-2
接頭辞
ヨッタ*
ゼッタ*
エクサ
ペタ
テラ
ギガ
メガ
キロ
ヘクト
デカ

一部の米国の慣習的な単位のANSI+単位コード

コード
接頭辞
1024
ya
10-24
ヨクト
21
10
za
10-21
ゼプト
18
10
ex
10-18
アト
1015
pe
10-15
フェムト
1012
t
10-12
ピコ
9
10
g
10-9
ナノ
6
10
ma
10-6
マイクロ
103
k
10-3
ミリ
102
h
10-2
センチ
1
10
da
10-1
デシ
*これらの省略形は、単一ケース省略形の ISO 仕様の中では定義されていない。

図7.8-3

コード
y
z
a
f
p
n
u
m
c
d

倍数接頭辞のための単一ケースISO省略形

HL7 7.18.4 節に、一般的な ISO 組み立て単位の省略形を列挙する。それに含まれるものは、一般的な単位、例えばミリ当量、国際単位、mm（Hg）についての標準単位の省略形、および分割記号、分母によって表わされるが分子のないもの、例えば／c を含む。上記に引用した ISO 規格の一部でないものである。我々は、薬ルートおよび生理学的な対策に合わせて、またそれ以外の場合はバージョン
2.2 のギャップを埋めるために単位テーブルを拡張した。
我々は、単位の定義において IUPAC1995 のシルバーブック 2 に一般に従った。
しかしながら、
IUPAC
は、単位を報告し表示するための基準を指定し、それらを識別するために 8 ビット・データセットを使用する。この規格は、患者情報の送信に関係がある。したがって、我々は大文字、小文字に無関係
な英字、および少数の特殊文字（例えば、
「.」
、
「／」
、
「
（」
、
「）
」
、
「*」
、および「＿」）に限定して、送信中に起こりうる混乱を回避した。したがって、我々は ISO 2955-1983（情報処理－制限のある文字
セットを持ったシステム中の、SI および他の単位の表現）、および ANSIX3.50-1986（制限のある文字
セットを持ったシステム中の、米国の慣習的な単位、SI および他の単位の表現）の、大文字、小文字に無関係の単位省略形を、それらが定義されている場合、使用する。これは、場合によっては IUPAC
省略形が ISO+と異なる省略形を持つことを意味する。例えば IUPAC 省略形が標準の英字だけを使用していたとしても同様である。例えば、パスカルは IUPAC の中のでは Pa と略される。しかし ISO+（ISO 2955 に従う）の中では PAL である。なぜなら Pa は大文字、小文字に無関係な表示として（Paと）見るとピコアンペアを意味するからである。しかしながら、送信用の要件は、エンドユーザに紙© JAHIS 202237

またはビデオディスプレイで報告するプレゼンテーションのため IUPAC 基準を使用することを妨げない。
すべての単位省略形は大文字、小文字に無関係である。ミリリットルは、ML、ml あるいは mL と書くことができる。このテーブルでは、我々はすべての省略形に対して小文字を使用した。ただし Lは大文字にした。数字の 1（1）と混同しないようにした。これは表示方法の変更であって規則の変更ではない。システムとしては通常どおり大文字または小文字で引き続き送信すべきである。
HL7 V2.5 7.18.4 節「一般的な ISO 誘導単位および ISO 拡張子」を参照のこと。
ローカルの単位コード
ローカル・コードは、第 3 の成分の中で 99zzz のコード・ソースを示すことによって単位に使用できる。ここで 99zzz は英数字の文字列である。ローカル・コードの場合には、コードのテキスト名あるいは単位の記述も（第 2 の成分中で）送信されるべきである。その結果を受信システムが、別のサービスによって送られた同じ測定の結果と比較できるようにするためである（2.5 節「データ型」を参照のこと）。
「L」はコードがローカルに定義されることを示すために第 3 の成分に保存されるべきである。さらに特定化されたローカル・コード指示も、CE データ型定義中で指定されたように、使用できる。

OBX-7 References Range 標準値 (ST)00575

成分：フォーマットが数値の場合：a） 下限 – 上限（下限と上限の両方が定義された場合。例えば、カリウム3.5―4.5の場合）b） >下限（下限のみが定義された場合。例えば、>10）c） <上限（上限のみが定義された場合。例えば、<15）
アルファベットの値：正常値はこの場所で報告される可能性がある。

定義：有毒物質の量を計測する場合、範囲の上限により毒性限界を表す。
薬剤の量を計測する場合、下限により治療の期待できる最小量を表し、上限によりそれ以上の薬剤投与により通常副作用が発生しうることを表す。

OBX-8 Abnormal Flags 異常フラグ (IS)00576

定義：このフィールドは結果の正常状態を示すテーブルルックアップを含んでいる。適用できる場合は、この値を送ることを強く推奨する。検査が抗菌物質感受性の場合、解釈コードは次のとおりである： S＝敏感；R＝耐性；I＝中間；MS＝少し敏感；VS＝過敏。
（詳細については、ASTM 1238-調査-を参照のこと）。採りうる値については、「使用者定義表 0078 - 異常フラグ」を参照のこと。
検査室で、胸部 X 線あるいは微生物培養などのテキスト・レポートの正常状態を識別できる場合、正常な場合は N、異常な場合は A として報告すべきである。複数のコード（例えば異常と悪化）を報告する場合は、反復デリミタ（例えば A～W）により分離されるだろう。
使用者定義表 0078 - Abnormal flags 異常フラグ
Value

Description
L
基準値下限以下
H
基準値上限以上
LL
パニック下限以下
HH
パニック上限以上<
測定限界下限未満>
測定限界上限超N
正常（非数値結果に適用）
A
異常（非数値結果に適用）
AA
非常に異常（数値単位のパニック値に対応するが、これは非数値単位に適用される
null
範囲未定義、もしくは正常が適用されないU
大幅な上昇変化D
大幅な下降変化B
改善－－方向が適用されない場合使用W
悪化－－方向が適用されない場合使用
微生物感受性の場合のみ
S
敏感
R
耐性
I
中間

© JAHIS 2022

38

ValueDescription
少し敏感
過敏

MS
VS

結果は、結果の正確な数値を指定せずに正常状態を報告することによってメモ書きによって報告されることがある。そのようなメモは、臨床医のノートはありふれたことで、その場合医師は「グルコース結果は正常であった」と書くだけである。そのようなメモ報告は薬品の症例報告にも見られる。そのような場合、結果は、「OBX-5 検査結果値」の中でなにかの値を指定せずに、「OBX-8 異常フラグ」中に正常コードを報告することによって、OBX の中で報告できる。

OBX-9 Probability 確率 (NM)00577

定義：このフィールドは、定性値を持つ結果の場合、結果が真である確率（結果が特定のコードとなる確率）を含んでいる。主として離散的コード化結果に適用される。0～1（0 と 1を含む）の ASCII 文字列で表した 10 進数である。

OBX-10 Nature Of Abnormal Test 異常検査の特質 (ID)00578

定義：このフィールドは、異常な検査の性質を含んでいる。有効な値については「HL7 表 0080
- 異常検査の特質」を参照すること。適用できるコードはできるだけ多く含むことができる。
コードは反復区切記号で分離される。例えば、年齢、性別および人種に基づいた正常値は、
Ａ～Ｓ～Ｒとしてコードになる。
この表のコードの使用上の制約は、PID セグメントで定義されているもの、
具体的には PID-35種コード、PID-36-品種コード、および PID-37-血統情報と一致している必要がある。
HL7表 0080 - Nature of Abnormal Testing 異常検査の特質
値
A
N
R
S
SP
B
ST

内容
年齢別分布
なし － 一般正常範囲
人種別分布
性別分布
種
品種
血統

OBX-11 Observ Result Status 検査結果状態 (ID)00579

定義： このフィールドは検査結果状態を含んでいる。採りうるコードについては、「HL7 表
0085-検査結果状態コード解釈」を参照のこと。このフィールドは、1 つの検査項目についての、現在の結果完了状態を反映する。
HL7表 0085 - Observation Result Status Codes Interpretation 検査結果状態コード解釈
Value
C
D
F
I
N
O
P
R
S
X
U

W

Description
Record coming over is a correction and thus replaces a final result 到着レコードは修正であり結果を書き換え
Deletes the OBX record OBX レコードを削除する
Final results; Can only be changed with a corrected result. 最終結果： 修正結果でのみ変更可能
Specimen in lab; results pending 臨床検査室の検体；結果保留
Not asked; used to affirmatively document that the observation identified in the OBX was not sought when the universal service ID in
OBR-4 implies that it would be sought. 未確認、OBX-４で探せない OBX 検査 ID を確定するために使用するOrder detail description only (no result) 検査依頼項目の詳細を示す
Preliminary results 事前結果
Results entered -- not verified 結果を入力 －－ 検証されない
Partial results 部分結果
Results cannot be obtained for this observation この検査では、結果は得られない
Results status change to Final. Without retransmitting results already sent as ‘preliminary. 結果状態を最終へ変更。結果状態が「最終」に変わる。「予備」としてすでに送られた結果は再送信しない。例えば、放射線科により状態が事前から最終へ変更される。
Post original as wrong, e.g., transmitted for wrong patient オリジナルを間違っているものとしてポストする。例えば、間違っている患者のために送信された。

© JAHIS 2022

39

OBX-12 Effective Date of Reference Range 標準値有効日付 (TS) 00580
成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：このフィールドには、「OBX-7 標準値」が有効になった日付（およびオプションで時刻）が含まれる。
使用規則：このフィールドは、「OBX-7 標準値」が設定されている場合にのみ設定できる。
このフィールドが存在するとき、それは異なる参照範囲を有する同一の結果間の比較を容易にする。 基準範囲の値は、検査室での実務の変化により変わる場合がある。 そのような差異は、臨床検査医学における最新の実践、または最新の機器の使用を反映する可能性がある。

OBX-13 User Defined Access Checks ユーザ定義アクセス点検 (ST) 00581
定義：このフィールドはこれにより実施者は、受信システムで検査を分類するのに使用する
結果依存コードを記録できるようになる。
ほとんどの分類は固定の検査 ID 属性であり、関連検査マスタファイルで定義することができるので、このフィールドはめったに必要とされない（HL7 第 8 章の説明を参照のこと）。

OBX-14 Date Time Of the Observation 検査日時 (TS)00582

成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：このフィールドは次の 2 つの状態で必要になる。まず、1 つのレポートーヘッダ（OBR）の下で報告された複数の検査が互いに異なる日付を持つ場合である。これが起こりえるのは、同じセットのある測定と別の測定が異なる時間を持つ可能性がある、照会、負荷試験・シー
ケンス、あるいはクリアランス検査の場合である。
次に、OBX セグメントを依頼者から実施者へ送る場合にも検査日時は必要である。この場
合には、転送中の検査の日付は要求検査の日付とはなんの関係もないだろう。
どのような場合でも、検査日時は生理学的日時あるいは生理学的日時に最も近い日時である。検体に対して行われる検査の場合は、該当日時は検体採取日時である。患者に対して直接行われる測定（例えば X 線画像、病歴、身体測定）の場合には、検査日時は測定が行われた日時である。
【生理】生理検査結果通知メッセージ（OBR-25="F"）の場合、OBX-14（検査日時）を値必須とする。

OBX-15 Producer's ID 実施者 ID(CE) 00583

成分: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは、検査実施責任者の一意な識別子を含んでいる。

OBX-16 Responsible Observer 検査責任者 (XCN) 00584<ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR)(ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning
Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit
Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name
Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range(DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^<Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assign-ing Agency or
Department (CWE)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Sur-name Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
副成分 for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System
(ID)>
成分:

© JAHIS 202240

副成分 for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義：要求された場合、このフィールドは検査に直接責任を負う個人（つまり検査を実行、もしくは検証した人）の識別子を含んでいる。

OBX-17 Observation Method 検査方法 (CE)00936

成分：<identifier <Identifier (ST)> ^ <textText (ST)> ^ <nameName of coding system (IS)> ^<alternate identifierCoding System (ID)> ^ <Alternate Identifier (ST)> ^ <alternate
textAlternate Text (ST)> ^ <nameName of alternate coding system (ISAlternate Coding
System (ID)>

定義：このオプションのフィールドは、次の場合に検査が得られた方法あるいは処置を送信するために使用できる。送信システムが異なる方法によって得られた 1 つの測定中で識別を希望し、その区別が検査 ID で暗示されない場合である。化学検査室は、検査名の一部として与えられた血清成分（例えば血清カリウム）を測定するために使用される、異なる 2 つの方法を通常識別しない。これらの区別の完全な議論に関しては、LOINC ユーザマニュアル 4 を参照すること。もし検査実施サービスが、特定検査を得るため使用された方法を報告し、方法が検査名に埋め込まれて「いない」ならば、それらはこのフィールドを使用できる。
（米国）疾病予防管理センター（CDC）方法コード（CDCM）は、方法／機器を報告するためのコードシステム 1 つの候補である。EUCLIDES 方法コードは別のものである。使用者定
義表は代替手段である。

OBX-18Equipment Instance Identifier 機器インスタンス識別子 (EI) 01479
成分: <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type(ID)>

定義：このフィールドは、検査結果の作成を担当する機器インスタンス（たとえば、アナライザ、アナライザモジュール、アナライザのグループなど）を識別する。 これは、組織が名前空間 ID または空白の場合は「実施者 ID」（OBX-15）で指定される施設の設備のマスターリストによる識別子である。 このマスターリストから機器タイプ、シリアル番号などを取得することは可能であるが、すべての OBX でこの情報を転送することは計画されていない。 このフィールドを繰り返すことにより、機器の階層表現（最下位レベルが最初）、例えば機器のモジュール、モジュールからなる機器、複数の機器のクラスタなどが可能になる。

OBX-19Date/time of the Analysis 分析日付 (TS)01480

成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：このフィールドは、機器インスタンス識別子（上記参照のこと）で指定された機器による分析結果の生成に関連するタイムスタンプを転送するために使用される。

© JAHIS 2022

41

7.9. ORC

Order Common Segment 共通オーダセグメント

共通オーダセグメント(ORC) は、（要求される全てのタイプのサービスである）全てのオーダに共通するフィールドの転送に使用される。ORC セグメントは、オーダメッセージ（ORM)に必須である。ORC は、
オーダ詳細セグメントがある場合はオーダ応答（ORR）メッセージにおいて必須であるが、それ以外では必要ない。
（例えば、薬剤、食事のような）特定のタイプのオーダセグメントに詳細が必要なら、任意のオーダ詳細
セグメント（例えば、RXO,ODS のような）の前に ORC がなければならない。場合によっては ORC は、
ORC|OK|<placer order number>|<filler order number>|<cr>の文字列のように簡単になりうる。
そのオーダに詳細が必要でないなら、オーダ詳細セグメントは省略してもよい。例えば、あるオーダを保留にするには、ORC を以下のフィールドを埋めて転送する： HD 型の値を持つ「ORC-1 オーダ制御」 と「ORC-2 依頼者オーダ番号」、そして 「ORC-3 実施者オーダ番号」。
ORC のフィールドとオーダ詳細セグメントのそれらには多少の重複がある。この点については、後続の節で記述する。
HL7属性表－ORC－Order Common Segment 共通オーダセグメント
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

LEN

DT
ID
EI
EI
EI
ID
ID
TQ
EIP
TS
XCN
XCN
XCN
PL
XTN
TS
CE
CE
CE
XCN
CE

OPT
R
C
C
O
O
O
B
O
O
O
O
O
O
O
O
O
O
O
O
O

JAHIS
R
R
O
O*
O
O
X*
C*
R*
O
O
R*
O
O
O
O
R
O
O
O

RP/#

2
22
22
22
2
1
200
200
26
250
250
250
80
250
26
250
250
250
250
250

21
22
23
24
25
26

250
250
250
250
250
60

XON
XAD
XTN
XAD
CWE
CWE

O
O
O
O
O
C

O
O
O
O
O
C

Y
Y
Y
Y

27

26

TS

O

O

28
29
30

250
250
250

CWE
CWE
CNE

O
O
O

O
O*
O

TBL#
0119

0038
0121
Y

Y
Y
Y
Y/2

Y
0339

0177
0482
0483

ELEMENT NAME
Order Control オーダ制御
Placer Order Number 依頼者オーダ番号
Filler Order Number 実施者オーダ番号
Placer Group Number 依頼者グループ番号
Order Status オーダ状態
Response Flag 応答フラグ
Quantity/Timing 数量/タイミング
Parent 親
Date/Time of Transaction トランザクション日時
Entered By 入力者
Verified By 検証者
Ordering Provider オーダ発行者
Enterer's Location 入力場所
Call Back Phone Numberコールバック用電話番号
Order Effective Date/Time オーダ有効日時
Order Control Code Reason オーダ制御コード理由
Entering Organization 入力組織
Entering Device 入力装置
Action By 発動者
Advanced Beneficiary Notice Code
予告受益者通知コード
Ordering Facility Name オーダ施設名
Ordering Facility Address オーダ施設住所
Ordering Facility Phone Number オーダ施設電話番号
Ordering Provider Address オーダ依頼者住所
Order Status Modifier オーダ状態修飾子
Advanced Beneficiary Notice Override Reason 予告
受益者通知上書き理由
Filler's Expected Availability Date/Time 実施者サービ
ス可能日時
Confidentiality Code 守秘コード
Order Type オーダタイプ
Enterer Authorization Mode 入力者承認モード

ORC 使用上の注意
a) 依頼者オーダグループ
本標準規格では、複数のオーダを 1 つのグループに集めるメカニズムをサポートする。大抵の場合、
これは 1 人の患者に対して「オーダリング・セッション」を表すために使用される。
オーダグループは、「ORC-4 依頼者グループ番号-placer group number」に関連するオーダ（ORCs）のリストである。グループは、依頼者が最初のオーダに依頼者グループ番号を付けたときに確立する。
オーダグループは、同じ依頼者グループ番号を有するすべての ORCs およびすべての詳細セグメント© JAHIS 202242

からなる。オーダは、グループから取消を使用して除去したり、取替えや親子メカニズムを使用して追加したりできる。新規オーダは、その他の方法でのグループへの追加はできない。
b) 重複フィールド
ORC は、すべてのオーダ（すなわち要求されたサービス）に共通なフィールドを一様に定義するよう意図されている。ただし、ORC の一部のフィールドは、一部のオーダ詳細セグメント（例えば OBR､
RXO）と重複する。例えば、「ORC-2 依頼者オーダ番号」は 、「OBR-2 依頼者オーダ番号」フィー
ルド と同じ意味および目的を持つ。これによって過去のバージョンおよび ASTM との上位互換性が保たれる。
これらのフィールドを使用する規則は、ORC に現れない値はオーダ詳細セグメントに現れねばならない、というものである。しかし、両方の箇所に値を入れて混乱を避けることが望ましい。
c) 親／子 － 取消、保留、中断
親オーダの取消、保留、または中断の要求の伝達は、その要求は親オーダおよびすべての関連の子
オーダに対して再帰的に適用されるよう意図されている。
例えば、
1) EKG アプリケーションが 3 回の EKG を毎朝連続して行うオーダを受けるとする。
2) EKG アプリケーションは 3 つの子オーダを、各々の要求された EKG に対して 1 つずつ作成する。
3) 元の親オーダを取消しする要求が受け取られたときに1 日目のEKG はすでに実施されていた（親は取り消せなかった）。
4) 残りの未実施の子は要求の結果として取消される。

ORC フィールド定義
ORC-1 Order Control オーダ制御 (ID)00215

定義：オーダセグメントの機能を決定する。有効なエントリについては「HL7 表 0119–オーダ制御コ
ードとその意味」を参照のこと。メッセージによって、制御コードの振る舞いはオーダまたは個別サービスに適用される。例えば、OMP メッセージの CA コードはそのオーダを取消しする。RDS メッ
セージの同じコードはその調剤を取消しする。かなり詳しい説明の注記が、この節の最後に設けられている。
このフィールドは、オーダのための「トリガーイベント」識別子と考えてよい。コードは、次の 3
つのカテゴリーに大別される。
a) イベント要求
イベントを生成するために、「NW」（新規オーダ）や「CA」（オーダ取消要求）のようなコードが使用される。
b) イベント肯定応答承認
イベント要求に返答するために、「OK」（オーダの受理）や「CR」（要求通り取消された）のようなコードが使用される。
c) イベント通知
イベントが発生したことを他のアプリケーションに知らせるために、「OC」（オーダ取消）や「OD」（オーダ中断）のようなコードが使用される。いかなるアプリケーション応答も必
要ない。
イベント要求コードは、イベントを開始することを意図する。イベント応答コードは、イベントを要求したアプリケーションに応答することを意図する。イベント通知コードは、他のアプリケーショ
ンに例えば次のようなことを知らせることを意図する。すなわち実施者がオーダに対し何かアクションをとり、それを他のアプリケーション（例えば依頼者）が知る必要がある場合などである。
実施者、依頼者、および他のアプリケーションは、イベント要求、イベント応答、およびイベント
通知型トリガーイベントについて互換性をもって使用できる。しかし、オーダ制御コードは実施者の© JAHIS 202243

みから生成することができる（例えば CR）ものや、依頼者のみから生成することができる（例えばCA）ものもある。
HL7表 0119 - Order Control Code オーダ制御コードとその意味
Value
AF

CA

Description
Order/service refill request
approval
補充オーダ要求許可
Cancel order/service
request
オーダ取消依頼

CH

Child order/service
子オーダ

CN

Combined result
統合検査結果Comments
Placer Applications.
AF は補充品や補充量を許可する依頼者からの返答である
Placer Applications.
オーダ取消依頼は、以前にオーダしたサービスを実施者に行わせないようにする依頼者からの要求である。取消要求の確認は、実施者によって行われる、例えば、CR の ORC-1 オーダ制御値）を持
つメッセージである。
一般的な応答は、これらに限定されないが、以下のようなものが挙げられる、CR－要求通りオーダ
取消完了、UC－オーダ取消不能。
Placer or Filler Applications.
PA とあわせて使用－親オーダコントロールコード。詳細は PA オーダコントロールコードを参照のこと。
Filler Applications.
統合検査結果コードは、複数のオーダに関連する結果を送るためのメカニズムを提供する。この状
態は、通常、放射線科医が複数のオーダで表される複数の検査に対して単一のレポートを口述する
ときの放射線科レポートに見られる。例えば、リューマチ性関節炎患者のひざと手のフィルムは、放射線科医の側で 1 つの口述レポートを生成することがある。
そのような結果が報告されるとき、CN コードが最後の ORC 以外のすべての RE を置き替える。結果は最後の ORC とその OBR に続く。3 つの ORC に続く単一のレポートの例は下記のとおりである。

MSH|...<cr>
PID|...<cr>
ORC|CN|...<cr>
OBR|1|A4461XA^HIS|81641^RAD|73666^Bilateral
Feet|...<cr>
ORC|CN|...<cr>
OBR|2|A4461XB^HIS|81642^RAD|73642^Bilateral
Hand PA|...<cr>
ORC|RE|...<cr>
OBR|3|A4461XC^HIS|81643^RAD|73916^Bilateral
Knees|...<cr>
OBX|1|CE|73916&IMP|1|Radiologist's
Impression|...<cr>
OBX|2|CE|73642&IMP|1|Radiologist's
Impression|...<cr>
OBX|3|FT|73642&GDT|1|Description|...<cr>
CRCanceled as requested
要求通りオーダ取消完了

DC

Discontinue order/service
request
オーダ中断要求DE

Data errors
データエラー
Order/service refill request
denied補充オーダ要求拒否

DF© JAHIS 2022

Filler Applications.
取消（依頼者アプリケーションからの CA）の要求が成功したことを示す実施者アプリケーション
からの応答
Placer Applications.
実施者アプリケーションに前もって要求したサービスを中断するための依頼者アプリケーションからの要求。中断と取消の違いとして、中断はオーダ／サービスおよび今後起こるすべての動作に影響、取消は現在のアクションだけに影響する。
一般的な応答は、これらに限定されないが、以下のようなものが挙げられる、CR－要求通りオーダ
取消完了、UC－オーダ取消不能
Placer or Filler Applications.
Placer Applications.
補充要求(RF)に対する実施者アプリケーションの応答、DF は依頼者がオーダの補充を許可しない
ことを示す。オーダ制御コード理由を使用して要求拒否の理由を示してもよい。下記の値が推奨されている。
AA Patient unknown to the provider
提供者が患者を知らない
AB Patient never under provider care
患者は提供者から医療を受けたことがない
AC Patient no longer under provider care
患者はもはや提供者の医療を受けていない
AD Patient has requested refill too soon
患者は補充を要求したがそれが早過ぎる
AE Medication never prescribed for the patient
薬品が患者に処方されたことがない。
AF Patient should contact provider first
患者は最初に提供者にコンタクトするべきである
AG Refill not appropriate
補充が適切でない。

44

ValueDescription

DR

Discontinued as requested
要求通りオーダ中断

FU

Order/service refilled,
unsolicited
補充オーダ済、未承諾
Hold order request
オーダ保留要求

HD

HR
LI

NA

On hold as requested
要求通りオーダ保留Link order/service to patientcare problem or goal
オーダ／サービスの患者
看護プロブレムまたはゴールへの紐付
Number assigned
番号が割り当て済み

Comments
注記：これらの値は、「NCPDP SCRIPT 応答セグメント・コードリスト修飾子」に由来することに留意すること。
資料の複製は©National Council for Prescription Drug Programs, Inc. （米国規格協会認定の機関）
1988, 1992, 2002 NCPDP の承諾を得てください。
Filler Applications.
実施者は、中断（依頼者アプリケーションからの DC）の要求に応じて、オーダ／サービスを中断する。
Filler Applications.
FU は依頼者に実施者が患者要求のオーダに対して補充を発行したことを通知する。
Placer Applications.
一般的な応答は、これらに限定されないが、以下のようなものが挙げられる、CR－要求通りオーダ
取消完了、UC－オーダ取消不能。
Filler Applications.
Placer or Filler Applications.
本規約では取り扱わない。
詳細は HL7 V2.5 第 12 章：患者看護を参照のこと。

Placer Applications.
オーダ番号(ORC-2 依頼者オーダ番号 または ORC-3-実施者オーダ番号)の要求に関与する 3 つの状況がある。
1) 実施者アプリケーションが、集中アプリケーション（例えば HIS）へ
ORC-3－実施者オーダ番号を要求する必要があるとき。
2) 実施者アプリケーションが、他のアプリケーション（例えばオーダエントリ）へ ORC-2－依頼者オーダ番号を要求する必要があるとき。
3) アプリケーション（実施者アプリケーションでない）が新規オーダのために
ORC-3－実施者オーダ番号を割り当てたいとき。
１）実施者アプリケーションが集中管理された実施者オーダ番号を必要とする場合
SN -このオーダ番号送信コードは、実施者が HIS のような中央集中アプリケーション（以下の表では”other”と呼ぶ）に、ORC－3－実施者オーダ番号を要求するメカニズムを提供する。 これはSN の ORC-1-オーダ制御値を含んでいる ORM メッセージを送ることによって行う。 この ORC
は null の ORC-3-実施者オーダ番号 と ORC-2 依頼者オーダ番号を持つ。これらは実施者がオーダを開始するとき、実施者アプリケーションによって作成されたものである。
ORM（SN タイプ）メッセージは、以下の 2 つの方法によって確認応答される。
ⅰ）ORC-1 オーダ制御 の値が OK である ORR メッセージによる。非要求の ORM メッセージ
は、ORC-1-オーダ制御 の値が NA である ORC を含んでいて、後で送信される。
ⅱ）
以下で述べる ORC-1 オーダ制御 の値が NA である ORR メッセージによる。
NA -この番号割り当て済コードは、その他のアプリケーションが実施者アプリケーションに、新
しく割り当てられた実施者オーダ番号を知らせることを許す。ORC-1－オーダ制御値、ORC-2－依頼者オーダ番号（SN 値を持つ ORC から）は NA の値を持ち、新しく割り当てられた実施者オーダ
番号を含む
Code

From

ORC-2-Placer
ORC-3-Filler
Order Number
Order NumberSNfiller application
placer orderNullnumber^filler
application ID
NAother application
placer orderfiller ordernumber^filler
number^filler
application ID
application ID
Note: Both the placer order number and the filler order number have the filler's
application ID
注記：依頼者オーダ番号と実施者オーダ番号の両方が、実施者のアプリケーション
ID を持つ。
2）実施者アプリケーションが依頼者オーダ番号を必要とする場合
SN -このオーダ番号送信コードは、実施者アプリケーションが ORC-2－依頼者オーダ番号をその他のアプリケーションに要求するためのメカニズムを提供する。（以下の表では“other”と呼ぶ）
これは SN の ORC-1－オーダ制御値を含んでいる ORM メッセージを送ることによって行う。この
ORC は、null の ORC-2－依頼者オーダ番号と、実施者がオーダを生成するときに実施者アプリケーションによって作成された ORC-3－実施者オーダ番号を持つ。
ORM（SN 型）メッセージは、2 つの方法によって確認応答される。
ⅰ）ORC-1－オーダ制御の値が OK である ORR メッセージによる。非要求 ORM メッセージ
は、ORC-1－オーダ制御の値が NA である ORC を含んでいて、後で送信が可能である。

© JAHIS 2022

45

ValueDescription

Commentsⅱ）以下で述べる、ORC-l－オーダ制御の値が NA である ORR メッセージによる。
NA -この番号割り当て済コードは、「その他」アプリケーションが実施者アプリケーションに、
新しく割り当てられた ORC-2－依頼者オーダ番号を知らせることを許す。ORC は、NA の ORC-1－オーダ制御値、新しく割り当てられた ORC-2－依頼者オーダ番号、および ORC-3－実施者オーダ番号（SN 値を持つ ORC から）を含む。
Code

From

ORC-2-Placer
Order Numbernull

ORC-3-Filler
Order NumberSNfiller application
filler ordernumber^filler
application ID
NAother application
placer or filler
filler ordernumber^placer
number^filler
application ID
application ID
Note: The new ORC-2-placer order number has the placer's application ID
注記：新しい ORC-2 依頼者のオーダ番号は、依頼者のアプリケーション ID を持っている。
3）アプリケーションが実施者オーダ番号を割り当てたい場合
NW - オーダを作成するアプリケーション（実施者アプリケーションではない）が、新規オーダの実施者オーダ番号を割り当てたいとき。
またはRO -（RP に続く RO）。この場合は、”other”のアプリケーションが ORC－3－実施者オーダ番
号 を完成させる。この際、実施者オーダ 番号の第 2 成分として実施者アプリケーション ID を使用
する。
Code

From

NW
or RO

NW

New order/service
新規オーダ

ORC-2-Placer
Order Number
placer ordernumber^placer
application ID

Otherapplication to filler
application
Placer Applications.
NA のコメントを参照のこと －番号は割り当て

ORC-3-Filler
Order Number
filler ordernumber^filler
application ID【生理】ORC(PA)を記述する前に ORC(NW)を記述する。
ORC(NW)
新規オーダ
ORC(PA)
親オーダ
OBR
親オーダの記述
ORC(CH)
１番目の子オーダ
OBR
１番目の子オーダの記述
ORC(CH)
２番目の子オーダ
OBR
２番目の子オーダの記述
OC
OD
OE
OF

OH
OK

OP

OR

Order/service canceled
オーダ取消完了
Order/service discontinued
オーダ中断
Order/service released
オーダ開放
Order/service refilled as
requested
要求通り補充オーダ済
Order/service held
オーダ保留
Order/service accepted &OKオーダ受付&OK
Notification of order foroutside dispense
外部調剤へのオーダ通知

Released as requested
要求通りオーダ開放© JAHIS 2022

Filler Applications.
Filler Applications.
Filler Applications.
Filler Applications.
OF は補完に対する依頼者システムからの要求に直接応答する。
Filler Applications.
Filler Applications.
NA のコメントを参照のこと －番号割り当て。
Placer Applications.
これらオーダ制御コードは、システム間でオーダを通信するために使用される。それらシステムでは、オーダは情報提供の目的とみなされる。たとえば、通信を行うシステムの組織外のベンダによって実行されるオーダである。そのシステムでは、臨床的な継続性のためにそのオーダに関連した情報を維持する必要があるが、オーダされたサービスを実行するアクションを何ら意図したものではない。
OP は、NW の情報提供バージョンを、PY は RO の情報提供バージョンといえる。NW と RO の表
注記は、各々OP と PY にも適用できる。
Filler Applications.

46

ValuePA

Description
Parent order/service
親オーダ

Comments
Filler Applications.
親(PA)と子(CH)のオーダ制御コードにより、親（オリジナルオーダ）を変えることなく｢親オーダ｣から｢子オーダ｣を生み出すことが可能になる。
PA の ORC-1－オーダ制御値を持つ 1 個以上の ORC
セグメントは CH の ORC-1－オーダ制御値を持つ 1 個以上の ORC セグメントが後に続く。ORC-6－応答フラグの値によって OBR セグメントが存在しなければならないかどうか決定される。
例えば、細菌培養で 2 つの細菌を生成しそれに対応する感受性試験の結果がでたと仮定して、そのときセグメントのシーケンスは、次の通りである
Segment
Order Control
Comments
ORC
PA
1st parent ORC
ORC

CH

OBR

ORC

1st child ORC
1st child order

CH

OBR

2nd child ORC
2nd child order

親子パターンでの依頼者オーダ番号の割り当ては、依頼者または実施者が子オーダを生成するかど
うか、また後者の場合、依頼者が SN/NA トランザクションをサポートするかどうかに依存する。
依頼者が子オーダを生成するならば､それはその通常の手続きに従ってそれらの依頼者オーダ番号を割り当てる。実施者が子オーダを生成するならば、そこで 2 つの可能性がある。各々の子はその親の依頼者オーダ番号を受け継ぐか、あるいは依頼者が依頼者オーダ番号を割り当てるよう要求するために実施者が SN/NA トランザクションを使用する。どちらのケースでも、実施者アプリケー
ションは、その通常の手続きに従って子の実施者オーダ番号を生成する。
子オーダがメッセージで送られるときは、
常に ORC セグメントの ORC-8-親に親の実施者オーダ番号（実施者から開始する場合）および親の依頼者オーダ番号（実施者から開始する場合、あるいは依頼者から開始する場合）がセットされる。
親子メカニズムは、（例えば、毎朝、連続して 3 回の EKG のオーダを発行するといったように）、
親オーダを拡張することのために使用される。
【生理】
生理検査の場合、親オーダはそのオーダ全体に関連する情報を記述する。例えば、患者のプロフ
ァイル情報などは親オーダ記述の中に記述する。子オーダはここの撮影に関する情報を記述する。例えば,撮影部位や使用材料などである。部位などが異なる撮影に関しては､それぞれに子オーダ記述を使用する。さらに、後述する ORC(NW)は新規オーダを表す意味で､ORC(PA)の前に記述する。
ORC(NW) 新規オーダ
ORC(PA)
親オーダ
OBR
親オーダの記述
ORC(CH) １番目の子オーダ
OBR
１番目の子オーダの記述
ORC(CH) ２番目の子オーダ
OBR
２番目の子オーダの記述
PR

Previous Results with neworder/service
以前の結果

PY

Notification of replacement
order for outside dispense
外部調剤へのオーダ修正通知Observations/Performed
Service to follow
検査付帯情報RE

Placer Applications.
PR は、この ORC が（オーダにうめこまれている）以前の検査を含む ORU 構造の一部であることを示す。少なくとも、主に２つのユースケースが、以前の検査の完全な結果がそのオーダとともに転送されることを要求する。
•臨床検査室は、結果（HIV 等）の確認や試験（遺伝的試験等）を行える設備がないため、他の検査
機関に検査を委託する。
•臨床検査室は、検査報告に含める診断コメントの自動生成のための知識ベースに検査結果を送る。
Placer Applications.
OP（外部調剤へのオーダ通知）のコメントを参照のこと。

Placer or Filler Applications.
検査付帯情報コードはオーダと共に患者固有情報を送るのに使用される。
オーダ詳細セグメント（例
えば、OBR）の後には 1 個またはそれ以上の検査セグメント(OBX)を続けることができる。ORU
メッセージとして伝えることができるいかなる検査情報も、このメカニズムで伝えることができる。
結果がオーダとともに送られるときは、結果はその結果が対応するオーダの直後に続けられるべきである。
次の例は、3 個の処方オーダのためのセグメントのシーケンスを、RE コードの使用例で示す。
Segment
MSH
PID© JAHIS 2022

Order Control

47

Comments

ValueDescription

RF

Refill order/service request
補充オーダ要求

RL

Release previous hold
前回保留オーダ開放
Replacement order
置換後オーダ

RO

ORC
RXO

NW

ORC
RXO
[ORC
OBR]
OBX
OBX
OBX
OBX

NW

ORC
RXO

NW

RE

Comments
First new orderFirst order segment
2nd new order
2nd order segment
Patient-specific observation, optional in V 2.2
Observation OBR, optional in V 2.2
An observation segment
Another observation segment
Another observation segment
Another observation segment
3rd order
3rd order segment

HL7 のこのバージョンにおいて、結果は 1 個あるいはそれ以上の OBX セグメントとしてオーダと共に送ることができる。ただし ORC と OBR セグメントを必ずしも含む必要はない。
検査情報は ORC を使用せずに ORU メッセージを用いて伝えることができる。
ORU メッセージのOBRセグメントに含まれない情報を伝える必要が生じるときがある。
この場合、ORC が ORU メッセージに含まれていることを推奨する。
オーダ制御の値に RE をもつことは、ORM メッセージにおいてオーダの後に検査結果（OBX）が続くことを示す場合にのみ要求される。RE コードは ORU メッセージでは必要ではない。なぜなら
OBR セグメントの後に検査結果（OBX）を続けることができるからである。
Placer or Filler Applications.
RF は実施者または依頼者の両方による要求を受け入れる。実施者は依頼者からの補充許可を要求していることもある。依頼者システムは、補充が実施者システムによって行われるよう要求していることもある。
標準的な応答は、これらに限定されないが、以下のようなものが挙げられる。実施者要求に関しては AF－補充オーダ要求許可、DF–補充オーダ要求拒否; 依頼者要求には、RE－検査付帯情報、UF－補充不能
Placer Applications.
Placer or Filler Applications.
オーダ置換依頼は以前に依頼された 1 個以上のオーダの代替えである。
取替えられたオーダはあたかも取り消されたオーダのように扱われる。依頼されたサービスが取替えられるかどうか、いつ修正されるかは、現場独自で決定する。
オリジナルのオーダが元の状態を保つことをサイトが要求するならば、親／子オーダ制御コードを使用する。以下の場合は、オーダ置換コードを使用しない。
取替えられる各オーダには RP（実施者に対するオーダ置換依頼）の ORC-1－オーダ制御値またはRU（実施者によって作成された非要求置換）を使用すること。RU は実施者によって使用され、依頼者および、または他のシステムに通知するためのものである。現場での取り決め(local agreement)
によって、ORC セグメント（RP または RU と）の後には、そのオリジナルのオーダ詳細セグメン
トが続いてもよい。ORC セグメント（RP または RU を含む）の後には、RO（置換後オーダを示す）の ORC-1－オーダ制御値を持つ、ORC セグメントが続かなければならない。現場での取り決めによっては、RO 値を持つ ORC は、オーダ詳細セグメントが後に続いてもよい。
例えば、部門のアプリケーションが 2 個の OBR オーダを 3 つの異なったオーダで修正されていたと仮定して、セグメントの順序は、次の通りになる。
Order
Control
RU

Comments

ORC
OBR

RU

2nd replaced ORC
2nd replaced order's detail segment

ORC
OBR

RO

1st replacement ORC
1st replacement order's detail segment

ORC
OBR

RO

2nd replacement ORC
2nd replacement order's detail segment

ORC
OBR

RO

3rd replacement ORC
3rd replacement order's detail segment

Seg
ORC
OBR

1st replaced ORC
1st replaced order’s detail segment

ORC-6－応答フラグの値によって OBR セグメントが存在しなければならないかどうかが決定される。

© JAHIS 2022

48

ValueDescription

RP

Order/service replacerequest
オーダ置換要求

RQ

Replaced as requested
要求通りオーダ置換© JAHIS 2022

Comments
この取替え方法は、すべての取替え可能なケースを扱う：
1 個から 1 個へ、複数から 1 個へ、1 個から複数へ、および複数から複数へ。もし依頼者が実施者に 2 つの RP 付き要求を送り実施者から依頼者への応答があるとすると、2 つの RU（非要求で置換された）は 2 つの RQ（要求通り置換された）となる。
Seg
ORC
OBR

Order Control
RQ

Comments
1st replaced ORC
1st replaced order's detail segment

ORC
OBR

RQ

2nd replaced ORC
2nd replaced order's detail segment

ORC
OBR

RO

1st replacement ORC
1st replacement order's detail segment

ORC
OBR

RO

2nd replacement ORC
2nd replacement order's detail segment

ORC
OBR

RO

3rd replacement ORC
3rd replacement order's detail segment

置換オーダコードは、実施者アプリケーションによって別のアプリケーションに送れて、置換された正確なオーダサービスを示す。それは上記の RP と RU のオーダ制御コードによって使用される。
RO の制御値を持つ ORC セグメントのオーダ番号の規則は置換型（RP または RU）によって決定される。
RU 型（すなわち実施者からの非要求置換）のときには、実施者オーダ番号は、実施者アプリケー
ションによって通常生成される。依頼者オーダ番号は、最初に送られた、オーダ制御の値が RU である ORC の依頼者オーダ番号と全く同一である。
RP 型（すなわち別のアプリケーションから実施者へのオーダ置換要求）のときには、依頼者オーダ番号は、新規オーダのための手続きを使用して、依頼者アプリケーションによって生成される。
実施者オーダ番号は、新規オーダと同一の手順を使用して、実施者アプリケーションによって生成される。
置換シーケンスが ORU メッセージ（すなわち検査結果報告の時に）において使用されるときの推奨セグメントを以下に述べる。
1) RO のオーダ制御値つきの ORC
2) 任意の OBR セグメント（任意のオーダ詳細セグメントによって置換可能）
3) オプションで検査結果セグメント（OBX）が後に続く。
4) NTE セグメントは、通常の ORU メッセージにおけるのと同様に OBR（あるいは任意のオーダ詳細セグメント）または OBX セグメントの後に続けられる。
Placer Applications.
オーダ置換依頼は、以前に依頼された、1 個あるいはそれ以上のオーダの代替えである。今後の議論のためには、RO–置換後オーダのコメントを参照のこと
オーダ置換要求コードは依頼者アプリケーションの要求に応じて、実施者が 1 個あるいはそれ以上の新規オーダを 1 個あるいはそれ以上の新規オーダと取替えることを許可する。
RO の制御値を持つ ORC セグメントのオーダ番号の規則は置換型（RP または RU）によって決定される。
RU 型（すなわち実施者からの非要求置換）のときには、実施者オーダ番号は、実施者アプリケー
ションによって通常生成される。依頼者オーダ番号は、最初に送られた、オーダ制御の値が RU である ORC の依頼者オーダ番号と全く同一である。
RP 型（すなわち別のアプリケーションから実施者へのオーダ置換要求）のときには、依頼者オーダ番号は、新規オーダのための手続きを使用して、依頼者アプリケーションによって生成される。
実施者オーダ番号は、新規オーダと同一の手順を使用して、実施者アプリケーションによって生成される。
置換シーケンスが ORU メッセージ（すなわち検査結果報告の時に）において使用されるときの推奨セグメントを以下に述べる。
1) RO のオーダ制御値つきの ORC
2) 任意の OBR セグメント（任意のオーダ詳細セグメントによって置換可能）
3) オプションで検査結果セグメント（OBX）が後に続く。
4) NTE セグメントは、通常の ORU メッセージにおけるのと同様に OBR（あるいは任意のオーダ詳細セグメント）または OBX セグメントの後に続けられる。
Filler Applications.
オーダ置換依頼は、以前に依頼された、1 個あるいはそれ以上のオーダの代替えである。今後の議論のためには、RO–置換後オーダのコメントを参照のこと
オーダ置換要求コードは依頼者アプリケーションの要求に応じて、実施者が 1 個あるいはそれ以上の新規オーダを 1 個あるいはそれ以上の新規オーダと取替えることを許可する。
置換オーダコードは、実施者アプリケーションによって別のアプリケーションに送れて、置換され49

ValueDescription

RR

Request received
要求受付
Replaced unsolicited
非要求オーダ置換

RU

SC
SN
SR

SS

UA

Status changed
状態変更
Send order/service number
送信オーダ番号Response to sendorder/service status request
送信オーダ状態要求応答
Send order/service status
request
送信オーダ状態要求
Unable to accept
order/service
オーダ受付不可UC

Unable to cancel
オーダ取消不能UD

Unable to discontinue
オーダ中断不能Unable to refill
補充不能

UF

UH
UM

Unable to put on holdオーダ保留不能Unable to replace© JAHIS 2022

Comments
た正確なオーダサービスを示す。それは上記の RP と RU のオーダ制御コードによって使用される。
RO の制御値を持つ ORC セグメントのオーダ番号の規則は置換型（RP または RU）によって決定される。
RU 型（すなわち実施者からの非要求置換）のときには、実施者オーダ番号は、実施者アプリケー
ションによって通常生成される。依頼者オーダ番号は、最初に送られた、オーダ制御の値が RU である ORC の依頼者オーダ番号と全く同一である。
RP 型（すなわち別のアプリケーションから実施者へのオーダ置換要求）のときには、依頼者オーダ番号は、新規オーダのための手続きを使用して、依頼者アプリケーションによって生成される。
実施者オーダ番号は、新規オーダと同一の手順を使用して、実施者アプリケーションによって生成される。
置換シーケンスが ORU メッセージ（すなわち検査結果報告の時に）において使用されるときの推奨セグメントを以下に述べる。
1) RO のオーダ制御値つきの ORC
2) 任意の OBR セグメント（任意のオーダ詳細セグメントによって置換可能）
3) オプションで検査結果セグメント（OBX）が後に続く。
4) NTE セグメントは、通常の ORU メッセージにおけるのと同様に OBR（あるいは任意のオーダ詳細セグメント）または OBX セグメントの後に続けられる。
Placer or Filler Applications.
下位互換性のためだけに保持されている。
Filler Applications.
オーダ置換依頼は、以前に依頼された、1 個あるいはそれ以上のオーダの代替えである。今後の議論のためには、RO–置換後オーダのコメントを参照のこと
オーダ非要求置換通知コードは依頼者アプリケーションから要求されることなしに実施者アプリケーションが別なアプリケーションに知らせることを許可する。
RO の制御値を持つ ORC セグメントのオーダ番号の規則は置換型（RP または RU）によって決定される。
RU 型（すなわち実施者からの非要求置換）のときには、実施者オーダ番号は、実施者アプリケー
ションによって通常生成される。依頼者オーダ番号は、最初に送られた、オーダ制御の値が RU である ORC の依頼者オーダ番号と全く同一である。
RP 型（すなわち別のアプリケーションから実施者へのオーダ置換要求）のときには、依頼者オーダ番号は、新規オーダのための手続きを使用して、依頼者アプリケーションによって生成される。
実施者オーダ番号は、新規オーダと同一の手順を使用して、実施者アプリケーションによって生成される。
置換シーケンスが ORU メッセージ（すなわち検査結果報告の時に）において使用されるときの推奨セグメントを以下に述べる。
1) RO のオーダ制御値つきの ORC
2) 任意の OBR セグメント（任意のオーダ詳細セグメントによって置換可能）
3) オプションで検査結果セグメント（OBX）が後に続く。
4) NTE セグメントは、通常の ORU メッセージにおけるのと同様に OBR（あるいは任意のオーダ詳細セグメント）または OBX セグメントの後に続けられる。
Placer or Filler Applications.
Placer Applications.
NA に関してはコメントを参照のこと －番号割り当て
Filler Applications.

Placer Applications.

Filler Applications.
オーダ受付不可コードが使用されるのは、新しいオーダを実施者が受付できないときである。受付できない理由としては、患者がアレルギーを起こす薬剤の処方を要求したこと、またはそのオーダを実施するための機器が利用できないこと（例えば、オーダが記入できないなど）が考えられる。
これは MSA セグメント内で定義される通信レベルでの受付とは異なることに留意すること。
Filler Applications.
オーダ取消不能コードは依頼されたサービスが実施者によって取り消せないポイントにあるとき、あるいは現場の取り決めで実施者による取消を禁止するとき使用される。このコードの使用はORC-6－応答フラグに従う。
Filler Applications.
Filler Applications.
UF は実施者システムが許可された補充要求に対してアプリケーションレベル拒否をしたことを示す｡
Filler Applications.
Filler Applications.

50

Value
UN

UR
UX
XO

XR
XX

MC

Description
オーダ修正不能Unlink order/service frompatient care problem or goal
患者看護プロブレムまたはゴールからのリンクオーダ
解除
Unable to release
オーダ開放不能Unable to change
オーダ変更不能Change order/service
requestオーダ変更要求

Changed as requested
要求通りオーダ変更
Order/service changed
unsolicited.
オーダ変更（未承諾）
Miscellaneous Charge –not associated with anorder
雑費－オーダとは関連なし

Comments
Placer or Filler Applications.
詳細は、HL7 V2.5 第 12 章： 患者看護を参照のこと。

Filler Applications.
Filler Applications.
Placer Applications.
【生理】検査内容変更の際に、ORC-1 に XO を入れ、1 メッセージで送信する。XO の使用は、
XO-PA-CH の構造のみで、上書きの情報として送付する。受け取り側はオーダ情報を完全に入れ替える。ORC(PA)を記述する前に ORC(XO)を記述する。
ORC(XO)
修正オーダ
ORC(PA)
親オーダ
OBR
親オーダの記述
ORC(CH)
１番目の子オーダ
OBR
１番目の子オーダの記述
ORC(CH)
２番目の子オーダ
OBR
２番目の子オーダの記述
Filler Applications.
Filler Applications.

applies to DFT^P03^DFT_P03 and DFT^P11^DFT_P11
DFT^P03^DFT_P03 と DFT^P11^DFT_P11 を適用。

注記：HL7 V2.5の当該表は、オーダ制御コードに対応するメッセージの記述が不十分であるため、HL7 V.2.7の当該表を採用した。

ORC-2 Placer Order Number 依頼者オーダ番号 ( EI)
成分：

00216

<Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID
Type (ID)>

定義：依頼者アプリケーションのオーダ番号。
第 1 成分は個々のオーダ（例えば OBR）を識別する文字列である｡15 文字の上限が推奨されるが、必須ではない。依頼者オーダ番号に対してより多くの文字数を要求するアプリケーションに適用するためにこのフィールドの文字数が増える場合、その実装は HL7 に準拠している。それは依頼者（オーダアプリケーション）によって割り当てられる。それは、特定のオーダリングアプリケーションからのすべてのオーダの中で、１つのオーダを一意に識別する。第 2 から第 4 までの成分は、HD デー
タ型と同じ形式で依頼者アプリケーションのアプリケーション ID を含んでいる。第 2 成分、ネーム
スペース ID は、アプリケーションに一意に関連している使用者定義のコード化された値である。6文字の上限が推奨されるが、必須ではない｡1 つの施設または相互に通信する施設のグループは、依頼者や実施者になる可能性のあるアプリケーションの一意なリストを構築し、一意なアプリケーション
ID を割り当てるべきである。各成分は、成分デリミタによって分離される。
真の依頼者がややあいまいな（それゆえ一意でない）状況が 3 つある。
a) RU 置換に続く RO の「ORC-1 オーダ制御値」の場合
b) CH（子オーダ）の「ORC-1 オーダ制御値」の場合
c) SN（番号送信）の「ORC-1 オーダ制御値」の場合
アプリケーション ID リストは、HL7 V2.5 第 8 章で文書化されている施設のマスタ辞書の 1 つになる。第三者アプリケーション（オーダの依頼者および実施者以外）が ORM と ORR のメッセージの送受信ができるので、このフィールドの依頼者アプリケーション ID は、（MSH セグメントで識別される）ネットワーク上の送信および受信アプリケーションと同じでなくともよい。
「ORC-2 依頼者オーダ番号」は､「OBR-2 依頼者オーダ番号」と同じである。依頼者オーダ番号
が ORC の中に存在していないならば､それは関連した OBR 内に存在しなければならない。逆も同様© JAHIS 202251

である｡もし両方のフィールド､すなわち「ORC-2 依頼者オーダ番号」および「OBR-2 依頼者オーダ
番号」が設定されるならば､それらは同じ値でなければならない。結果が ORU メッセージで送られる
場合､ORC は必須ではないが、依頼者オーダ番号が OBR セグメント内に存在せねばならない。
これらの規則は、上位互換性のため ORC と OBR の両方の中に存在している他のフィールドにも適用される。
（例えば、数量／タイミング、親番号、オーダ依頼者、および依頼コールバック用電話番号）。

ORC-3 Filler Order Number 実施者オーダ番号 ( EI)00217

定義：このフィールドは実施者アプリケーションに関連したオーダ番号である。それは実体識別子データ型 (HL7 V2.5 第 2.A.28 節) の実例である。
その第 1 成分は、
オーダ詳細セグメント（例えば OBR）
を識別する文字列である。15 文字の上限が推奨されるが、必須ではない。実施者オーダ番号に対してより多くの文字数を要求するアプリケーションに適用するためにこのフィールドの文字数が増える
場合、その実装は HL7 に準拠している。それはオーダ実施者（受信）アプリケーションによって割り当てられる。この文字列は、オーダ（オーダ詳細セグメントで指定された）を、特定の実施者アプ
リケーション（例えば臨床検査室）における他のオーダから一意的に識別しなければならない。この
一意性は時間が経過しても維持されなければならない。
第 2 から第 4 までの成分は実施者アプリケーション ID を含んでいるが、その形は HD データ型である (HL7 V2.5 2.A.36 節「HD 階層的指定子」を参照のこと）。第 2 成分は使用者定義のコード化された値であって、そのアプリケーションをネットワーク上の他のアプリケーションから一意的に定義する。6 文字の上限が推奨されるが、必須ではない。実施者オーダ番号の第 2 成分は、オーダの実際の実施者を常に識別する。
施設または相互通信する施設のグループは、オーダの依頼者や実施者となりうるアプリケーションのリストを作成し、一意のアプリケーション ID を割り当てるべきである。アプリケーション ID リス
トは､HL7 V2.5 第 8 章で文書化される施設のマスタ辞書リストのうちの 1 つになる。第三者アプリケーション（オーダの依頼者および実施者以外のもの）は、ORM および ORR メッセージを送信し受信することができるため、このフィールドの実施者アプリケーション ID は（MSH セグメントで定義される）ネットワーク上の任意の送信および受信アプリケーションと同じでなくともよい。
「ORC-3 実施者オーダ番号」は「OBR-3 実施者オーダ番号」と同じである。実施者オーダ番号がORC の中にない場合､それは関連する OBR の中になければならない。
（この規則は､ORC および OBRの他の同一のフィールドに対して同じであり､上位および ASTM 互換性を促進する。
）結果が ORU メ
ッセージ中で送信される場合､これは特に重要である。この場合､ORC は必須ではないため､識別する
実施者オーダ番号は OBR セグメントの中になければならない。
実施者オーダ番号 (OBR-3 または ORC-3) は、さらにオーダおよびその関連する観察を一意に識別する。例えば、施設がいくつかの付随的なアプリケーションからの検査（広義）を共通のデータベースへ集め、この共通のデータベースが検査（広義）のための別のアプリケーションから照会を受ける場合を想定する。この場合､共通のデータベース・アプリケーションによって送信された実施者オ
ーダ番号および依頼者オーダ番号は、それぞれ元の実施者および依頼者の番号になり、共通のデータ
ベース・アプリケーションによって割り当てられた新しい番号ではない。
同様に、オーダの第三者アプリケーション（実施者または依頼者ではない）がオーダ状態を修正する（例えばそれを取り消す）権限を持つならば、第三者アプリケーションは実施者に次のような ORM
メッセージを送るであろう、すなわち、「ORC-1 オーダ制御」の値が「CA」に等しく、それ自体割り当てるのではなく元の依頼者オーダ番号および実施者オーダ番号を含む ORC セグメントを含んでいる。

ORC-4 Placer Group Number 依頼者グループ番号 (EI)
成分：

00218

<Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID
Type (ID)>

定義：このフィールドによって、オーダ依頼者アプリケーションは何組かのオーダをグループ化した
後にそれらを識別できる。それは実体識別子データ型(HL7 V2,5 2.A.28 節)の実例である。
第 1 成分は、与えられた依頼者アプリケーションからのオーダグループをすべて一意に識別する文字列である。15 文字の上限が推奨されるが、必須ではない。それは依頼者アプリケーションによって割り当てられ、ORC の依頼者オーダ番号と同じシリーズからくるかもしれないが、そうである必要はない。

© JAHIS 202252

第 2 から第 4 までの成分は、依頼者アプリケーション ID を構成するが、これは「ORC-2 依頼者オーダ番号」の同様の成分と同一である。

ORC-5 Order Status オーダ状態 (ID)00219

定義： このフィールドはオーダの状態を定義する。とりうる値については「HL7 表 0038–オーダ状態」を参照すること。このフィールドの目的は、要求された場合または状態が変更になった場合にオーダの状態を報告することであり、行為を開始することではない。オーダ状態は、メッセージが送られる時点で送信アプリケーションに知られていた状態を反映させることを想定している。実施者だけがこのフィールドに値を付けることができる。
「HL7 表 0038–オーダ状態」は「HL7 表 0119–オーダ制御コードとその意味」と同じ値の多くを含んでいるが、目的は異なる。オーダ状態は、「ORC-1 オーダ制御値」が SR または SC のメッセージにおいて典型的に使用される。これは、要求により、あるいは任意の時点で任意の当事者にオーダの状態を報告するためである。
【生理】
ORU メッセージの検査ステータス通知で使用する値については、
OBR-25 項の「表7.7-1 OBR-25と ORC-5 の組合せによる検査ステータス」を参照のこと。
HL7表 0038 - Order status オーダ状態
Value
A

Description
Some, but not all, results available 一部（全部ではない）の結果が利用できる。
Order was canceled オーダが取り消されたOrder is completed オーダが完了した
Order was discontinued オーダが中断した
Error, order not found エラー、オーダが見つからない
Order is on hold オーダが保留In process, unspecified 進行中、不定
Order has been replaced オーダ変更された
In process, scheduled 進行中、予定された

CA
CM
DC
ER
HD
IP
RP
SC

ORC-6 Response Flag 応答フラグ (ID)00220

定義：このフィールドによって依頼者（送信）アプリケーションは、実施者から返されるべき情報の量を決定できる。要求されたレベルの応答は、即時には可能ではないかもしれない。しかし、それが可能なとき、実施者（受信）アプリケーションは、その情報を送らなければならない。フィールドがnull であるとき、フィールドのデフォルト値は D である。とりうる値については「HL7 表 0121–応答フラグ」を参照のこと。
HL7表 0121 - Response flag 応答フラグ
Value
E
R
D
F
N

Description
Report exceptions only 例外のみを報告
Same as E, also Replacement and Parent-Child E と同じ、および変更と親子Same as R, also other associated segments R と同じ、および 他の関連セグメント
Same as D, plus confirmations explicitly D と同じ、プラス明確な確認
Only the MSA segment is returned MSA セグメントのみが返却される

ORC-7 Quantity/Timing 数量/タイミング (TQ)

00221

定義：
（このフィールドは下位互換を保つ目的のためだけに残されている）

ORC-8 Parent 親 (EIP)00222

成分： <Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>
副成分 for Placer Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> &<Universal ID (ST)> & <Universal ID Type (ID)>
副成分 for Filler Assigned Identifier (EI): <Entity Identifier (ST)> & <Namespace ID (IS)> &<Universal ID (ST)> & <Universal ID Type (ID)>

定義：このフィールドは、親子の関係が存在するときに、子をその親に関係付ける。親子のメカニズ
ムは、「ORC-1 オーダ制御」の注記のところで述べられる。

© JAHIS 2022

53

第 1 成分は、「ORC-2 依頼者オーダ番号」と同じフォーマットである。第 2 成分は、
「ORC-3 実施者
オーダ番号」と同じフォーマットである。依頼者オーダ番号と実施者オーダ番号の成分は、このフィールドの 2 つの成分の副成分として送られる。
「ORC-8 親」は、「OBR-29 親」と同じである。ORC に親が記載されていない場合、関連づけられた OBR に記述されるべきである。
（この規定は、ORC と OBR の他の同一フィールドと同じであり、上位互換と ASTM 互換を促進する。
）これは、結果が ORU メッセージにおくられた場合に特に重要である。この場合、その ORC は要求されず、識別する実施者オーダ番号が OBR セグメントの中に記
述されなければならない。

ORC-9 Date/Time Of Transaction トランザクション日時 (TS)
成分：

00223

<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義： このフィールドは、「ORC-1 オーダ制御コード」に反映される現在のトランザクションを開始したイベントの日時を含む。このフィールドは、「MSH-7 メッセージ日時（物理的なメッセージの日時を反映する）」と等価ではない。

ORC-10 Entered By 入力者 (XCN)00224<ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR)(ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning
Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit
Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name
Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range(DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^<Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or
Department (CWE)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
副成分 for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>
副成分 for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>成分：

定義： このフィールドは要求をアプリケーションに実際に入力した人の識別情報を含む。これは、現在のトランザクションの「ORC-1 オーダ制御コード」に反映されることに注意する。それは、要求が不正確に入力され、関連部門が要求を明らかにする必要がある場合、監査証跡となる。現場の取り決めによって、ID 番号または名前成分は省略してもよい。

ORC-11 Verified By 検証者 (XCN)00225

成分：<ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR)(ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning
Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit
Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name© JAHIS 2022

54

Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range(DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^<Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or
Department (CWE)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
副成分 for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>
副成分 for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義： このフィールドは入力された要求の正確さを検証した人の識別情報を含む。これは、「ORC-1
オーダ制御コード」に反映されるものとして、現在のトランザクションを参照することに注意する。
それが使用されるのは、要求が技師によって入力され、（看護師など）より高い権限者によって検証される必要がある場合である。現場の取り決めによって、ID 番号や名前成分は省略してもよい。

ORC-12 Ordering Provider オーダ発行者 (XCN)

00226<ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR)(ST)> ^ <DEPRECATED-Degree (e.g., MD) (IS)> ^ <Source Table (IS)> ^ <Assigning
Authority (HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit
Scheme (ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name
Representation Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range(DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^<Professional Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or
Department (CWE)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
副成分 for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>
副成分 for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>成分：© JAHIS 202255

副成分 for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義： このフィールドは、（例えば、依頼している医師など）要求を作成することに責任がある人の識別情報を含む。
「ORC-12 オーダ依頼者」は、「OBR-16 オーダ依頼者」と同じである。オーダ依頼者が ORC に記述されない場合、関連づけられた OBR に記述されるべきである。
（この規定は、ORC や OBR の他の同一フィールドと同様であり、上方互換と ASTM 互換を促進する。
）これは特に、結果が ORU メッセージに転送された場合に重要である。この場合、ORC が要求されず、識別する実施者オーダ番号がOBR セグメントに記述されるべきである。
【生理】本フィールドは必須とする。

ORC-13 Enterer's Location 入力場所 (PL)00227

<Point of Care (IS)> ^ <Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)>^ <Person Location Type (IS)> ^ <Building (IS)> ^ <Floor (IS)> ^ <Location Description (ST)>^ <Comprehensive Location Identifier (EI)> ^ <Assigning Authority for Location (HD)>
副成分 for Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type(ID)>
副成分 for Comprehensive Location Identifier (EI): <Entity Identifier (ST)> & <Namespace ID(IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
副成分 for Assigning Authority for Location (HD): <Namespace ID (IS)> & <Universal ID (ST)> &<Universal ID Type (ID)>成分：

定義： このフィールドは要求を入力した人がオーダを入力した時にいた物理的な場所を指定する（例えばナースステーション、関連サービス部、クリニック、フロア）。これは「ORC-1 オーダ制御コード」に反映されるものとして、現在のトランザクションを参照することに注意する。入力した人の場
所に関係のある副成分だけが値を与えられるべきである（通常は看護ユニット、施設、建物、フロア）。
要求を入力した人は「ORC-10 入力者」によって定義される。
【生理】たとえば、ICU4 は、4 階の ICU の場所の呼称とするなど。
入力者の場所のデータ型は PL 型なので、入院の場合、<病棟コード>^<病室コード>^<ベッド番号>^^^N
外来の場合<科コード>^^^^^Cと設定することにし、person location type の指定を必須とした。
person location type には、C：診療科、D：部門、N：病棟を設定する。

ORC-14 Call Back Phone Number コールバック用電話番号 (XTN)
成分：

00228

<DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^<Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)>^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^<Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

定義： このフィールドは、要求やそのオーダに関する他の情報を確認するための電話番号を含む。
「ORC-14 コールバック用電話番号」は、「OBR-17 オーダコールバック用電話番号」と同じである。

ORC-15 Order Effective Date/Time オーダ有効日時 (TS)
成分：

00229

<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義： このフィールドは、要求への変更が有効になった、あるいは有効になる予定の日時を含む。
「ORC-9 トランザクション日時」が、「ORC-15 オーダ有効日時」以降であれば、ORC およびその下位のセグメントのデータ値はオーダ有効日時に有効になった。
「ORC-9 トランザクション日時」が、「ORC-15 オーダ有効日時」より前ならば、ORC およびその下位セグメントのデータ値はオーダ有効日時に有効になるよう計画される。
「ORC-15 オーダ有効日時」がブランクであれば、その値は、「ORC-9 トランザクション日時」と、トランザクション日時がブランクであれば「MSH-7 メッセージ日時」と等しいと仮定される。
「ORC-15 オーダ有効日時（同じ ORC セグメントのオーダ制御コードイベントのための）」が、
ORC-7-数量／タイミングの対応する日時と異なる場合は、「ORC-15 オーダ有効日時」が優先する。1
例として ORC イベントが実施者への継続しているオーダに対する中断要求であり、かつオーダ有効© JAHIS 202256

日時が「ORC-7 数量／タイミング」の終了日時の前であれば、オーダ有効日時が優先する｡ORC の中で識別されたオーダが子を持っているならば、開始しなかった子は取り消される必要がある。進行中の子がいるならば、それは中断される必要がある;子が中断できる点を超えて進行しているならば、その状態は影響されない。

ORC-16 Order Control Code Reason オーダ制御コード理由 (CE)
成分：

00230

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義： このフィールドは、オーダ制御コード(HL7 表 0119) によって記述されたオーダイベントに対する理由の説明を含んでいる。コード化したあるいはテキスト形式のどちらでもよい。オーダ特有のセグメント（例えば、RXO、ORO、OBR）の後の NTE は、その特有のセグメントのためのコメントとなる一方、オーダ制御コード理由の目的は、そのオーダイベントの理由のみを拡張することである。
「ORC-1 オーダ制御」が NW であるときは､「ORC-16 オーダ制御コード理由」には普通は値を設定しない。ただし、設定できないわけではない。取り消されたオーダのときには、例えば、このフィールドは、取消の理由を説明するためによく使用される｡よく知られているアレルギーのために医師からの処方オーダが取消されたならば、調剤システムからこのフィールドによってアレルギーの事実が報告される。それが薬理相互作用のためにこのオーダを取消したならば、このフィールドは、相互作用物質の少なくとも名称（および必要ならコードも）、相互作用を記述する文章、および相互作用の深刻度を含む。

ORC-17 Entering Organization 入力組織 (CE)
成分：

00231

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義： このフィールドは、入力した人が、オーダを入力／維持したときに属している組織、例えば医療グループまたは診療科を識別する。要求を入力した人は「ORC-10 入力者」によって定義される。

ORC-18 Entering Device 入力装置 (CE)
成分：

00232

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義： このフィールドは、オーダを入力するのに使用された物理的装置（端末や PC）を識別する。

ORC-19 Action By 発動者 (XCN)00233<ID Number (ST)> ^ <Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further
Given Names or Initials Thereof (ST)> ^ <Suffix (e.g. JR or III) (ST)> ^ <Prefix (e.g. DR) (ST)>^ <DEPRECATED-Degree (e.g. MD) (IS)> ^ <Source Table (IS)> ^ <Assigning Authority(HD)> ^ <Name Type Code (ID)> ^ <Identifier Check Digit (ST)> ^ <Check Digit Scheme(ID)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation
Code (ID)> ^ <Name Context (CE)> ^ <DEPRECATED-Name Validity Range (DR)> ^ <Name
Assembly Order (ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional
Suffix (ST)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or Department (CWE)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
副成分 for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>
副成分 for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
成分：© JAHIS 2022

57

Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義： このフィールドは、対応するオーダ制御コードによって表されるイベントを発動した人の識
別情報を含む。例えば、オーダ制御コードが CA（オーダ取消要求）であるならば、このフィールドは､オーダ取消を要求した人を表す。この人は典型的には医療提供者であるが、必ずしも「ORC-12 オーダ発行者」と同じとはかぎらない。

ORC-20 Advanced beneficiary notice code 予告受益者通知コード (CE)
成分：

01310

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは保険未加入の可能性のあるサービスの支払責任に対する患者または患者の代理人の承諾状態を示す。この要素は、外来患者に対する CMS 医療要求を満たすことを促す。この要素は、(a)サービスに関連づけられた診断コードが医療上必要な治療の対象かどうか、(b)この種のサービスに対して、そのサービスに対する支払責任があるかもしれないことを患者に通知されているか、(c)そして、患者がサービスに対する請求に同意しているか、を示している。そのフィールドの値は、「使用者定義表 0339–予告受益者通知コード」から引用される。
使用者定義表 0339 – Advanced beneficiary notice code 予告受益者通知コード
Value
1
2

Description
Service is subject to medical necessity procedures サービスは、医療上必要な治療の対象である
Patient has been informed of responsibility, and agrees to pay for service 患者に支払責任のあることが通知されており、サービスの支払の同意がある

3

Patient has been informed of responsibility, and asks that the payer be billed 患者に支払責任のあることが通知されており、支払人が請求されるよう依頼する4

Advanced Beneficiary Notice has not been signed 予告受益者通知がサインされていない

ORC-21 Ordering facility name オーダ施設名 (XON)

01311<Organization Name (ST)> ^ <Organization Name Type Code (IS)> ^ <DEPRECATED-ID
Number (NM)> ^ <Check Digit (NM)> ^ <Check Digit Scheme (ID)> ^ <Assigning Authority(HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Name Representation
Code (ID)> ^ <Organization Identifier (ST)>
副成分 for Assigning Authority (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal
ID Type (ID)>
副成分 for Assigning Facility (HD): <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>成分：

定義：このフィールドはオーダ依頼している施設名を含む。

ORC-22 Ordering facility address オーダ施設住所 (XAD)

01312<Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province(ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other
Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address
Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective
Date (TS)> ^ <Expiration Date (TS)>
副成分 for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> &<Dwelling Number (ST)>
副成分 for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>成分：

定義：このフィールドはオーダ依頼している施設の住所を含む。

© JAHIS 2022

58

ORC-23 Ordering facility phone number オーダ施設電話番号 (XTN)
成分：

01313

<DEPRECATED-Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^<Telecommunication Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)>^ <Area/City Code (NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^<Extension Prefix (ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

定義：このフィールドはオーダ依頼している施設の電話番号を含む。

ORC-24 Ordering provider address オーダ依頼者住所 (XAD)

01314<Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province(ST)> ^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other
Geographic Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address
Representation Code (ID)> ^ <DEPRECATED-Address Validity Range (DR)> ^ <Effective
Date (TS)> ^ <Expiration Date (TS)>
副成分 for Street Address (SAD): <Street or Mailing Address (ST)> & <Street Name (ST)> &<Dwelling Number (ST)>
副成分 for DEPRECATED-Address Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>要素：

定義：このフィールドはオーダを要求した医療提供者の住所を含む。

ORC-25 Order status modifier オーダ状態修飾子 (CWE)
成分：

01473

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドは「ORC-5 オーダ状態」フィールドの修飾または絞り込みのためにある。このフィールドは定義されたオーダ状態コードへの付加的な特定レベルまたは付加的な情報を提供するのに利用される。HL7 定義表により制御されるオーダ状態フィールドとは異なり、このフィールド
は CWE データ型であり、アプリケーションはオーダ状態修飾子コードの制限のないライブラリをサポートすることが許される。
使用規則：このフィールドは「ORC-5 オーダ状態」フィールドに値がある場合のみ値を持ってよい。
例：オーダ状態が IP のオーダを処理している LIS が、検査室内でのオーダ進捗状況や、そのオー
ダが外部検査機関に送られたことを示すのに、オーダ状態修飾子を用いて最新情報を送るかもしれな
い。医療関連でないオーダを利用する別の例では、電話を患者の病室に転送するよう依頼されたが、一時的に切れてしまったような場合である。
「ORC-5 オーダ状態」は IP を示し、「ORC-25 オーダ状
態修飾子」は切れた状態を示す。第３の例は、薬剤部での調剤に関するものである。処方箋が調剤されているかどうかを知るだけでは不十分な場合がある。
「ORC-25 オーダ状態修飾子」はラベルが印刷されたかどうか、処方箋が記載されたかどうか、処方箋が発行されたかどうか、などを示す。

ORC-2601641

Advanced Beneficiary Notice Override Reason
成分：

予告受益者通知上書き理由(CWE)<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドは、患者が予告受益者通知にサインしない理由を含む。理由はコード化してもよいしフリーテキストで入力してもよい。
「HL7 表 0552–予告受益者通知上書き理由」を参照のこと。
条件：このフィールドは「ORC-20 予告受益者通知コード」の値が、通知にサインされていない場合に要求される。例えば、ORC-20 が「使用者定義表 0339-予告受益者通知コード」の 3 或いは 4 の値を持つ場合、または、関連する外部コード表で同様の値が入力されている場合、追加の修飾または説明のための情報が正当なものとして認められる。
HL7表 0552 - Advanced beneficiary notice override reason
Value© JAHIS 2022

Description

予告受益通知上書き理由
Comments

59

ORC-27 Filler's Expected Availability Date/Time 実施者サービス可能日時 (TS)
成分：

01642

<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：このフィールドは、実施者がサービス可能な日時を指定する。例えば、処方箋が受け取り可能
な時、補充品が送付ないし受け取られる時、または検体検査結果が利用可能となる時。

ORC-28 Confidentiality Code 守秘コード (CWE)
成分：

00615

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドは、オーダを取り巻くセキュリティおよび／あるいはセンシティビティのレベ
ルに関する情報を含む。
（例えば非常に機微、機微ではない、機微など）。可能な値に関しては、「HL7
表 0177–守秘コード」 を参照のこと。特定の守秘レベルでのデータの具体的な処理に関しては、施設固有の取り決めに委ねる。
HL7表 0177 - Confidentiality Code 守秘コード
Value
AID
EMP
ETH

Description
AIDS patient 患者
Employee 従業員
Alcohol/drug treatment patient アルコール/
薬物中毒 治療患者

HIV
PSY
R
U
UWM
V
VIP

HIV(+) patient HIV(+)患者
Psychiatric patient 精神医学患者
Restricted 限定
Usual control 通常管理
Unwed mother 未婚の母
Very restricted 非常に限定
Very important person or celebrity 重要人
物や名士

ORC-29 Order Type オーダタイプ (CWE)
成分：

Comments

01643<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドは、オーダが入院患者の設定ないし外来患者の設定で実行されるかどうかを示している。もし、このフィールドが値を持っていなければ、システムのデフォルト値がとられる。推奨値に関しては、「HL7 表 0482–オーダタイプ」を参照のこと。
例：退院前にフォローアップの理学療法ないし地域薬局で処方箋を受け取るオーダが出される。その患者は、PV1 によると入院患者だが、そのオーダは外来患者オーダである。
HL7表 0482 - Order Type オーダタイプ
Value
I
O

Description
Inpatient Order 入院患者オーダ
Outpatient Order 外来患者オーダ

ORC-30 Enterer Authorization Mode 入力者承認モード (CNE)
成分：

Comments

01644<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドは、 オーダを作成或いは変更する責任を持つ医師から記録者が得た承認の形態を示している。推奨値に関しては、「HL7 表 0483-承認モード」を参照のこと。

© JAHIS 2022

60

HL7表 0483 - Authorization Mode 承認モード
Value
EL
EM
FX
IP
MA
PA
PH
RE
VC
VO

© JAHIS 2022

Description
Electronic 電子的
E-mailFax
In Person 本人自ら
Mail
Paper 紙Phone 電話
Reflexive (Automated system)ム)Video-conference TV 会議
Voice 口頭

61

Comments

条件に基づく (自動化システ

7.10. PID - Patient Identification Segment 患者識別セグメント
PID セグメントはすべてのアプリケーションで、患者（含む動物）の識別情報を交換することを主要目的としている。このセグメントは恒久的な患者識別を、そして患者基本情報を扱うが、多くの情報はそれほど頻回には変化しない。
HL7 V2.4 以降は動物の患者基本情報も PID セグメント（PID-35 から PID-38 を参照）で送れることになったことを注記しておく。
患者 ID の 4 番目の成分である発行機関のデータ型は HD 型であり、大元の発行機関により一意に関連づけられた固有の番号である。発行機関の ID を与えた機関、相互連絡機関は患者識別情報（そして他の重要な識別情報）を付与する可能性のある発行機関のリストを作成しなければならない。そのリストはその発行機関の最も重要なマスターリストのひとつとなる。
（患者 ID を付与した機関とは別の）第三者機関は、患者識別情報を含む HL7 メッセージを送信あるいは受信するかもしれないので、患者 ID に含まれる発行機関は
MSH で示される送信システムや受信システムと同じであってはならない。発行機関は、その地域では唯一である必要がある。このフィールドは HL7 の導入に際して、複数の患者管理アプリケーションにおいてこのような番号を割り当てる必要がある。発行機関と識別区分コードはすべて CX 型とすることを強く推奨する。
HL7 V2.3 から、患者 ID の 4 番目の成分の名称が「発行機関 ID（assigning facility ID）
」から、
「発行機
関(assigning authority)」に変更になった。識別情報（例えば、XYZZ 病院の A 部門で割り当てられた医療記録）は、それを発行した医療機関では一意的でありえるが、識別情報はシステムレベル（例えば企業の個
人インデックスや、複数企業にまたがるエンタープライズ番号）、または政府による実体（例えば国により与えられた一意的個人識別子）も割り当てられる。施設は大抵発行機関になるのに、すべての発行機関は施設ではない。しかしながら、4 番目の成分は発行機関として参照される。しかし、下位互換性のため HD 型の構成を使っている。
（2 章を参照のこと）。さらに、CX 型は発行機関（HD）を 6 番目の成分として扱うこともできる。
HL7属性表－PID –Patient Identification - 患者識別
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

LEN
4
20
250
20
250
250
26
1
250
250
250
4
250
250
250
250
250
250
16
25

DT
SI
CX
CX
CX
XPN
XPN
TS
IS
XPN
CE
XAD
IS
XTN
XTN
CE
CE
CE
CX
ST
DLN

OPT
O
B
R
B
R
O
O
O
B
O
O
B
O
O
O
O
O
O
B
B

JAHIS
O
B
R
B
RE*
O
RE
RE
B
O
O
B
O
O
O
O
O
O
B
B

RP/#

21
22
23
24
25
26
27
28
29

250
250
250
1
2
250
250
250
26

CX
CE
ST
ID
NM
CE
CE
CE
TS

O
O
O
O
O
O
O
B
O

O
O
O
O
O
O
O
B
O

Y
Y

© JAHIS 2022

TBL#

Y
Y
Y
Y
0001
Y
Y
Y

0005
0289

Y
Y
0296
0002
0006

0189
0136

Y

0171
0172
0212

62

ELEMENT NAME
Set ID - PID セットID-PID
Patient ID 患者ID
Patient Identifier List 患者IDリスト
Alternate Patient ID - PID 代替患者ID
Patient Name 患者氏名
Mother's Maiden Name 母親の旧姓
Date/Time of Birth 生年月日
Administrative Sex 性別
Patient Alias 患者別名
Race 人種
Patient Address 患者住所
County Code 郡コード
Phone Number - Home 電話番号－自宅
Phone Number - Business 電話番号－勤務先
Primary Language 使用
Marital Status 結婚状態
Religion 宗教
Patient Account Number 患者会計口座番号
SSN Number - Patient 社会保障番号
Driver's License Number - Patient 運転免許証番
号
Mother's Identifier 母親の識別情報
Ethnic Group 民族
Birth Place 出生地
Multiple Birth Indicator 多胎児識別情報
Birth Order 誕生順序
Citizenship 市民権情報
Veterans Military Status 退役軍人情報
Nationality 国籍
Patient Death Date and Time 患者死亡日時

SEQ
30
31
32
33
34
35
36
37
38
39

LEN
1
1
20
26
241
250
250
80
250
250

DT
ID
ID
IS
TS
HD
CE
CE
ST
CE
CWE

OPT
O
O
O
O
O
C
C
O
O
O

JAHIS
O
O
O
O
O
C
C
O
O
O

RP/#

TBL#
0136
0136
0445

Y

0446
0447
2
Y

0429
0171

ELEMENT NAME
Patient Death Indicator 患者死亡識別情報
Identity Unknown Indicator 識別情報の有無
Identity Reliability Code 識別情報の信頼性
Last Update Date/Time 最終更新日時
Last Update Facility 最終更新施設
Species Code 種コード
Breed Code 品種コード
Strain 血統情報
Production Class Code 製品分類コード
Tribal Citizenship 所属種族

PID フィールド定義
PID-1 Set ID - PID セット ID-PID (SI)00104

定義：このフィールドはこのトランザクションにおける番号を示す。そのセグメントが最初に現れた
時はこのシーケンス番号は 1 でなければならない。2 回目の時は 2,といった具合である。

PID-2 Patient ID 患者 ID (CX)00105

定義：このフィールドは下位互換性のためにのみ残されている。

PID-3 Patient Identifier List 患者 ID リスト (CX)00106

成分：<ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning
Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date(DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or
Department (CWE)>
副成分 for Assigning Authority (HD)：<Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Assigning Facility (HD)：<Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Assigning Jurisdiction (CWE)：<Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE)：<Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義：このフィールドは医療機関で患者を特定（例：医療記録番号、会計口座番号、誕生記録、国民
識別番号）するための（ひとつ、またはそれ以上の）識別情報を示す。カナダでは、Canadian Provincial
Healthcare Number をこのフィールドで送らなければならない。
独断的であった用語「内部 ID」はこのフィールドの名前から取り除かれた。
【共通編】本規約では「<患者 ID>^^^^PI」の形式で利用する。
例：|0012345678^^^^PI|

PID-4 Alternate Patient ID - PID 代替患者 ID (CX)00107

定義：このフィールドは下位互換のためにのみ残されている。

PID-5 Patient Name 患者氏名 (XPN)00108

成分：<Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given names or Initials
Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^ <Degree (e.g., MD)(IS)> ^ <Name Type Code (ID)> ^ <Name Representation Code (ID)> ^ <Name Context (CE)>^ <Name Validity Range (DR)> ^ <Name Assembly Order (ID)> ^ <Effective Date (TS)> ^<Expiration Date (TS)> ^ <Professional Suffix (ST)>
副成分 for Family Name (FN):<Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Name Context (CE):<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^<Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System(ID)>© JAHIS 2022

63

副成分 for Name Validity Range (DR):<Range Start Date/Time (TS)> & <Range End Date/Time(TS)>
副成分 for Range Start Date/Time (TS):<Time (DTM)> & <Degree of Precision (ID)>
副成分 for Range End Date/Time (TS):<Time (DTM)> & <Degree of Precision (ID)>
副成分 for Effective Date (TS):<Time (DTM)> & <Degree of Precision (ID)>
副成分 for Expiration Date (TS):<Time (DTM)> & <Degree of Precision (ID)>

定義：このフィールドは最初に報告された患者の主な、あるいは法律上の氏名を示している。このフィールドにおける氏名種別コードは「L-法律上」を含む必要がある。推奨値は、「HL7 表 0200 - 名前
種別」、
「HL7 表 0465 - 名前／アドレス表記」を参照のこと。このフィールドは同じ名前について違う
文字セットでの反復が許されている。HL7 の旧バージョンにおける「own family name prefix 」は「lastname prefix」と同義である。同様に「second and further given names or initials thereof」は「middle initial orname」と同義である。名前やイニシャルを複数持つ場合はスペースで区切る。
【共通編】患者氏名を MSH-18 文字セットで指定した文字コードで使用する。
例えば MSH-18 に ASCII~ISO IR87 をセットした場合、PID-5 は Yamada^Tarou^^^^^L^A~山田^太郎^^^^^L^I~ヤマダ^タロウ^^^^^L^P となる。
反復の順序には意味を持たない。姓と名の区別が困難な場合、姓のフィールドを代用するものとする。
半角カタカナは全てのフィールドで使用しないようにすること。
【生理】患者連携機能を持たないモダリティや、患者氏名を使用せずに検査を実施する場合は、本フィールドを使用しなくても良い。
HL7表 0200 - Name Type 名前種別
Value
A
B
C
D
I
L
M
N
P
R
S
T
U

Description
Alias Name 別名
Name at Birth 誕生時の名前
Adopted Name 養子縁組み後の名前
Display Name 表示名
Licensing Name 許可を得た名前
Legal Name 法律上の名前
Maiden Name 旧姓（婚姻前の名前）
Nickname /”Call me” Name/Street Name あだ名／よび名／道路名
Name of Partner/Spouse – obsolete 配偶者の名前－廃止
Registered Name (animals only) 登録名（動物のみ）
Coded Pseudo-Name to ensure anonymity 匿名のためのコード化された偽名
Indigenous/Tribal/Community Name 種族／部族／共同社会名
Unspecified 未定義

Comments

HL7 V2.4 で廃止された

動物においては、名前種別が「R」が使われていた場合は、「Name Context」はこの動物の名前が登録されている機関を識別するために用いられる。
HL7表 0465 – Name/adress representation 名前／アドレス表記
Value
I
A
P

Description
Ideographic 表意文字(例、漢字)
Alphabetic アルファベット（例、デフォルトおよびシングルバイト文字）
Phonetic 表音文字(例、ASCII、カタカナ、ひらがな、など)

PID-6 Mother's Maiden Name 母親の旧姓 (XPN)

Comments00109

成分：<Family Name (FN)> ^ <Given Name (ST)> ^ <Second and Further Given Names or Initials
Thereof (ST)> ^ <Suffix (e.g., JR or III) (ST)> ^ <Prefix (e.g., DR) (ST)> ^<DEPRECATED-Degree (e.g., MD) (IS)> ^ <Name Type Code (ID)> ^ <Name Representation
Code (ID)> ^ <Name Context (CE)> ^ <Name Validity Range (DR)> ^ <Name Assembly Order(ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix from Partner/Spouse (ST)> & <Surname from Partner/Spouse (ST)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>

副成分 for Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range End Date/Time (TS)>
副成分 for Range Start Date/Time (TS): <Time (DTM)> & <Degree of Precision (ID)>
副成分 for Range End Date/Time (TS): <Time (DTM)> & <Degree of Pre-cision (ID)>
副成分 for Effective Date (TS): <Time (DTM)> & <Degree of Precision (ID)>© JAHIS 202264

副成分 for Expiration Date (TS): <Time (DTM)> & <Degree of Precision (ID)>
定義：このフィールドはその母親が生まれた時の名前（例：結婚前）を示す。これは患者の名前が同じ場合に区別するために使われる。
【共通編】本フィールドに出現する名前種別コードは｢M｣である。

PID-7 Date/Time of Birth 生年月日 (TS) 00110
成分：<Time (DTM)> ^ <Degree of Precision (ID)>

定義：このフィールドは患者の誕生日を示す。

PID-8 Administrative Sex 性別 (IS)00111

定義：このフィールドは患者の性別を示す。 推奨値については「使用者定義表 0001－性別」を参照のこと。
使用者定義表 0001 - Administrative Sex 性別
Value
F
M
O
U
A
N

Description
Female 女性
Male 男性
Other その他
Unknown 未知
Ambiguous 両性具有
Not applicable 適応外

PID-9 Patient Alias 患者別名 (XPN)

Comments00112

定義：このフィールドは HL7 V2.4 から下位互換のためにのみ残されている。

PID-10 Race 人種 (CE)00113

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは患者の人種を示す。推奨値は「使用者定義表 0005 -人種」を参照のこと。
人種データの 2/3（alternate identifier, alternate text, and name of alternate coding system）は政府により割り当てられるコードである。

PID-11 Patient Address 患者住所 (XAD)00114

成分：<Street Address (SAD)> ^ <Other Designation (ST)> ^ <City (ST)> ^ <State or Province (ST)>^ <Zip or Postal Code (ST)> ^ <Country (ID)> ^ <Address Type (ID)> ^ <Other Geographic
Designation (ST)> ^ <County/Parish Code (IS)> ^ <Census Tract (IS)> ^ <Address
Representation Code (ID)> ^ <Address Validity Range (DR)> ^ <Effective Date (TS)> ^<Expiration Date (TS)>
副成分 for Street Address (SAD):<Street or Mailing Address (ST)> & <Street Name (ST)> &<Dwelling Number (ST)>
副成分 for Address Validity Range (DR):<Range Start Date/Time (TS)> & <Range End Date/Time(TS)>
副成分 for Range Start Date/Time (TS):<Time (DTM)> & <Degree of Precision (ID)>
副成分 for Range End Date/Time (TS):<Time (DTM)> & <Degree of Precision (ID)>
副成分 for Effective Date (TS):<Time (DTM)> & <Degree of Precision (ID)>
副成分 for Expiration Date (TS):<Time (DTM)> & <Degree of Precision (ID)>

定義：このフィールドは患者の郵送用の住所を示している。アドレス種別コードは「HL7 表 0190 – 住所タイプ」で定義している。同じ個人に対して複数の住所を次の順序で送ることができる：主たる郵送用住所は必ず最初になければならない（下位互換性のため）；もし、郵送用アドレスを送らない場合
は、必ず最初に反復デリミタを送る必要がある。
【共通編】最初のエレメントは、<Street Address (SAD)>
であり、これはさらに<Street or Mailing Address (ST)> & <Street Name (ST)> & <Dwelling Number (NT)>に分解されるので、日本の場合は、
新橋７－５－５^^港区^東京都^105-0004^^H© JAHIS 202265

のように記述する。ただし、住所を(都道府県や市町村などに)分離して管理していない場合は、第 8
成分だけを用いて、^^^^105-0001^^H^東京都港区新橋７－５－５のように記述する。また、第 7 成分を「B」（=会社／事業所）とすることで、患者の勤務先の郵便番
号、住所を表現することもできる。
^^^^105-0001^^B^東京都千代田区霞が関４－２－２
HL7表 0190 - Address type 住所タイプ
Value
BA
N
BDL
F
C
B
H
L
M
O
P
RH

BR

Description
Bad address 誤った住所
Birth (nee) (birth address, not otherwise specified) 出生（生まれ）（他に指定がな
ければ、出生の住所）
Birth delivery location (address where birth occurred) 出生地（誕生が行われた住所）
Country of Origin 出身国
Current or Temporary 現住所または一時的な住所
Firm/Business 会社/事業所
Home 自宅
Legal Address 法律上の住所
Mailing 郵送先
Office 事務所
Permanent 永久的な住所
Registry home. Refers to the information system, typically managed by a publichealth agency, that stores patient information such as immunization histories orcancer data, regardless of where the patient obtains services. 戸籍上の自宅。予防接種歴や癌登録のような患者情報を扱う公共医療機関の情報システムに関係する事が多い。患者が治療を受ける場所には無関係である。
Residence at birth (home address at time of birth) 出生時の居住地（出生の際の自宅住所）

PID-12 County Code 郡コード (IS)Comments00115

定義：このフィールドは HL7 V2.3 から下位互換性のためにのみ残されている。

PID-13 Phone Number - Home 電話番号－自宅 (XTN)

00116

成分：<Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication
Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code(NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix(ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

定義：このフィールドでは患者の個人的な電話番号を示す。すべての患者の個人電話番号は次の順序で送られる。最初は主として使われる電話番号（下位互換性のため）である。もし、主として使われる電話番号がない場合は、必ず最初に反復デリミタを送る必要がある。推奨値については「HL7 表 0201
－遠距離通信用途コード」と、「HL7 表 0202－遠距離通信機器タイプ」を参照のこと。
HL7表 0201－Telecommunication Use Code 遠距離通信用途コード
Value
PRN
ORN
WPN
VHN
ASN
EMR
NET
BPN

© JAHIS 2022

Description
Primary Residence Number 主たる住居の番号
Other Residence Number その他の住居の番号Work Number 勤務先番号
Vacation Home Number 休暇中の住居の番号
Answering Service Number 留守電話応答サービス番号
Emergency Number 緊急連絡先番号
Network (email) Address ネットワーク(電子メール)アドレス
Beeper Number ポケットベル番号66

Comments

HL7表 0202－Telecommunication Equipment Type 遠距離通信機器タイプ
Value
PH
FX
MD
CP
BP
INTERNET
X.400
TDD
TTY

Description
Telephone 電話
Fax ファックス
Modem モデム
Cellular Phone 携帯電話
Beeper ポケットベル
Internet Address インターネットアドレス：遠距離通信用途コードがNET の場合のみ使用
X400 email address 電子メールアドレス：遠距離通信用途コードがNET の場合のみ使用
Telecommunications Device for the Deaf 聴覚障害者のための遠距離
通信機器
Teletypewriter テレタイプ

Comments【共通編】
注記：PID-13（電話番号）XTN の第 1 要素は、オプション値が ’B’(Backword) なので使用しない。
なお、電話番号は第 12 成分に記述することとし、例えば、^PRN^PH^^^^^^^^^03-0000-0000と扱うこととする。

PID-14 Phone Number - Business 電話番号－勤務先 (XTN)

00117

成分：<Telephone Number (ST)> ^ <Telecommunication Use Code (ID)> ^ <Telecommunication
Equipment Type (ID)> ^ <Email Address (ST)> ^ <Country Code (NM)> ^ <Area/City Code(NM)> ^ <Local Number (NM)> ^ <Extension (NM)> ^ <Any Text (ST)> ^ <Extension Prefix(ST)> ^ <Speed Dial Code (ST)> ^ <Unformatted Telephone number (ST)>

定義：このフィールドでは患者の職場の電話番号を示す。すべての職場の電話番号は次の順序で送られる。最初は主として使われる電話番号（下位互換性のため）である。もし主として使われる電話番
号がない場合は、必ず最初に反復セパレータを送る必要がある。推奨値については「HL7 表 0201－遠
距離通信用途コード」と「HL7 表 0202－遠距離通信機器タイプ」を参照のこと。
【共通編】電話番号は第 12 成分に記述することとし、例えば、^PRN^PH^^^^^^^^^03-3506-8070と扱うこととする。

PID-15 Primary Language 使用言語－患者 (CE)00118

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドでは患者の使用する言語を示す。HL7 としての推奨は「使用者定義表 296 -使用言語」として ISO 表 639 の使用である。
使用者定義表 0296 - Primary Language 使用言語
Value

Description
no suggested values 推奨値なし

PID-16 Marital Status 結婚状態 (CE)Comments00119

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドでは患者の結婚状態（民事）を示す。推奨値は「使用者定義表 0002－結婚状態」
を参照のこと。
使用者定義表 0002 - Marital Status 結婚状態
Value
A
D
M
S
W
C
G
P
R

© JAHIS 2022

Description
Separated 別居
Divorced 離婚
Married 既婚
Single 独身
Widowed 未亡人
Common law 法的
Living together 同居・同棲
Domestic partner 配偶者
Registered domestic partner 登録された配偶者

67

Comments

Value
E
N
I
B
U
O
T

PID-17 Religion 宗教 (CE)

Description
Legally Separated 法的な別居
Annulled 取消
Interlocutory 対話者
Unmarried 未婚
Unknown 不明
Other その他
Unreported 未報告

Comments00120

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドでは患者の宗教を示す。推奨値は「使用者定義表 0006-宗教」を参照のこと。
使用者定義表 0006 - Religion 宗教
Value
AGN
ATH
BAH
BUD
BMA
BTH
BTA
BOT
CFR
CHR
ABC
AMT
AME
ANG
AOG
BAP
CAT
CRR
CHS
CMA
COC
COG
COI
COM
COL
EOT
EVC
EPI
FWB
FRQ
GRE
JWN
LUT
LMS
MEN
MET
MOM
NAZ
ORT
COT
PRC
PEN
COP
PRE
PRO
QUA
REC
REO

© JAHIS 2022

Description
Agnostic
AtheistBaha'i
Buddhist
Buddhist: Mahayana
Buddhist: Theravada
Buddhist: Tantrayana
Buddhist: Other
Chinese Folk Religionist
ChristianChristian: American Baptist Church
Christian: African Methodist Episcopal
Christian: African Methodist Episcopal Zion
Christian: Anglican
Christian: Assembly of God
Christian: Baptist
Christian: Roman Catholic
Christian: Christian Reformed
Christian: Christian Science
Christian: Christian Missionary Alliance
Christian: Church of Christ
Christian: Church of God
Christian: Church of God in Christ
Christian: Community
Christian: Congregational
Christian: Eastern Orthodox
Christian: Evangelical Church
Christian: Episcopalian
Christian: Free Will Baptist
Christian: Friends
Christian: Greek Orthodox
Christian: Jehovah's Witness
Christian: Lutheran
Christian: Lutheran Missouri Synod
Christian: Mennonite
Christian: Methodist
Christian: Latter-day Saints
Christian: Church of the Nazarene
Christian: Orthodox
Christian: Other
Christian: Other Protestant
Christian: Pentecostal
Christian: Other Pentecostal
Christian: Presbyterian
Christian: Protestant
Christian: Friends
Christian: Reformed Church
Christian: Reorganized Church of Jesus Christ-LDS

68

Comments

Value
SAA
SEV
SOU
UCC
UMD
UNI
UNU
WES
WMC
CNF
ERL
HIN
HVA
HSH
HOT
JAI
JEW
JCO
JOR
JOT
JRC
JRF
JRN
MOS
MSU
MSH
MOT
NAM
NRL
NOE
OTH
SHN
SIK
SPI
VAR

Description
Christian: Salvation Army
Christian: Seventh Day Adventist
Christian: Southern Baptist
Christian: United Church of Christ
Christian: United Methodist
Christian: Unitarian
Christian: Unitarian Universalist
Christian: Wesleyan
Christian: Wesleyan Methodist
ConfucianEthnic Religionist
Hindu
Hindu: Vaishnavites
Hindu: Shaivites
Hindu: Other
Jain
JewishJewish: Conservative
Jewish: Orthodox
Jewish: Other
Jewish: Reconstructionist
Jewish: Reform
Jewish: Renewal
MuslimMuslim: Sunni
Muslim: Shiite
Muslim: Other
Native American
New Religionist
Nonreligious
Other
Shintoist
SikhSpiritist
Unknown

PID-18 Patient Account Number 患者会計口座番号 (CX)

Comments00121

成分：<ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning
Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date(DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or
Department (CWE)>
副成分 for Assigning Authority (HD)：<Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Assigning Facility (HD) <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Assigning Jurisdiction (CWE)：<Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE)：<Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義：このフィールドでは患者のすべての課金、支払い等を記録し、計算するために割り付けられた
会計口座番号を示す。患者の会計を識別するために使用される。推奨値は「HL7 表 0061 - チェック
デジット形式」を参照のこと。

PID-19 SSN Number - Patient 社会保障番号(ST)00122

定義：このフィールドは HL7 V2.3.1 から下位互換性のためにのみ残されている。

© JAHIS 2022

69

PID-20 Driver's License Number - Patient 運転免許証番号 (DLN)00123

定義：このフィールドは HL7 V2.3.1 から下位互換性のためにのみ残されている。

PID-21 Mother's Identifier 母親の識別情報(CX)00124

成分：<ID Number (ST)> ^ <Check Digit (ST)> ^ <Check Digit Scheme (ID)> ^ <Assigning
Authority (HD)> ^ <Identifier Type Code (ID)> ^ <Assigning Facility (HD)> ^ <Effective Date(DT)> ^ <Expiration Date (DT)> ^ <Assigning Jurisdiction (CWE)> ^ <Assigning Agency or
Department (CWE)>
副成分 for Assigning Authority (HD)：<Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Assigning Facility (HD)：<Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID
Type (ID)>
副成分 for Assigning Jurisdiction (CWE)：<Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE)：<Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義：このフィールドは、例えば、新生児用に関係を示すために用いられる。一般的には患者 ID ある
いは会計口座番号を使用する。このフィールドは同じ母親を示す複数の識別情報を含むことができる。
推奨値は「HL7 表 0061- チェックデジット形式」を参照のこと。

PID-22 Ethnic Group 民族(CE)00125

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは患者の先祖を定義する。推奨値については「使用者定義表 0189 - 民族」を参照のこと。民族データの後半（alternate identifier, alternate text, and name of alternate coding system）は政府により割り当てられるコードである。アメリカでは一般に民族性の報告はスペイン系住民に対する米国連邦政府の標準規約と同じである。
使用者定義表 0189 - Ethnic Group 民族
Value
H
N
U

Description
Hispanic or Latino
Not Hispanic or Latino
Unknown

PID-23 Birth Place 出生地(ST)Comments00126

定義：このフィールドは患者の出生地を示す。例えば「St. Francis Community Hospital of Lower South Side」である。現住所は PID-11 に識別情報「N」で報告する。

PID-24 Multiple Birth Indicator 多胎児識別情報 (ID)00127

定義：患者が多胎児の一人であったかどうか示す。推奨値は「HL7 表 0136 - Yes/No 標識」を参照のこと。
Y
多胎児の一人N
多胎児でない一人

PID-25 Birth Order 誕生順序 (NM)00128

定義：患者が多胎出産だった時に、このフィールドには何番目に生まれたか（数字）を示す。

PID-26 Citizenship 市民権情報 (CE)00129

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは個人の市民権のある国に関する情報を示す。国の市民権については HL7 では
ISO 表 3166 の使用を推奨する。もし、個別に定義をする場合は、「使用者定義表 0171-市民権」を使用しなければならない。

© JAHIS 2022

70

個人が複数の国で住民であった場合、このフィールドは繰り返す。CE データ型のコードシステム名は市民権や団体が書かれた表によって識別される。
オランダでは、このフィールドは「国籍」を示す。
使用者定義表 0171 - Citizenship 市民権
Value

Description
no suggested values 推奨値なし

PID-27 Veterans Military Status 退役軍人情報 (CE)Comments00130

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドは退役軍人に割り当てられた軍人情報である。推奨値については「使用者定義
表 0172-退役軍人情報」に示す。
使用者定義表 0172 - Veterans Military Status 退役軍人情報
Value

Description
no suggested values 推奨値なし

PID-28 Nationality 国籍 (CE)Comments00739

定義：V2.4 以降から、このフィールドは下位互換性のためにのみ残されている。

PID-29 Patient Death Date and Time 患者死亡日時 (TS)00740

成分：<Time (DTM)> ^ <Degree of Precision (ID)>

定義：このフィールドは患者が死亡した日時を示す。

PID-30 Patient Death Indicator 患者死亡識別情報 (ID)00741

定義：このフィールドは患者が死亡しているのか否かを示す。推奨値は「HL7 表 0136 - Yes/No 標識」
を参照のこと。
Y
患者は死亡しているN
患者は死亡していない

PID-31 Identity Unknown Indicator 識別情報の有無 (ID)01535

定義：このフィールドは患者／個人の識別情報がわかっているか否かを示す。推奨値は「HL7 表 0136
- Yes/No 標識」を参照のこと。
Y
患者／個人の識別情報は未知である。
N
患者／個人の識別情報は既知である。

PID-32 Identity Reliability Code 識別情報の信頼性 (IS)01536

定義：このフィールドは、トランザクションで送られた患者／個人識別情報の信頼性評価情報を伝えるために使用する。
この値で PID セグメントの特定フィールドの患者／個人識別情報が誤り（例えば、初期値であるとか、システムで生成した生年月日、社会保障番号）であること示すことができる。推奨値については「使用者定義表 0445－識別情報の信頼性」を参照のこと。
使用者定義表 0445 - Identity Reliability Code 識別情報の信頼性
Value
US
UD
UA
AL

Description
Unknown/Default Social Security Number 不明／社会保障番号（初期値）
Unknown/Default Date of Birth 不明／誕生日（初期値）
Unknown/Default Address 不明／住所（初期値）
Patient/Person Name is an Alias 患者／個人名は別名

PID-33 Last update Date/Time 最終更新日時 (TS)Comments01537

成分：<Time (DTM)> ^ <Degree of Precision (ID)>

定義： このフィールドでは PID セグメントに含まれる患者／個人の識別情報や患者基本情報の最終更新日時を示す。受信側システムではこのフィールドを用いて、どのようにそのトランザクションをそのシステムで扱うかを判断するために使用する。もし、受信側システム（例えばエンタープライズマ© JAHIS 202271

スター患者インデックス）が、既により新しい個人の情報を持っていた場合、そのトランザクション
からの患者／個人基本情報、識別情報を使用しないことと判断する。

PID-34 Last Update Facility 最終更新施設 (HD)01538

成分：<Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID Type (ID)>

定義：このフィールドは PID セグメントに含まれる患者／個人の識別情報や患者基本情報の最終更新をした機関の識別情報を示す。受信側のシステムまたは使用者は、このフィールドにより該当トラン
ザクションをそのシステムに適応するかを判断する。もし、受信側システム（例えば病院の患者管理システム）は既にその患者／個人の記録を持っている場合、信頼できる情報源からの情報のみ更新するかもしれない。病院は他の病院を信頼できる情報源と考えるかもしれない。しかし、急性期治療機関ではない医療機関からの更新は信じないかもしれない。
書式例は次のとおり。
...|Metro Hospital|...

PID-35 Species Code 種コード (CE)01539

成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
定義：生物の種。このフィールドはコーディングシステムを用いて一般名もしくは学術名を示す。
SNOMED を推奨する。
もしこのフィールドの値が無い場合は人間が対象である。
推奨値については「使
用者定義表 0446-種コード」を参照のこと。
使用者定義表 0446 - Species Code 種コード
Value

Description
no suggested values 推奨値なし

Comments

条件付きルール：もし PID-36 品種コードまたは PID-38 製品分類コードが値を持つ時は、このフィールドも値を持つ必要がある。例：...|L-80700^Canine, NOS^SNM3|...
...|L-80100^Bovine^SNM3|...
...|L-80A00^Feline^SNM3|...

PID-36 Breed Code 品種コード (CE)01540

成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>
定義：特定の動物の品種。このフィールドは種や血統と異なり動物に対して特有で、一般の生物には使うことができない。コーディングシステムは SNOMED を推奨する。推奨値については「使用者定義表 0447-品種コード」を参照のこと。
使用者定義表 0447 - Breed Code 品種コード
Value

Description
no suggested values 推奨値なし

Comments

条件付きルール：PID-37 血統情報が値を持つ時は、このフィールドは値を持たなくてはならない。
例（一部に「アメリカンカーネルクラブ」と用語定義されている動物の主および代替えコーディング
システムを示す。
）：...|L-80733^ Staffordshire bull terrier^SNM3^^American Staffordshire Terrier^99AKC|...
...|L-80900^Weimaraner^SNM3|...
...|L-80439^Peruvian Paso Horse^SNM3|...

PID-37 Strain 血統情報 (ST)01541

定義：このフィールドは動物の血統情報を示す。このフィールドはどのような生物の血統情報にも、
また動物以外にも拡張することができる。
例：...|DeKalb|...
...|Balb/c|...
...|DXL|...

© JAHIS 2022

72

PID-38 Production Class Code 製品分類コード (CE)01542

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義：このフィールドはその生物が主に飼育されたものか、成長したものかを示すコードと／もしくはテキストである。推奨値については「使用者定義表 0429-製品分類コード」を参照のこと。
使用者定義表 0429 - Production Class Code 製品分類コード
Value
BR
DA
DR
DU
LY
MT
OT
PL
RA
SH
NA
U

Description
Breeding/genetic stock
Dairy
Draft
Dual Purpose
Layer, Includes Multiplier flocks
Meat
Other
Pleasure
RacingShow
Not Applicable
Unknown

Comments

例：...|DA^Dairy^L|...
...|MT^Meat^L|...
...|RA^Racing^L|...

PID-39 Tribal Citizenship 所属部族 (CWE)

01840

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^<Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)>^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドには個人の所属種族に関する情報が含まれる。合衆国における所属種族としては、HL7 はインディアン事務局（BIA）種族識別リストによることを推奨する。もし個別に定義する
場合は、「使用者定義表 0171-市民権」を使わなければならない。
個人が複数の種族に属したことがある場合、このフィールドは繰り返す。CWE データ型のコードシス
テム名は種族が書かれた表によって識別される。

© JAHIS 202273

7.11. PV1 - Patient Visit Segment 来院情報セグメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

7.12. QAK - Query Acknowledgment Segment 照会応答セグメント
JAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

© JAHIS 2022

74

7.13. QPD - Query Parameter Definition 照会パラメータ定義
QPD セグメントは照会のパラメータを定義する。
HL7属性表－QPD－Query Parameter Definition照会パラメータ定義
SEQ
1
2
3-n

LEN
250
32
256

DT
CE
ST
Varies

OPT
R
C

JAHIS
R
C
C

RP/#

TBL#
0471

ELEMENT NAME
Message Query Name メッセージ照会名Query Tag 照会タグ
User Parameters (in successive fields)
ユーザ・パラメータ(以降のフィールド)QPD フィールド定義
QPD-1 Message Query Name メッセージ照会名 (CE) 01375
成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義： このフィールドは照会名を含む。これらの名前は、この仕様の機能に特化した章に割り当てられている。照会名に関しては、適合宣言書と一対一であり、実際にその適合宣言書のための識別子である。施設固有の照会名は、文字 Z から始まる。推奨値については、「使用者定義表 0471－照会名」
を参照のこと。
使用者定義表 0471 – 照会名
Value

Description

IHE PDQ QueryIHE PDVQ QueryZS1^Order Query^JHSS0002

生理検査依頼照会

ZS3^Storage Commitment^JHSS0002

データ保存確認

Comment
JAHISデータ交換規約 共通編 Ver.1.3参照
JAHISデータ交換規約 共通編 Ver.1.3参照

QPD-2 Query Tag 照会タグ (ST) 00696
定義： このフィールドは、照会を識別するために開始するシステムによって値が入れられ、そして応答メッセージを元の照会に一致させるために使用しても良い。もしこのフィールドに値がセットされた場合、応答システムは照会認知セグメント(QAK)の最初のフィールドとしてそれをエコーバック
することを要求される。
このフィールドは、MSA -2 メッセージ制御 ID とは異なる。その値が照会に関係があるそれぞれのメッセージ(すなわちすべての継続メッセージ)では一定のままであるのに対し、MSA -2 メッセージ制御
ID は、それが全体としての照会ではなく、それぞれの個々のメッセージに関係があるため、それぞれの継続メッセージによって異なっていてよい。
[実装時の注意点：ソケット上の唯一の応答メッセージが今送られた照会に対する応答になる実装では、このフィールドに値を入れる必要がない。逆に、多くの照会、応答、および他のメッセージが同
じソケットで双方向に伝えられる「非同期」な実装の場合には、サーバがどの照会に応答しているかをクライアントがわかるように、このフィールドに値が入ることが必須である。]

QPD-3 User Parameters ユーザ・パラメータ (Varies) 01435
定義： これらの後続のパラメータ・フィールドは、クライアントがサーバに渡す値を保持する。
クライアント・データは、一連の HL7 フィールドとして存在する。QPD -3 ユーザ・パラメータから始まって、QPD セグメントの残りフィールドは、ユーザ・パラメータ・データを伝える。それぞれの QPD ユーザ・パラメータ・フィールドは、それぞれの名前、データ型、オプション指定、および反復が指定されている、適合宣言書で定義された１つのパラメータに対応する。これらのパラメー
タが通常は共に「AND 条件」であると理解されている一方で、ユーザは、適切にそれぞれを理解するために、要求された適合宣言書を注意深く調べなくてはいけない。QSC 別形を除いて、パラメータ
名は照会で述べられる必要がなく、それらは、適合宣言書に基づいた位置にあると理解される。

© JAHIS 2022

75

それぞれのパラメータ・フィールドは、複雑な QIP および QSC 型を含めて、どんな単一のデータ型としてでも適合宣言書に指定できる。また、パラメータ・フィールドは、以下のセクション HL7 V2.5
5.4.4.3.1 節で定義された、ソート・コントロール( SRT )フィールドあるいはセグメントグループ( ID )フィールドを含んでもよい。QPD セグメントのパラメータ・フィールドは、適合宣言書と同じ順序で現れる。
【生理】QPD-1 にて推奨したメッセージ問合せ名に対応する使用者定義パラメータを以下に示す。

表7.13-1 QPD パラメータ仕様 – 生理検査依頼照会 (ZS1^Order Query^JHSS0002)
Field Seq
(QueryID=Znn)1

Col Name
MessageQuery

Key/S
earch

Sort

LEN

TYPE

Opt

250

CE

R

32

ST

R

256

CX

C

Rep

Match
Op

TBL

Segment
Field
Name

Service
Identifier
CodeElement
Name

Name メッセー
ジ 照会名2QueryTag 照会
タグ

3

Patient ID 患者

=

PID-3

IDリスト

PID-3:Patie
nt Identifier
List 患者ID
リスト

4

Placer Order

22

EI

C

=

ORC-2

ORC-2:Plac

Number 依頼者

er Order

オーダ番号

Number 依
頼者オーダ
番号

5

Universal

256

CE

C

OBR-4

OBR-4:Univ

Serviceersal

Identifier 汎用

Service

サービスID

Identifier
汎用サービ
スID

6

Filler Order

22

EI

C

=

ORC-3

Number 実施者

ORC-3:Filler OrderNumber 実

オーダ番号

施者オーダ
番号
7

Equipment

22

EI

C

OBX-18

OBX-18:Eq

instance

uipment

identifier 機器

Instance

インスタンス識

Identifier 機

別子

器インスタ
ンス識別子

8

Where Subject

20

ST

C

QRF-1

QRF-1:Whe

Filter対象場所

re Subject

フィルタ

Filter 対象
場所フィル
タ

9

When Data

26

TS

C

TQ1-7

Start Date/Time

Date/Time

データ開始日時
10

When Data End

TQ-7:Start
開始日時

26

TS

C

TQ1-8

TQ-8:End

Date/Time デー

Date/Time

タ終了日時

終了日時

© JAHIS 2022

76

Field Seq(QueryID=Znn)11

Col Name

Key/S
earch

Sort

LEN

TYPE

Opt

60

ST

C

Rep

Match
Op

TBL

Segment
Field
Name
ORC-5

Service
Identifier
CodeElement
Name
QRF-5:Othe

Other QRYr QRYSubject Filter

Subject

他のQRY対象フFilter 他の

ィルタ

QRY対象フ
ィルタ

12

Which

12

ID

C

‘Y

0156

QRF-6

QRF-6:Whi

Date/Timech

Qualifier対象日

Date/Time

時修飾子

Qualifier 対
象日時修飾
子

13

Date/Time

12

ID

C

Y

0158

QRF-8

QRF-8:Date

Selection/Time

Qualifier日時選

Selection

択修飾子

Qualifier 日
時選択修飾子

表7.13-2 QPD パラメータ仕様 – データ保存確認 (ZS3^Storage Commitment^JHSS0002)
Field Seq
(QueryID=Znn)Col Name

1

MessageQuery

Key/S
earch

Sort

LEN

TYPE

Opt

250

CE

R

32

ST

R

256

EI

R

Rep

Match
Op

TBL

Segment
Field
Name

Service
Identifier
CodeElement
Name

Name メッセー
ジ 照会名2QueryTag 照会
タグ3

Data UID デー=

タ固有識別ID

Data UID は保存確認を行いたいデータの固有識別 ID である。この UID によって、モダリティと LIS間で対象データは唯一特定される。

© JAHIS 2022

77

7.14. QRD - Query Definition Segment 照会定義セグメント
QRD セグメントは、照会を定義するのに使われる。
HL7属性表－QRD－オリジナルスタイル照会定義
SEQ
1
2
3
4
5
6
7
8
9
10
11
12

LEN
26
1
1
10
1
26
10
250
250
250
20
1

DT

OPT
R
R
R
R
O
O
R
R
R
R
O
O

TS
ID
ID
ST
ID
TS
CQ
XCN
CE
CE
VR
ID

JAHIS
R
R
R
R
O
O
R
R
R
R
O
O

RP/#

TBL #
0106
0091
0107
0126

Y
Y
Y
Y

0048

0108

ELEMENT NAME
Query Date/Time 照会日時
Query Format Code 照会フォーマットコード
Query Priority 照会優先度
Query ID 照会ID
Deferred Response Type 遅延応答タイプ
Deferred Response Date/Time 遅延応答日時
Quantity Limited Request 数量制限請求
Who Subject Filter 対象人物フィルタ
What Subject Filter 対象フィルタ
What Department Data Code 対象部門データコード
What Data Code Value Qual. 対象データコード値修飾子
Query Results Level 照会結果レベル

QRD フィールド定義
QRD-1 Query Date/Time 照会日時 (TS) 00025
成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義： このフィールドは、アプリケーションプログラムによって照会を作成した日時を含む。

QRD-2 Query Format Code 照会フォーマットコード (ID) 00026
定義： このフィールドでは、取りうるコードは、「HL7 表 – 0106 照会応答フォーマットコード」を参照のこと。
HL7表 0106 – Query/Response Format Code
Value
D

照会応答フォーマットコード

Description
Response is in display format 応答が表示モードにあるComment

R

Response is in record-oriented format 応答が診療記録用モードにあるT

Response is in tabular format 応答が表用フォーマットにある

QRD-3 Query Priority 照会優先度 (ID) 00027
定義： このフィールドは、応答が期待される時間枠を含む。取りうる値は「HL7 表 - 0091 照会優先度」を参照のこと。テーブル値と以降のフィールドは、応答の時間枠を指定する。
HL7表 0091－Query Priority
Value
D

DeferredI

Immediate

照会優先度

Description

Comment

遅延
即時

QRD-4 Query ID 照会 ID (ST) 00028
定義： このフィールドは、照会に対する一意の識別子を含む。照会アプリケーションによって割り当てられ、応答アプリケーションによりそのままエコーバックする。

QRD-5 Deferred Response Type 遅延応答タイプ (ID) 00029
定義： このフィールドの取りうる値は「HL7 表 – 0107 遅延応答タイプ」を参照のこと。
HL7表 0107 – Deferred Response Type© JAHIS 2022

Value
B

Description
Before the Date/Time specified 指定日時以前

L

Later than the Date/Time specified 指定日時以降

78

遅延応答タイプ
Comment

QRD-6 Deferred Response Date/Time 遅延応答日時 (TS) 00030
成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義： このフィールドは、遅延応答の送信日時以前または以降の日時を含む。存在しない場合、応答は可能になった時点で送ることができる。(QRD-5 遅延応答タイプ参照のこと）

QRD-7 Quantity Limited Request 数量制限請求 (CQ) 00031
成分: <quantity (NM)> ^ <units (CE)>

副成分 for Unit(CE) ：<Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> & <Alternate
Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System (ID)>
定義： このフィールドは、要求システムが受け入れられる応答の最大長を含む。有効な応答は、第 2成分内で指定した単位で与えられた第 1 成分の数値である。第 2 成分の取りうる値は、「HL7 表 0126
– 数量制限要求」を参照のこと。デフォルトは LI(行)。
HL7表 0126 – Quantity Limited Request
Value
CH

数量制限要求Description

Comment

Characters 文字LI

Lines 行PG

Pages ページRD

Records レコード

ZO

Locally defined ローカルで定義

QRD-8 Who Subject Filter 対象人物フィルタ (XCN) 00032
成分: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)>^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source
table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <code identifying thecheck digit scheme employed(ID)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)>
副成分 for Family Name (FN): <Surname (ST)> & <Own Surname Prefix (ST)> & <Own Surname(ST)> & <Surname Prefix From Partner/Spouse (ST)> & <Surname From Partner/Spouse(ST)>
副成分 for Assigning Authority: <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID type(ID)>
副成分 for Assigning Facility: <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID type(ID)>
副成分 for Name Context (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)>& <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>
副成分 for DEPRECATED-Name Validity Range (DR): <Range Start Date/Time (TS)> & <Range
End Date/Time (TS)>Note subcomponent contains sub-subcomponents
副成分 for Effective Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分for Expiration Date (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Assigning Jurisdiction (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>
副成分 for Assigning Agency or Department (CWE): <Identifier (ST)> & <Text (ST)> & <Name of
Coding System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of
Alternate Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding
System Version ID (ST)> & <Original Text (ST)>

定義： このフィールドは、対象人物、あるいは誰に関する照会かを識別する。

QRD-9 What Subject Filter 対象フィルタ (CE) 00033
成分: <identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義： このフィールドは、要求を満たすために必要な情報の種類を記述する。取りうる値はトランザクション照会のタイプを定義し、実装時に施設で拡張することができる。
【生理】「生理検査結果照会(QRY/ORF)」は RES（結果）を指定する。

© JAHIS 2022

79

HL7表 0048 – What Subject Filter 対象主題フィルタ
Value
ADV
ANU
APN
APP
ARN
APM
APA
CAN
DEM
FIN
GID
GOL
MRI
MRO
NCK
NSC
NST
ORD
OTH
PRB
PRO
RES
RAR
RER
RDR
RGR
ROR
SAL

SBK
SBL
SOF
SOP

SSA
SSR
STA
VXI
XID

Description
Advice/diagnosis
助言／診断
Nursing unit lookup (returns patients in beds, excluding empty beds)
看護ユニット検索(ベッドにいる患者を返す。空きベッドは除く)
Patient name lookup
患者名検索
Physician lookup
医師検索
Nursing unit lookup (returns patients in beds, including empty beds)
看護ユニット検索（患者をベッドに戻す、空きベッドも含む）
Medical record number query, returns visits for a medical record number
カルテ番号照会、カルテ番号への受付番号を返す
Account number query, return matching visit
口座番号照会、一致した受付番号を返す
Cancel. Used to cancel a query
キャンセル. 照会キャンセルに使われる
Demographics デモグラフィックス
Financial 財務
Generate new identifier 新規識別子生成
Goals ゴール
Most recent inpatient 最近の入院患者
Most recent outpatient 最近の来院患者
Network clock ネットワーク時刻
Network status change ネットワーク状態変更
Network statistic ネットワーク統計
Order オーダ
Other その他
Problems 問題
Procedure 手順
Result結果

Comment【生理】生理検査結果照会(QRY/ORF)
はこの値をセットする

Pharmacy administration information 処方管理情報
Pharmacy encoded order information 処方コード化オーダ情報
Pharmacy dispense information 処方調剤情報
Pharmacy give information 処方投与情報
Pharmacy prescription information 処方箋情報
All schedule related information, including open slots, booked slots, blocked
slots
すべての予約関連情報 空いた予約枠、予約された予約枠、予約停止枠を含む。
Booked slots on the identified schedule
識別された予約における予約された予約枠
Blocked slots on the identified schedule
識別された予約における予約停止枠
First open slot on the identified schedule after the start date/time
開始日時以降の識別された予約における最初の空き予約枠
Open slots on the identified schedule between the begin and end of the startdate/time range
開始日時の開始と終了の間に識別された予約における空いた予約枠
Time slots available for a single appointment
単一の予約に利用できる時間予約枠
Time slots available for a recurring appointment
再予約に利用できる時間予約枠
Status 状態
Vaccine Information 予防接種情報
Get cross-referenced identifiers 相互参照された識別子を取得

QRD-10 What Department Data Code 対象部門データコード (CE) 00034
成分: <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)>

定義： このフィールドは、検査番号、手順番号、薬剤コード、品目番号、オーダ番号等などが指定可能である。このフィールドの内容は、直前のフィールドの内容により決定される。このフィールドには、反復区切り文字で区切ることにより、複数の発生を含むことができる。

© JAHIS 2022

80

【生理】
「生理検査結果照会(QRY/ORF)」は依頼者オーダ番号を指定するが、依頼者オーダ番号が無い場合は|””|を指定する。

QRD-11 What Data Code Value Qual. 対象データコード値修飾子 (VR) 00035
成分: <first data code value (ST)> ^ <last data code value (ST)>

定義： このフィールドは、成分セパレータによって区切られた開始と停止を含む。これらの値は照会をさらに絞り込むためのウインドウまたは範囲を示す。

QRD-12 Query Results level 照会結果レベル (ID) 00036
定義： このフィールドは、結果詳細レベルを制御するのに使用する。取りうる値は「HL7 表 - 0108 照
会結果レベル」を参照のこと。
【生理】生理検査結果照会では、通常は T（すべての結果）を指定する。
HL7表 0108 – Query Results Level
Value
O
R
S
T

© JAHIS 2022

Description
Order plus order status オーダとオーダ状態
Results without bulk text 長文を除いた結果
Status only 状態のみ
Full results すべての結果

81

照会結果レベル
Comment

7.15. QRF - Query Filter Segment 照会フィルタセグメント
QRF セグメントはオリジナルスタイルの照会内容をさらに改良するために QRD セグメントとともに使われる。
HL7属性表 – QRF – オリジナルスタイル照会フィルタ
SEQ
1
2

LEN
20
26

DT
ST
TS

OPT
R
B

JAHIS
R
B

RP/#
Y

TBL#

3

26

TS

B

B

4
5

60
60

ST
ST

O
O

O
C

Y
Y

6
7

12
12

ID
ID

O
O

C
O

Y
Y

0156
0157

8

12

ID

O

O

Y

0158

9

60

TQ

O

O

10

10

NM

O

O

ELEMENT NAME
Where Subject Filter対象場所フィルタ
When Data Start Date/Time対象データ開始
日時
When Data End Date/Time 対象データ終了
日時
What User Qualifier 対象ユーザ修飾子
Other QRY Subject Filter 他のQRY対象フィルタWhich Date/Time Qualifier 対象日時修飾子
Which Date/Time Status Qualifier 対象日時
状態修飾子
Date/Time Selection Qualifier 日時選択修飾子
When Quality/Timing Qualifier 数量/タイミ
ング修飾子
Search Confidence Threshold サーチ範囲

QRF フィールド定義
QRF-1 Where Subject Filter 対象場所フィルタ (ST) 00037
定義： このフィールドはその問合せが対象とする部門、システム、サブシステムを識別する。このフィールドは、LAB~HEMO などのように繰り返すことができる。

QRF-2 When Data Start Date/Time 対象データ開始日時 (TS) 00038
成分: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
定義： このフィールドは、下位互換性のためだけに用意されている。

QRF-3 When Data End Date/Time 対象データ終了日時 (TS) 00039
成分: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
定義： このフィールドは、下位互換性のためだけに用意されている。

QRF-4 What User Qualifier 対象ユーザ修飾子 (ST) 00040
定義： このフィールドには、対象データの特性をさらに定義するための識別子を含む。

QRF-5 Other QRY Subject Filter 他の QRY 対象フィルタ (ST) 00041
定義： このフィールドには、2 つのシステム間で使用する施設定義のフィルタを含んでいる。このフィルタは、関連するアプリケーションや施設にのみ特定の意味を持つコードとフィールド定義を使用する。
【生理】生理検査結果照会メッセージにおいて照会条件として検査ステータスを指定したい場合
は”CM”(検査終了)固定とする。

QRF-6 Which Date/Time Qualifier 対象日時修飾子 (ID) 00042
定義： このフィールドは、QRF-2－対象データ開始日時と QRF-3－対象データ終了日時で参照される日付のタイプを指定する。取りうる値については「HL7 表 0156 - Which Date/Time Qualifier 対象
日時修飾子」を参照。

© JAHIS 2022

82

HL7表 0156 – Which Date/Time Qualifier 対象日時修飾子
Value
ANY
COL
ORD
RCT
REP
SCHED

Description
Any date/time within a range 範囲内の任意の日時
Collection date/time, equivalent to film or sample collection date/time
収集日時。フィルムまたはサンプル収集日時と同等
Order date/time オーダ日時
Specimen receipt date/time, receipt of specimen in filling ancillary (Lab)取り消し日時。検体受領日時、臨床検査部門での検体の受領
Report date/time, report date/time at filing ancillary (i.e., Lab)
結果報告日時。臨床検査部門での報告日時
Schedule date/time 予定日時

Comment

QRF-7 Which Date/Time Status Qualifier 対象日時状態修飾子 (ID) 00043
定義： このフィールドは、QRF-2－対象データ開始日時および QRF-3 対象データ終了日時により定義された日付範囲で選択した対象日時の状態を示す。取りうる値については「HL7 表 0157 - Whichdate/time status qualifier 対象日時状態修飾子」を参照。
HL7表 0157 – Which date/time status qualifier 対象日時状態修飾子
Value
ANY
CFN
COR
FIN
PRE
REP

Description

Comment

任意の状態
現在の最終値、最終又は修正の修正のみ（修正最終値を除く）
最終のみ（修正を除く）
予備的報告完了日時QRF-8 Date/Time Selection Qualifier 日時選択修飾子 (ID) 00044
定義： このフィールドはその日時範囲で特定のタイプの値が指定できる。取りうる値については「HL7 表 0158– Date/Time Selection Qualifier 日付選択修飾子」を参照。
HL7表 0158 – Date/Time Selection Qualifier 日時選択修飾子
Value
1ST
ALL
LST
REV

Description
First value within range 範囲内の最初の値
All values within the range 範囲内のすべての値
Last value within the range 範囲内の最終値
All values within the range returned in reverse chronological order (This is the default if
not otherwise specified.) 範囲内のすべての値であって、日時の逆順に返されたもの（別途指示がない限りこれがデフォルトである）

Comment

QRF-9 When Quantity/Timing Qualifier 量/タイミング修飾子 (TQ) 00694
成分：<quantity (CQ)> ^ <interval (CM)> ^ <duration> ^ <start date/time (TS)> ^ <end date/time(TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <ordersequencing>
副成分 for Quantity (CQ): <Quantity (NM)> & <Units (CE)>
副成分 for Interval (RI): <Repeat Pattern (IS)> & <Explicit Time Interval (ST)>
副成分 for Start Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for End Date/Time (TS): <Time (DTM)> & <DEPRECATED-Degree of Precision (ID)>
副成分 for Order Sequencing (OSD): <Sequence/Results Flag (ID)> & <Placer Order Number:
Entity Identifier (ST)> & <Placer Order Number: Namespace ID (IS)> & <Filler Order
Number: Entity Identifier (ST)> & <Filler Order Number: Namespace ID (IS)> & <Sequence
Condition Value (ST)> & <Maximum Number of Repeats (NM)> & <Placer Order Number:
Universal ID (ST)> & <Placer Order Number: Universal ID Type (ID)> & <Filler Order
Number: Universal ID (ST)> & <Filler Order Number: Universal ID Type (ID)>
副成分 for Occurrence Duration (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System(ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding
System (ID)>

定義： このフィールドは、照会への複数の応答を絞り込むための日時の範囲を指定する。

© JAHIS 202283

定義の補足として、これからの実装では「QRF-2－対象データ開始日時」および「QRF-3－対象デー
タ終了日時」を使用不可とするべきである。
注記：このフィールドはデータ型 TQ であり、HL7 V2.5 で非推奨となった。Quantity 成分(第 1 成分)の実装についての情報は、HL7 V2.5 2.A.81 節を参照のこと。

QRF-10 Search Confidence Threshold サーチ範囲 (NM) 01442
定義： このフィールドには、最小しきい値の一致を確立するために使用される数値が含まる。この値は、検索の「一致重み」がこの使用者定義値よりも低い患者のレコードを返さないように応答シス
テムに指示する。
例: |0.50| or |8.25|
このオプションのフィールドの 1 つの用途は、検索システムが患者/個人の検索で可能性のある一致を決定するために数値的なアルゴリズムを採用する患者検索トランザクションである。

© JAHIS 2022

84

7.16. RCP - Response Control Parameter Segment 応答制御パラメー
タセグメントJAHIS データ交換規約 共通編 Ver.1.3「７．関連セグメント詳細」を参照のこと。

© JAHIS 2022

85

7.17. TQ1 - Timing/Quantity Segment タイミング/数量セグメント
TQ1 セグメントは、オーダ管理やスケジューリングシステムなどで起きる、イベントとアクションの複雑なタイミングを指定するのに使用される。このセグメントは、サービスの量、頻度、優先度、及びタイミン
グを決定する。このセグメントの繰返しを許すことで、あるサービス要求（時間にこだわらず）での量、頻度、優先度を継続的に持たせることが可能になる。
以下に TQ1 が繰り返されるユースケースを示す。
a. 心筋酵素（直ちに）、後は毎 4 時間
b. ストレプトキナーゼ検査、1 回目（直ちに）の採血を行い、検査を実施（直ちに）、その後 4 時間毎に採血し、検査を実施（直ちに）。
c. ゲンタマイシン 100mg（すぐ）、80mg 毎 12 時間 2 回分（最初 1 回分 80mg）1 回分 100mg の後きっかり 12 時間後（2 回目のサービス要求かも）d. アクティバース 15mg ボーラス（直ちに）、次に 30 分間 50mg、次に 60 分間 35mg（2 回目のサー
ビス要求かも）e. 初めにイモディアム 4mg （2 カプセル)経口、次に 2mg (1 カプセル)各軟便（unformed stool）後、1 日あたり最大 16 mg。
f. 初日 Zithromax500mg（2 錠剤)経口、次に 250mg（1 カプセル）経口で 1 日 1 回を 5 日間（2 回目のサービス要求かも)g. 禁煙の処方薬Zyban（ブプロピオン Bupropion) 150mg 経口から開始、毎午前を3 日間、次に150mg
経口、1 日 2 回を 7 週から 12 週間に増量。
h. コルヒチン 1mg（2 錠)経口（すぐ）、次に 1 錠毎 1～2 時間、痛みが緩和するか、あるいは好ましくない副作用（下痢、胃腸障害)が出るまで。
（(2 回のサービス要求かも)i. 初日 doxycylcine100mg 経口、1 日 2 回、次に 100mg 経口、1 日 1 回。
j. スコポラミン、xxx mg 、術前 1 時間。相対時間= -1^hour 、優先度= P (術前)、あるいは代替繰返しパターン= P1H^Preop 、1 Hour before Surgery^99LocalCode、相対時間は空で優先度は P (術前)。
HL7属性表－TQ1－Timing/Quantity タイミング／数量
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14

LEN
4
20
540
20
20
20
26
26
250
250
250
10
20
10

DT
SI
CQ
RPT
TM
CQ
CQ
TS
TS
CWE
TX
TX
ID
CQ
NM

OPT
O
O
O
O
O
O
O
O
O
O
O
C
O
O

JAHIS
O
O
O
O
O
O
C*
O
O
O
O
C
O
O

RP/#

TBL #

Y
Y
Y

0335

Y

0485

0472

ELEMENT NAME
Set ID - TQ1 セットID – TQ1
Quantity 数量
Repeat Pattern 繰返しパターン
Explicit Time 明示的な時間
Relative Time and Units 相対的時間と単位
Service Duration サービス期間
Start Date/Time 開始日時
End Date/Time 終了日時
Priority 優先度
Condition Text 条件テキスト
Text Instruction テキスト指示
Conjunction 連結
Occurrence Duration発生期間
Total Occurrence's 発生総数

【生理】生理検査結果通知メッセージ（OBR-25=”F”）では、TQ1-7（開始日時）は値必須となるた
め、TQ1-7 の JAHIS 値を”C”とする。

TQ1 フィールド定義
TQ1-1 Set ID - TQ1 セット ID (SI)01627

定義：伝送された最初のタイミング指定に対してシーケンス番号は 12 番目のタイミング指定では 2、以下同様。

© JAHIS 2022

86

TQ1-2 Quantity 数量 (CQ) 01628
成分：<Quantity (NM)> ^ <Units (CE)>
副成分 for Units (CE):<Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> &<Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>

定義：このフィールドは、サービスが各々のサービス間隔で提供されるべき数量を指定する。例えば、2 つの血液培養を 4 時間毎に取得すべき場合、その量は２である。或いは、3 ユニットの血液の血液型が判別され、クロスマッチされる場合、量は 3 となる。このフィールドのデフォルト値は 1 である。
もし、複数のサービスが要求される場合、複数のサービス要求が発行され、各々のサービスに各自一
意な発行者／実施者番号を与えることを強く推奨する。

TQ1-3 Repeat Pattern 繰返しパターン

(RPT)

01629

成分：<Repeat Pattern Code (CWE)> ^ <Calendar Alignment (ID)> ^ <Phase Range Begin Value(NM)> ^ <Phase Range End Value (NM)> ^ <Period Quantity (NM)> ^ <Period Units (IS)> ^<Institution Specified Time (ID)> ^ <Event (ID)> ^ <Event Offset Quantity (NM)> ^ <Event
Offset Units (IS)> ^ <General Timing Specification (GTS)>
副成分 for Repeat Pattern Code (CWE): <Identifier (ST)> & <Text (ST)> & <Name of Coding
System (ID)> & <Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate
Coding System (ID)> & <Coding System Version ID (ST)> & <Alternate Coding System
Version ID (ST)> & <Original Text (ST)>

定義：その治療が実施されるべき繰返しの頻度。オーダエントリシステムで使用される頻度と SIG コ
ード表と類似している。
このフィールドは、より複雑な繰返しパターンを構築するために繰り返される。例えば、毎日就寝時
は、”|QD~HS|”と表現される。
数量タイミング指定がある期間の後、異なる繰返しパターンに変化しなければならない時、新しい
TQ1 セグメントが新しい繰返しパターンを示すために使用されなければならない。現行の TQ1 の終了日は現行のタイミング指定が終了する時を示し、次の TQ1 の開始日は新しいタイミング指定が開始する時を示すことに注意すること。TQ1-12 の結合フィールドが次の TQ1 セグメントが連続して或いは並行して実行されるかを決定する。
使用者定義表 0335 -Repeat Pattern 繰り返しパターン
Value
Q＜整数＞S
Q＜整数＞>M
Q＜整数＞H
Q＜整数＞D
Q＜整数＞W
Q＜整数＞L
Q＜整数＞J＜日番号
＞

BID
TID
QID
xID
QAM
QSHIFT
QOD
QHS
QPM
C
U <spec>
U <指定>
PRN
PRNxxxOnce
食事に関連したタイミング© JAHIS 2022

Description＜整数＞秒ごと＜整数＞分ごと＜整数＞時間ごと＜整数＞日ごと＜整数＞週ごと＜整数＞月（月周期）ごと
週の特定の曜日に繰り返す

Comments

日に 2 回、施設で定められた時刻
日に 3 回、施設で定められた時刻
日に 4 回、施設で定められた時刻
日に X 回、施設で定められた時刻で、X は
数字の 5 より大きい
朝の施設で決められた時間に
8 時間の 3 回のシフトを 1 回ずつ施設で決められた時間に1 日おきに
毎日就寝時間の前に夕の施設で決められて時間にサービスは開始時刻から終了時刻まで連続的に提供される
将来の使用のため、＜指定＞は UNIX のcron 仕様で定義された繰り返しの指定
必要に応じてxxx はある繰り返しコード
一回のみ＜タイミング＞C (“cum”)＜食事＞

87

フランス語の Jour（日）より。＜整数＞がないとき繰り返
し頻度は 1 と見なされる。＜日番号＞は 1=月曜日から 7=日曜日までである。したがって、Q2J2 は 2 週に 1 度の火曜日
ごととなり；Q1J6 は毎日曜日となる。
（例、9AM-4PM）（例、9AM-4PM-9PM）（例、9AM-11AM-4PM-9PM）（例、5ID=日に 5 回； 8ID=日に 8 回）

（Q2D と同じ）（例、PRNQ6H）；頻度の間隔で必要に応じてこれもこの成分が null の時のデフォルト

ValueA
P
I
M
D
V

Description
Ante（前）Post（後）Inter（間）Cibus Matutinus 〈朝食〉Cibus Diurnus （昼食）
Cibus Vespertinus （夕食）

TQ1-4 Explicit Time 明示的な時間

Comments（例、前後の食事の間、夕食と終身の間）

(TM)

01630

定義：このフィールドは TQ1-3 のコードによって参照された実際の時間を明示的にリストする。このフィールドは、実際の実施時間が施設内でまちまちであるケースで TQ1-3 を明確化するために使用される。仮にサービスの時間が 1 日よりももっと長い期間を要求する場合、このフィールドはサービス要求があった各々の日に同じ実施時間が発生する場合にのみ実行が可能となる。仮にサービス要求の実際の開始時間（TQ1-7 によって与えられる）が最初の明示的時間よりも後である場合、開始時間後の最初の明示的時間に最初の実施が行われる。患者が明示的時間の異なる組合せを持つ場所に移動したケースでは、既存のサービス要求は、変更された明示的時間を示す新しい数量／タイミングセグメ
ントによって更新される。
使用上の注意：このフィールドは、TQ1-3 繰返しパターンが存在しない場合には値を持たない。

TQ1-5 Relative Time and Units 相対的時間と単位

(CQ)

01631

成分：<Quantity (NM)> ^ <Units (CE)>
副成分 for Units (CE):<Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> &<Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>

定義：このフィールドはサービス要求或いはボトル記録のためのスケジュールの間隔を定義するために使用される。仮にこのフィールドが値を持つ場合、TQ1-4 明示的な時間間隔フィールドの値をオー
バーライドする。CQ データ型の単位成分は、時間単位に制約される。
例:
TQ1|1|1|Q1H||60^min&&ANS+ - Q1H はサービス間隔 60 分ごとと定義される
TQ1|1|1|Q6H||6^hr&&ANS+ - Q6H はサービス間隔 6 時間ごとと定義される
TQ1|1|1|QD||1^d&&ANS+ - QD はサービス間隔 1 日ごとと定義される

TQ1-6 Service Duration サービス期間

(CQ)

01632

成分：<Quantity (NM)> ^ <Units (CE)>
副成分 for Units (CE): <Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> &<Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>

定義：このフィールドは、サービスが要求される期間を含む。このフィールドの数量成分は、ポジテ
ィブで、ゼロでない数字でなければならない。このフィールドの単位部分は、時間の単位に制約される。
例：ワールプール（whirlpool 渦流浴）を 3 日間に 1 日 3 回 20 分間。3 日間はサービス期間。
TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<CR>

TQ1-7 Start Date/Time 開始日時

(TS)

01633

成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：このフィールドは、サービスを開始すべき最早日時を示す場合に、要求者によって指定される。
しかしながら、多くの場合、開始日時は暗黙的に指定されるかサービス要求レコード（例えば、緊急-STAT）によって定義される。これらの場合、このフィールドは空である。 しかしながら実施サービ
スでは、サービス要求を受け取った後にこのフィールドに値を記録し、実施サービスの内部使用のため、開始日時を基に終了時間を計算することがよくある。
【生理】生理検査結果通知メッセージ（OBR-25="F"）の場合、TQ1-7（開始日時）を値必須とする。

TQ1-8 End Date/Time 終了日時 (TS)01634

成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義：サービス要求者によって指定される場合、このフィールドはサービスが実行されるべき最遅日時を含む。仮に指定された時間までにサービスが実行されなかった場合、そのサービスは全く実行さ© JAHIS 202288

れるべきではない。要求者はいつもこの値を記入するとは限らず、実施サービスが受け取った指示と実際の開始時間を基に記入するかもしれない。終了日時の値にかかわらず、サービスは期間或いは終了日時によって指定された最早日時で停止されるべきである。

TQ1-9 Priority 優先度 (CWE)01635

成分：<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)>^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義：このフィールドは、要求の優先度を記述する。仮にこのフィールドがブランクならデフォルトは R である。推奨値に関しては、「使用者定義表 0485―拡張優先度コード」を参照のこと。
使用者定義表 0485 - Extended Priority Codes 拡張優先度コード
Value
S
A
R
P
C
T

Description
Stat 緊急
ASAP できるだけ早く
Routine ルーチン
Preop 術前Callback 返信
Timing critical タイミングが重要TS<integer>
TM<integer>
TH<integer>
TD<integer>
TW<integer>
TL<integer>
PRN

Comments
最も高い優先度
S の次の優先度
デフォルト

できるだけ要求時間に近づけることが重要な要求。例えば、抗菌レベ
ル
タイミングは<整数値＞秒以内であることが重要
タイミングは<整数値＞分以内であることが重要
タイミングは<整数値＞時間以内であることが重要
タイミングは<整数値＞日以内であることが重要
タイミングは<整数値＞週以内であることが重要
タイミングは<整数値＞月以内であることが重要

As needed 必要に応じてTQ1-10 Condition Text 条件テキスト (TX)01636

定義：これは薬が与えられる条件を記述するフリーテキストのフィールドである。例えば、疼痛時、
或いは血圧を 110 以下に保つこと。このフィールドの存在は、この薬がどのように、および／または、
いつ与えられるべきかを決定するために人間のレビューが必要であるということを意味すると捉えるべきである。

TQ1-11 Text Instruction テキスト指示

(TX)

01637

定義：このフィールドは、指示のフルテキスト版である。
（オプション）

TQ1-12 Conjunction 連結

(ID)

01638

定義：このフィールドは、2 番目の TQ1 セグメントが続くことを示す。可能な値に関しては「HL7
表 0472–TQ 連結 ID」を参照のこと。
HL7 表 0472 - TQ Conjunction ID
Value
S

Description
同期 (Synchronous)A

非同期 (Asynchronous)C

これは開始時間である(Actuation Time)

TQ連結ID

Comments
同期. 今回の指定の後に次の指定を行う(TQ1-7－開始日時、および TQ1-8－終了日時により制限を受けなければ）。 “S”指定は、最初のタイミング･シーケンスの後に 2 番
目のタイミング･シーケンスが続くことを示す。例えば、最初の 1 時間は 15 分ごとに血圧を測定し、次の日には 2 時間ごとに血圧を測定するよう依頼する。
今回の指定と並行して次の指定を行う(TQ1-7－開始日時、および TQ1-8－終了日時により制限を受けなければ）。連結“A”により、投薬時などに散見される、2 つの指示の並行指定が可能になる。例えば、月曜、水曜、金曜にプレドニゾン 1 錠、火曜、木曜、土曜、日曜には 1／2 錠。
このコードの後にはサービスの終了時間が続く。このコードにより、サービスを起動すべき（採血など）時間･優先度から、サービスを終了すべき（結果報告など）時間･優先度が区別できるようになる。

連続したサービスあるいは周期的なサービスの場合、サービスを実際に停止するポイントは、TQ1-8 終了日時及び TQ1-6 継続時間の、どちらかより早い停止時間を示すフィールドにより決定される。通常、
この 2 つのフィールドのうち 1 つだけが存在する。 条件規則：TQ1 セグメントがメッセージ内で繰り返される場合、このフィールドには次に続く TQ1 セグメントの順序を示す適切な連結コードを指定すべきである。

© JAHIS 2022

89

TQ1-13 Occurrence Duration 発生期間

(CQ)

01639

成分：<Quantity (NM)> ^ <Units (CE)>
副成分 for Units (CE):<Identifier (ST)> & <Text (ST)> & <Name of Coding System (ID)> &<Alternate Identifier (ST)> & <Alternate Text (ST)> & <Name of Alternate Coding System(ID)>

定義：このフィールドはサービスの単独の実行についての期間を含んでいる。このフィールドの数量
成分は、値を持つ時はポジティブかつゼロでない数字でなければならない。単位成分は、時間の単位に制約される。例えば、ワールプール（whirlpool 渦流浴）を 3 日間、1 日 20 分間を 3 回。20 分が発
生時間である。
TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>

TQ1-14 Total Occurrence's 発生総数

(NM)

01640

定義：このフィールドは、サービス要求の結果であるべきサービスの発生総数を含む。仮に終了日時(TQ1-8)と発生総数の両方が値を持ち、その発生数が終了日時を越えて延びる場合は、終了日時を優先する。その他の場合は発生数を優先する。
例：ワールプール（whirlpool 渦流浴）を 3 日間、1 日 20 分間を 3 回。総発生数が 9 回。
TQ1|1||TID|||3^d&&ANS+||||||20^min&&ANS+|9<cr>© JAHIS 202290

付録‐１．生理検査データ交換規約メッセージの例
１．各ワークフロー（ａ）基本ワークフロー（検査室での運用を想定）
本ケースは、オンライン接続されたオーダ管理機能を有するモダリティで検査を実施する場合を想定した
ワークフローである。
検査依頼は事前にLISが受信し、モダリティはLISに対象患者のオーダ情報を参照し、検査後はオーダ情報を添えて検査結果を LIS に送信する。検査終了時、モダリティは検査終了を LIS に通知
し、LIS は事前に決定したメッセージを使用して HIS に対して検査終了を通知する。

HIS(病院情報システム)

LIS(生理検査情報システム)

Modality(オーダ管理有)① 生理検査依頼

opt② 患者情報更新[患者属性更新時]③ 検査ステータス通知(患者到着)④ 生理検査依頼照会⑤ 検査ステータス通知(検査中)
loop⑥ 生理検査結果通知[検査結果数]⑦ データ保存確認⑧ 検査ステータス通知 (検査終了)

alt[検査ステータス通知][結果通知]⑨ 検査ステータス通知 (検査終了)⑩ 生理検査結果通知

注記：本シーケンス図は、UML2.5 に則して記述している。記号の意味は、opt：オプション、loop：繰り返し、alt：選択 である。
（以下、同様）© JAHIS 202291

① 生理検査依頼：
生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
② 患者情報更新：
検査実施前に患者属性情報が変更になる等した場合（例：患者が外来から入院等）、患者情報更新がHIS から LIS へ送信される。
③ 検査ステータス通知（患者到着）：
患者が検査室受付に到着後、検査ステータス通知（患者到着）を LIS から HIS へ通知する。
④ 生理検査依頼照会：
検査実施時にモダリティ（心電計）より LIS へ検査予定日とステータスをキーに生理検査依頼照会を行う。
⑤ 検査ステータス通知（検査中）：
オーダ情報照会後、検査ステータス通知（検査中）をモダリティ（心電計）から LIS へ通知する。
⑥ 生理検査結果通知：
心電図検査を実施し、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
⑦ データ保存確認：
LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）からLIS へ送信する。
（エラーの場合は、⑥生理検査結果通知に戻る。
）※ 運動負荷心電図検査など、検査結果を複数回送信する必要がある場合は、検査結果数分⑥と⑦を繰り返し実施する。
⑧ 検査ステータス通知（検査終了）：
検査ステータス通知（検査終了）をモダリティ（心電計）から LIS へ通知する。
⑨ 検査ステータス通知（検査終了）：
検査ステータス通知（検査終了）を LIS から HIS へ通知する。
⑩ 生理検査結果通知：
検査終了時に⑨の代わりに検査結果を生理検査結果通知にて LIS から HIS へ送信してもよい。
（検査結果が複数存在する場合はまとめて送信する。
）© JAHIS 2022

92

（ｂ）基本ワークフロー（病棟等での出張検査（ポータブル検査）を想定）
本ケースでは、オーダ管理機能を有するモダリティをネットワークから切り離して（オフライン）検査を実施する場合を想定したワークフローである。検査依頼は事前に LIS が受信するが、モダリティは LIS から
当日実施予定のオーダ情報をまとめて参照、ダウンロードし、病棟等でオフラインでの検査を実施する。検
査終了後、検査室に戻った後にオーダ情報を添えて検査結果を LIS にまとめて送信する。検査終了時、LISは事前に決定したメッセージを使用して HIS に対して検査終了を通知する。
HIS(病院情報システム)

LIS(生理検査情報システム)

Modality(オーダ管理有)① 生理検査依頼

loop② 生理検査依頼照会[オーダ数]

検査実施 &
検査結果保存loop[オーダ数]

loop[検査結果数]③ 生理検査結果通知④ データ保存確認

alt⑤ 検査ステータス通知 (検査終了)[検査ステータス通知][結果通知]⑥ 生理検査結果通知① 生理検査依頼：
オーダ発行の都度、生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
② 生理検査依頼照会：
モダリティ（心電計）より LIS へ検査予定日をキーに生理検査依頼照会を行い、検査予定のオーダ情報をモダリティ（心電計）に保存する。検査予定のオーダ情報が複数存在する場合は、②生理検査依
頼照会を繰り返しても良い。
※ モダリティ（心電計）をネットワークから切り離して心電図検査を実施し、検査結果をモダリティ（心電計）に保存する。
（検査予定のオーダが複数存在する場合は、都度、モダリティ（心電計）を移動して検査を実施する。
）③ 生理検査結果通知：
モダリティ（心電計）をネットワークに接続し、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
④ データ保存確認：
LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）からLIS へ送信する。
（エラーの場合は、③生理検査結果通知に戻る。
）© JAHIS 202293

※ 検査結果を複数回送信する必要がある場合、検査結果数分③～④を繰り返し実施する。
⑤ 検査ステータス通知（検査終了）：
実施したオーダに対して検査ステータス通知（検査終了）を LIS から HIS へ通知する。
⑥ 生理検査結果通知：
検査終了時に⑤の代わりに検査結果を生理検査結果通知にて LIS から HIS へ送信してもよい。
（検査結果が複数存在する場合は、まとめて送信する。
）※ 発行されたオーダが複数存在する場合は、オーダ数分③～⑥を繰り返し実施する。

（ｃ）オーダ管理機能の無いモダリティ場合（患者情報のみの連携を想定）
本ケースでは、オーダ管理機能が無く患者属性のみ連携可能なモダリティで検査を実施する場合を想定したワークフローである。検査依頼は事前に LIS が受信し、モダリティは LIS にオーダ情報を照会せず、単に患者 ID から患者属性情報を照会する。検査終了後、患者属性情報を添えて検査結果を LIS に送信する。LIS
は検査結果とオーダ情報の紐づけを実施し、事前に決定したメッセージを使用して HIS に対して検査終了を
通知する。
HIS
(病院情報システム)

LIS(生理検査情報システム)

Modality(オーダ管理無)① 生理検査依頼② 患者情報照会

loop[検査結果数]③ 生理検査結果通知④ データ保存確認

検査結果とオーダ
情報を紐づけalt⑤ 検査ステータス通知 (検査終了)[検査ステータス通知][結果通知]⑥ 生理検査結果通知① 生理検査依頼：
生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
② 患者情報照会：
モダリティ（心電計）より LIS へ患者 ID をキーに患者情報照会を行う。
③ 生理検査結果通知：
患者情報照会後、心電図検査を実施し、生理検査結果通知にて検査結果をモダリティ（心電計）からLIS へ送信する。

© JAHIS 2022

94

④ データ保存確認：
LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）からLIS へ送信する。
（エラーの場合は、③生理検査結果通知に戻る。
）※ 運動負荷心電図検査など、検査結果を複数回送信する必要がある場合、検査結果数分③と④を繰り返し実施する。
⑤ 検査ステータス通知（検査終了）：
LIS にて検査結果とオーダ情報を紐づけ、検査ステータス通知（検査終了）を LIS から HIS へ通知する。
⑥ 生理検査結果通知：
検査終了時に⑤の代わりに検査結果を生理検査結果通知にて LIS から HIS へ送信してもよい。
（検査結果が複数存在する場合は、まとめて送信する。
）（ｄ）オーダ管理機能の無いモダリティの場合（患者情報連携無しを想定）
本ケースでは、LIS とオーダ情報や患者属性情報の連携機能の無いモダリティで検査を実施する場合を想定したワークフローである。検査依頼は事前に LIS が受信し、モダリティに患者属性情報を入力して検査を実施する。検査終了後、検査結果を LIS に送信する。LIS は検査結果とオーダ情報の紐づけを実施し、事前に決定したメッセージを使用して HIS に対して検査終了を通知する。
HIS(病院情報システム)

LIS(生理検査情報システム)

Modality(患者情報取扱無)① 生理検査依頼
患者ID入力loop[検査結果数]② 生理検査結果通知③ データ保存確認

検査結果とオーダ
情報を紐づけalt④ 検査ステータス通知 (検査終了)[検査ステータス通知][結果通知]⑤ 生理検査結果通知① 生理検査依頼：
生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
② 生理検査結果通知：
患者が検査室に入室後、モダリティ（心電計）に患者 ID を入力して心電図検査を実施する。検査終了後、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
③ データ保存確認：
LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から© JAHIS 2022

95

LIS へ送信する。
（エラーの場合は、②生理検査結果通知に戻る。
）※ 運動負荷心電図検査など、検査結果を複数回送信する必要がある場合、検査結果数分②と③を繰り返し実施する。
④ 検査ステータス通知（検査終了）：
LIS にて検査結果とオーダ情報を紐づけ、検査ステータス通知（検査終了）を LIS から HIS へ通知する。
⑤ 生理検査結果通知：
検査終了時に④の代わりに検査結果を生理検査結果通知にて LIS から HIS へ送信してもよい。
（検査結果が複数存在する場合は、まとめて送信する。
）（ｅ）救急時などオーダが発行される前に検査を実施する場合
本ケースでは、救急時など緊急検査を実施する際、HIS からの検査オーダが発行される前にモダリティで検査を実施する場合を想定したワークフローである。患者が救急外来、又は検査室等に入室後、モダリティに患者 ID（仮患者 ID の場合あり）を入力して検査を実施し、検査終了後、検査結果を LIS に送信する。検査実施後に事後オーダを発行し、HIS から LIS に通知する。LIS は検査結果とオーダ情報の紐づけを実施して事前に決定したメッセージを使用して HIS に対して検査終了を通知する。患者 ID に仮患者 ID を使用した場合、正規の患者属性情報を LIS に通知する。
HIS(病院情報システム)

LIS(生理検査情報システム)

Modality(患者情報取得無)患者ID入力
① 生理検査結果通知② データ保存確認③ 生理検査依頼

検査結果とオーダ
情報を紐づけalt④ 検査ステータス通知 (検査終了)[検査ステータス通知][結果通知]

opt[患者情報更新時]⑤ 生理検査結果通知⑥ 患者情報更新① 生理検査結果通知：
患者が救急外来、又は検査室等に入室後、モダリティ（心電計）に患者 ID（仮患者 ID の場合あり）
を入力して心電図検査を実施する。検査終了後、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
② データ保存確認：
LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から© JAHIS 2022

96

LIS へ送信する。
（エラーの場合は、①生理検査結果通知に戻る。
）③ 生理検査依頼：
事後オーダとして患者 ID に患者情報とオーダ情報を添えて生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
④ 検査ステータス通知（検査終了）：
LIS にて検査結果とオーダ情報を紐づけ、検査ステータス通知（検査終了）を LIS から HIS へ通知する。
⑤ 生理検査結果通知：
検査終了時に④の代わりに検査結果を生理検査結果通知にて LIS から HIS へ送信してもよい。
（検査結果が複数存在する場合は、まとめて送信する。
）⑥ 患者情報更新：
患者 ID に仮患者 ID を使用した場合、LIS で管理している患者情報を更新するために、患者名や生年月日、性別等の患者属性情報を患者情報更新にて HIS から LIS へ送信してもよい。

（ｆ）結果照会
本ケースでは、上記ケース全てにおいて、HIS が LIS に保存された検査結果を取得することを想定したワークフローである。検査データの実体を取得する場合と、URI を取得する場合があるが、本例では HIS が
FTP にて実体を取得するケースになる。
HIS(病院情報システム)

LIS(生理検査情報システム)① 生理検査結果照会① 生理検査結果照会：
HIS が LIS へ生理検査結果照会を行う。

© JAHIS 2022

97

２．メッセージ使用例
規約の解釈相違によりメッセージ送受信トラブルを避けるために、前節で記述したフロー例にもとづき、
生理検査メッセージがどのように構築されるかを示す。
（a-①）: 生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
送信メッセージ（HIS→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

患者区分

外来患者

所属科

01

担当医

中田隆

依頼科

01

オーダ制御

新規オーダ

依頼者オーダ番号202008210089

入力者

中田隆

入力場所コード

01

検査回数

1

優先度

通常

検査名

標準１２誘導心電図

MSH|^~¥&|HIS||LIS||20200821114523||OMG^O19^OMG_O19|12345678901234500002|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
PV1||O|01^^^^^C||||112233^中田^隆^^^^^^^L^^^^^I|||01<CR>
ORC|NW|202008210089|||SC||||20200821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||202008211030||R<CR>
OBR||202008210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O<CR>
ORC|PA|202008210089|||SC||||20200821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||202008211030||R<CR>
OBR||202008210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O<CR>
OBX|1|NM|9M021000000000001^体重^JC10||65.0|kg|||||F<CR>
ORC|CH|202008210090|||SC|||202008210089|20200821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||202008211030||R<CR>
OBR||202008210090||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O||||202008210089<CR><EOM>© JAHIS 2022

98

■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

HIS

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821114523

送信システムがメッセージを作成
した日時

9

メッセージ型OMG^O19^OMG_O19

10

メッセージ制御 ID

12345678901234500002

必須フィールド
必須フィールド
メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード
姓名~フリガナ~ローマ字

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000■ PV1 セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

2

患者区分

推奨値 「使用者定義表 004 - 患者

O区分」
入院の場合、<病棟コード>^<病室コ3

患者に割り当てられた場所

ード>^<ベッド番号>^^^N

01^^^^^C

外来の場合、<診療科コード>^^^^^C

7

担当医112233^中田^隆^^^^^^^L^^^^^I

10

診療部門

01

© JAHIS 2022

推奨値 「使用者定義表 0069 - 診療部門」

99

■ ORC セグメント(1)SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

NW

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210089

る文字列
5

オーダ状態

「HL7 表 0038 - オーダ状態」

SC

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115000

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

12

オーダ発行者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド
要求を作成することに責任がある人（依頼する医師など）の識別情報
要求を入力した人がオーダを入力

13

入力場所

01^^^^^C17

入力組織01^内科^HL70069

29

オーダタイプO^外来患者オーダ^HL70482

した時にいた物理的な場所
依頼科
推奨値 「HL7 表 0482 – オーダタ
イプ」

■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

202008211030

9

優先度

R

備考

推奨値 「使用者定義表 0485 - 拡張
優先度コード」■ OBR セグメント(1)SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

4

検査項目群 ID

9A^循環器機能検査^JC10

備考

必須フィールドORC-2 と同一
必須フィールド
要求された試験／検査／検査セットの識別子コード16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

O

「HL7 表 0123 - 結果状態」© JAHIS 2022

100

■ ORC セグメント(2)SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

PA

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210089

る文字列
5

オーダ状態

「HL7 表 0038 - オーダ状態」

SC

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115000

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

12

オーダ発行者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド
要求を作成することに責任がある人（依頼する医師など）の識別情報
要求を入力した人がオーダを入力

13

入力場所

01^^^^^C17

入力組織01^内科^HL70069

29

オーダタイプO^外来患者オーダ^HL70482

した時にいた物理的な場所
依頼科
推奨値 「HL7 表 0482 – オーダタ
イプ」

■ TQ1 セグメント(2)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

202008211030

9

優先度

R

備考

推奨値 「使用者定義表 0485 - 拡張
優先度コード」■ OBR セグメント(2)SEQ

値

ELEMENT NAME

備考
上位 ORC に対する通番。初期値 1、1

セット ID – 検査要求

増分 1。必要に応じ同一 ORC セグ

2

メントに対して 1 から付番される通し番号（オプション）。

2

依頼者オーダ番号

必須フィールド

202008210089

ORC-2 と同一
必須フィールド

4

検査項目群 ID

9A^循環器機能検査^JC10

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

O

「HL7 表 0123 - 結果状態」

要求された試験／検査／検査セットの識別子コード© JAHIS 2022

101

■ OBX セグメント(2-1)
SEQ

値

ELEMENT NAME

備考
同一の OBR セグメントに対し 1 か1

OBX セット ID

ら付番される OBX のシーケンス番

1号
必須フィールド

2

値型

NM

3

検査項目

9M021000000000001^体重^JC10

5

検査結果値

65.0

6

単位

kg

「HL7 表 0125 - 値型」
必須フィールド

必須フィールド
11

検査結果状態「HL7 表 0085 - 検査結果状態コ

F

ード解釈」

■ ORC セグメント(3)SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

CH

ド」
必須フィールド
第 1 成分は、個々のオーダを識別す

2

依頼者オーダ番号202008210090

5

オーダ状態

SC

「HL7 表 0038 - オーダ状態」

8

親202008210089

親オーダの ORC-2 と同一る文字列

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115000

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド12

オーダ発行者

112233^中田^隆^^^^^^^L^^^^^I

要求を作成することに責任がある人（依頼する医師など）の識別情報
要求を入力した人がオーダを入力

13

入力場所

01^^^^^C17

入力組織01^内科^HL70069

29

オーダタイプO^外来患者オーダ^HL70482

した時にいた物理的な場所
依頼科
推奨値 「HL7 表 0482 – オーダタ
イプ」

■ TQ1 セグメント(3)SEQ

値

ELEMENT NAME

2

数量

1

9

優先度

R

© JAHIS 2022

備考
推奨値 「使用者定義表 0485 - 拡張
優先度コード」102

■ OBR セグメント(3)SEQ

値

ELEMENT NAME

備考
上位 ORC に対する通番。初期値 1、1

セット ID – 検査要求

増分 1。必要に応じ同一 ORC セグ

3

メントに対して 1 から付番される通し番号（オプション）。
必須フィールド

2

依頼者オーダ番号202008210090

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10

ORC-2 と同一
必須フィールド
要求された試験／検査／検査セットの識別子コード16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

O

「HL7 表 0123 - 結果状態」

29

親番号

202008210089

ORC-8 と同一応答メッセージ（LIS→HIS）
MSH|^~¥&|LIS||HIS||20200821114328||ORG^O20^ORG_O20|99999999991234500002|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500002<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

HIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821114328

9

メッセージ型

ORG^O20^ORG_O20

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500002

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 2022

103

■ MSA セグメント
SEQ
1

値

ELEMENT NAME
確認応答コード

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

2

メッセージ制御 ID

12345678901234500002

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 2022104

（a-②）: 検査実施前に患者が外来から入院に変更になった時に患者情報更新がHISからLISへ送信される。
送信メッセージ(HIS→LIS)
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

患者区分

入院患者

所属科

01

担当医

中田隆

依頼科

01

病棟

4E

病室

136

ベッド番号

B

MSH|^~¥&|HIS||LIS||20200821114323||ADT^A08^ADT_A01|12345678901234500001|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
EVN||20200821114323||01<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
PV1||I|4E^136^B^^^N||||112233^中田^隆^^^^^^^L^^^^^I|||01<CR><EOM>■ MSH セグメントSEQ

ELEMENT NAME

値

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

HIS

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821114323

9

メッセージ型

ADT^A08^ADT_A01

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500001

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 2022

105

■ EVN セグメントSEQ

ELEMENT NAME

値

備考
必須フィールド2

イベント伝送日時

20200821114323

トランザクションが入力されたシ
ステムの日時4

イベント理由コード

6

イベント発生日時

推奨値 「使用者定義表 0062 - イベ

01

ント理由」
イベントが実際に起こった日時■ PID セグメント
SEQ
3

ELEMENT NAME
患者 ID リスト値
1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード
姓名~フリガナ~ローマ字

7

生年月日

195012148

性別

M

YYYYMMDD

11

患者住所

東京都港区鹿ノ門 6 丁目 1 番 1 号

13

電話番号 – 自宅^PRN^PH^^^^^^^^^03-0000-0000

第 8 成分のみ使用■ PV1 セグメントSEQ

ELEMENT NAME

値

備考
必須フィールド

2

患者区分

推奨値 「使用者定義表 004 - 患者

I区分」
入院の場合、<病棟コード>^<病室コード>^<ベッド番号>^^^N

3

患者に割り当てられた場所

4E^136^B^^^N

7

担当医112233^中田^隆^^^^^^^L^^^^^I

10

診療部門

01

外来の場合、<診療科コード>^^^^^C
推奨値 「使用者定義表 0069 - 診療部門」

応答メッセージ（LIS→HIS）
MSH|^~¥&|LIS||HIS||20200821114325||ACK^A08^ACK|99999999991234500001|P|2.5||||||~ISO IR87||ISO2022-1994<CR>
MSA|AA|12345678901234500001<CR><EOM>■ MSH セグメントSEQ

ELEMENT NAME

値

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS© JAHIS 2022

ネットワーク全体で一意に識別可能であること106

SEQ

ELEMENT NAME

値

備考
ネットワーク全体で一意に識別可

5

受信アプリケーション

HIS

7

メッセージ日時

20200821114325

能であること必須フィールド
送信システムがメッセージを作成
した日時

9

メッセージ型

ACK^A08^ACK

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500001

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
確認応答コード

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

2

メッセージ制御 ID

12345678901234500001

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 2022107

（a-③）: 患者が検査室受付に到着後、検査ステータス通知（患者到着）を LIS から HIS へ通知する。
検査ステータス通知（患者到着）が、Modality→LIS→HIS という流れで処理する場合、MSH セグメン
トは各システムで再作成される。
送信メッセージ（LIS→HIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号202008210089

検査名

標準１２誘導心電図検査ステータス

受付(到着確認)

MSH|^~¥&|LIS||HIS||20200821115030||ORU^R01^ORU_R01|12345678901234500003|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
ORC|SC|202008210089|||IP||||20200821115020|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069<CR>
OBR|1|202008210089||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||I<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

HIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115030

9

メッセージ型

ORU^R01^ORU_R01

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500003

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 2022

108

■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード

5

患者氏名

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

姓名~フリガナ~ローマ字YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000■ ORC セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド1「HL7 表 0119 - オーダ制御コー

SC

オーダ制御

ド」
必須フィールド
2

第 1 成分は、個々のオーダを識別す

202008210089

依頼者オーダ番号

る文字列
5

オーダ状態

9

トランザクション日時「HL7 表 0038 - オーダ状態」

IP

必須フィールドORC-1 に反映される現在の処理を

20200821115020

始めるイベントの日時
10112233^中田^隆^^^^^^^L^^^^^I

入力者

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド

12112233^中田^隆^^^^^^^L^^^^^I

オーダ発行者

要求を作成することに責任がある人（依頼する医師など）の識別情報
要求を入力した人がオーダを入力し

13

入力場所

01^^^^^C17

入力組織01^内科^HL70069た時にいた物理的な場所
必須フィールドORC-10 で指定した人がオーダを入力した時に属している組織■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

備考
必須フィールドORC-2 と同一
必須フィールド

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10要求された試験／検査／検査セットの識別子コード16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

I

「HL7 表 0123 - 結果状態」© JAHIS 2022

109

応答メッセージ（HIS→LIS）
MSH|^~¥&|HIS||LIS||20200821115035||ACK^R01^ACK|99999999991234500003|P|2.5||||||~ISO IR87||ISO2022-1994<CR>
MSA|AA|12345678901234500003<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

HIS

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115035

送信システムがメッセージを作成
した日時

9

メッセージ型

10

メッセージ制御 ID

ACK^R01^ACK

必須フィールド
必須フィールド

99999999991234500003

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
確認応答コード

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

2

メッセージ制御 ID

12345678901234500003

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 2022110

（a-④）: 検査実施時にモダリティ（心電計）より LIS へ検査予定日とステータスをキーに生理検査依頼照会を行う。
送信メッセージ（Modality→LIS）
項目名
照会条件

項目値

備考

検査予定日＝2020/08/21

検査ステータス＝IP がセットされた場合、LIS は

検査ステータス＝SC(予定)

受付済レコードを返信するものとする。

MSH|^~¥&|Modality||LIS||20200821115200||QBP^ZS1^QBP_Q11|12345678901234500005|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QPD|ZS1^Order Query^JHSS0002|Q001|||||||20200821|20200821|SC|SCHED|ALL<CR>
RCP|I|99^RD|R^リアルタイム^HL70394<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115200

9

メッセージ型

QBP^ZS1^QBP_Q11

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500005

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS1^Order Query^JHSS0002

必須フィールド

2

照会タグ

Q001

応答と照会を突合する識別子

9

データ開始日時

20200821

検査予定日時（範囲開始）

10

データ終了日時

20200821

検査予定日時（範囲終了）

11

他の QRY 対象フィルタ

SC「HL7 表 0038 - オーダ状態」

12

対象日時修飾子

SCHED「HL7 表 0156 - 対象日時修飾子」

13

日時選択修飾子ALL「HL7 表 0158 - 日時選択修飾子」© JAHIS 2022

111

■ RCP セグメント
SEQ

値

ELEMENT NAME

備考

1

照会優先度

I

応答のためのタイムフレーム2

数量制限要求99^RD

受け入れられる応答の最大長

3

応答様式

R^リアルタイム^HL70394

応答メッセージのタイミングとグ
ルーピング

応答メッセージ（LIS→Modality）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

患者区分

入院患者

所属科

01

担当医

中田隆

依頼科

01

病棟

4E

病室

136

ベッド番号

B

オーダ制御

新規オーダ

依頼者オーダ番号202008210089

入力者

中田隆

入力場所コード

診療科 (01)

検査回数

1

検査日時

2020/08/21

優先度

通常

検査名

標準１２誘導心電図

MSH|^~¥&|LIS||Modality||20200821115230||RSP^ZS2^RSP_K11|99999999991234500005|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500005<CR>
QAK|Q001|OK|ZS1^Order Query^JHSS0002|1<CR>
QPD|ZS1^Order Query^JHSS0002|Q001||||||20200821|20200821|SC|SCHED|ALL<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
PV1|1|I|4E^136^B^^^N ||||112233^中田^隆^^^^^^^L^^^^^I|||01<CR>
ORC|NW|202008210089|||SC||||20200821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||20200821||R<CR>
OBR|1|202008210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O<CR>
ORC|PA|202008210089|||SC||||20200821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||20200821||R<CR>
OBR|2|202008210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O <CR>
OBX|1|NM|9M021000000000001^体重^JC10||65.0|kg|||||F<CR>
ORC|CH|202008210090|||SC|||202008210089|20200821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中© JAHIS 2022112

田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||20200821||R<CR>
OBR|3|202008210090||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O||||202008210089<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

9

メッセージ型

20200821115230

送信システムがメッセージを作成
した日時

RSP^ZS2^RSP_K11

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500005

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994

メッセージを一意に識別する番号
または他の識別子■ MSA セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

確認応答コードAA

2

メッセージ制御 ID

12345678901234500005「HL7 表 0008 - 応答コード」
必須フィールド
通知メッセージの MSH-10 をエコーバック■ QAK セグメント
SEQ

値

ELEMENT NAME

1

照会タグ

Q001

2

照会応答状態OK

3
4

メッセージ照会名
合致データトータル数© JAHIS 2022

備考
照会メッセージの QPD-2 と同一である必要がある「HL7 表 0208 - 照会応答状態」

ZS1^Order Query^JHSS0002
1113

照会メッセージの QPD-1 と同一である必要がある

■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS1^Order Query^JHSS0002

必須フィールド

2

照会タグ

Q001

応答と照会を突合する識別子

9

データ開始日時

20200821

検査予定日時（範囲開始）

10

データ終了日時

20200821

検査予定日時（範囲終了）

11

他の QRY 対象フィルタ12

対象日時修飾子

SCHED「HL7 表 0156 - 対象日時修飾子」

13

日時選択修飾子ALL「HL7 表 0158 - 日時選択修飾子」「HL7 表 0038 - オーダ状態」

SC■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード>
姓名~フリガナ~ローマ字

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000■ PV1 セグメント
SEQ
1

値

ELEMENT NAME
セット ID – PV1

備考

1
必須フィールド2

患者区分

推奨値「使用者定義表 004 - 患者区

I分」
入院の場合、<病棟コード>^<病室コ3

患者に割り当てられた場所

ード>^<ベッド番号>^^^N

4E^136^B^^^N

外来の場合、<所属科コード>^^^^^C

7

担当医112233^中田^隆^^^^^^^L^^^^^I

10

診療部門

01

© JAHIS 2022

推奨値 「使用者定義表 0069 - 診療
部門」

114

■ ORC セグメント(1)SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

NW

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210089

る文字列
5

オーダ状態

「HL7 表 0038 - オーダ状態」

SC

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115000

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

12

依頼者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド
要求を作成することに責任がある人（依頼する医師など）の識別情報

13

入力場所

要求を入力した人がオーダを入力

01^^^^^C

時にいた物理的な場所
必須フィールド17

入力組織01^内科^HL70069

ORC-10 で指定した人がオーダを入力した時に属している組織

29

オーダタイプO^外来患者オーダ^HL70482

推奨値 「HL7 表 0482 – オーダタ
イプ」

■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20200821

9

優先度

R

備考
検査予定日時推奨値 「使用者定義表 0485 - 拡張
優先度コード」■ OBR セグメント(1)SEQ

値

ELEMENT NAME

備考

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

4

検査項目群 ID

9A^循環器機能検査^JC10

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

O

「HL7 表 0038 -オーダ状態」© JAHIS 2022

必須フィールドORC-2 と同一

115

必須フィールド検査分類の識別子コード

■ ORC セグメント(2)SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

PA

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210089

る文字列
5

オーダ状態

「HL7 表 0038 - オーダ状態」

SC

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115000

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

12

依頼者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド
要求を作成することに責任がある人（依頼する医師など）の識別情報

13

入力場所

要求を入力した人がオーダを入力

01^^^^^C

時にいた物理的な場所
必須フィールド17

入力組織01^内科^HL70069

ORC-10 で指定した人がオーダを入力した時に属している組織

29

オーダタイプO^外来患者オーダ^HL70482

推奨値 「HL7 表 0482 – オーダタ
イプ」

■ TQ1 セグメント(2)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20200821

9

優先度

R

備考
検査予定日時推奨値 「使用者定義表 0485 - 拡張
優先度コード」■ OBR セグメント(2)SEQ

値

ELEMENT NAME

備考

1

セット ID – 検査要求

2

2

依頼者オーダ番号202008210089

4

検査項目群 ID

9A^循環器機能検査^JC10

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

O

「HL7 表 0123 - 結果状態」© JAHIS 2022

必須フィールドORC-2 と同一

116

必須フィールド検査分類の識別子コード

■ OBX セグメント(2-1)
SEQ

値

ELEMENT NAME

1

OBX セット ID

1

2

値型

NM

3

検査項目

9M021000000000001^体重^JC10

5

検査結果値

65.0

6

単位

kg

備考
必須フィールド「HL7 表 0125 - 値型」
必須フィールド

必須フィールド
11

検査結果状態「HL7 表 0085 - 検査結果状態コ

F

ード解釈」

■ ORC セグメント(3)SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

CH

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210090

る文字列
5

オーダ状態

SC

「HL7 表 0038 - オーダ状態」

8

親202008210089

親オーダの ORC-2 と同一

9

トランザクション日時

20200821115000

必須フィールドORC-1 に反映される現在の処理を始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド

12

依頼者

112233^中田^隆^^^^^^^L^^^^^I

要求を作成することに責任がある人（依頼する医師など）の識別情報

13

入力場所

要求を入力した人がオーダを入力

01^^^^^Cした時にいた物理的な場所
必須フィールド17

入力組織01^内科^HL70069

ORC-10 で指定した人がオーダを入力した時に属している組織

29

オーダタイプO^外来患者オーダ^HL70482

推奨値 「HL7 表 0482 – オーダタ
イプ」

■ TQ1 セグメント(3)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20200821

9

優先度

R

© JAHIS 2022

備考
検査予定日時推奨値 「使用者定義表 0485 - 拡張
優先度コード」117

■ OBR セグメント(3)SEQ

値

ELEMENT NAME

備考

1

セット ID – 検査要求

3

2

依頼者オーダ番号202008210090

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

O

「HL7 表 0038 - オーダ状態」

29

親番号

202008210089

ORC-8 と同一

© JAHIS 2022

必須フィールドORC-2 と同一

118

必須フィールド
検査種別の識別子コード

（a-⑤）: オーダ情報照会後、検査ステータス通知（検査中）をモダリティ（心電計）から LIS へ通知する。
検査ステータス通知（検査中）が、Modality→LIS→HIS という流れで処理する場合、MSH セグメント
は各システムで再作成される。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号202008210089

検査名

標準１２誘導心電図検査ステータス

検査中

MSH|^~¥&|Modality||LIS||20200821115135||ORU^R01^ORU_R01|12345678901234500004|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
ORC|SC|202008210089|||IP||||20200821115120|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069<CR>
OBR|1|202008210089||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||S<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115135

9

メッセージ型

ORU^R01^ORU_R01

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500004

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 2022

119

■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード>
姓名~フリガナ~ローマ字

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000■ ORC セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

SC

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210089

る文字列
5

オーダ状態

「HL7 表 0038 - オーダ状態」

IP

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115120

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド

12

依頼者

112233^中田^隆^^^^^^^L^^^^^I

要求を作成することに責任がある人（依頼する医師など）の識別情報

13

入力場所

要求を入力した人がオーダを入力

01^^^^^Cした時にいた物理的な場所
必須フィールド17

入力組織01^内科^HL70069

ORC-10 で指定した人がオーダを入力した時に属している組織■ OBR セグメント
SEQ

値

ELEMENT NAME

備考

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

S

「HL7 表 0123 - 結果状態」© JAHIS 2022

必須フィールドORC-2 と同一

120必須フィールド
検査種別の識別子コード

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20200821115140||ACK^R01^ACK|99999999991234500004|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500004<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115140

送信システムがメッセージを作成
した日時

9

メッセージ型

10

メッセージ制御 ID

ACK^R01^ACK

必須フィールド
必須フィールド

99999999991234500004

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
確認応答コード

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

2

メッセージ制御 ID

12345678901234500004

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 2022

121

（a-⑥）: 心電図検査を行い、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
生理検査結果通知が、Modality→LIS→HIS という流れで処理する場合、MSH セグメントは各システムで再作成される。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号202008210089

検査名

標準１２誘導心電図

検査日時2020/08/21 12:34:56

測定日時

2020/08/21 12:34:56

付帯情報データ（メッセージ参照）

MFER データ（メッセージ参照）

DataUID

0123420150102132532123

HL7 CDA R2

MSH|^~¥&|Modality||LIS||20200821115300||ORU^R01^ORU_R01|12345678901234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|202008210089||9A110^標準１２誘導心電図^JC10|||20200821123456|||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR>
TQ1||1|||||20200821123456<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥
HL7 CDA R2をBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub..¥X0D0A¥
MFERデータをBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||F|||20200821123456<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||0123420150102132532123||||||F|||20200821123456<CR><EOM>© JAHIS 2022

122

■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であること
ネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115300

送信システムがメッセージを作成した日時

9

メッセージ型

ORU^R01^ORU_R01

10

メッセージ制御 ID

12345678901234500006

必須フィールド
必須フィールド
メッセージを一意に識別する番号または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード>
姓名~フリガナ~ローマ字

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

備考
必須フィールド
必須フィールド

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10

7

検査日時

20200901123456

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

25

結果状態

F

要求された試験／検査／検査セットの識別子コード© JAHIS 2022

存在すれば必須「HL7 表 0123 - 結果状態」

123

■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20200821123456

備考
検査日時

■ OBX セグメント(1)SEQ

値

ELEMENT NAME

1

OBX セット ID

1

2

値型

ED

3

検査項目

MIME^MIMEPackage^JHSS0001

備考
必須フィールド「HL7 表 0125 - 値型」
必須フィールド^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed;boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type:application/x-hl7-cda-level-one+xml¥X0D0A¥

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZ
GluZz0idXRmLTgiPz4NCjw/eG1sLXN0eW
xlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy
ZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24g
5

検査結果値

eG1sbnM9InVybjpobDctb3JnOnYzIiB4bW
xuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥
X0D0A¥

必須フィールド
HL7 CDA R2 とMFER データをそれぞれ Base64 エンコードしたテキ
ストを MIME 形式でパッケージ化--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgR
UNHICAgICAgIBceTklIT04gS09IREVOXkVDR
1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALB
gH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUE
Y9MC4wNAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥

必須フィールド
11

検査結果状態「HL7 表 0085 - 検査結果状態コ

F

ード解釈」
14

検査日時

© JAHIS 2022

20200821123456

124

存在すれば必須

■ OBX セグメント(2)SEQ

値

ELEMENT NAME

備考

1

OBX セット ID

3

2

値型

ST

3

検査項目

DUID^DataUID^JHSS0001

必須フィールド

5

検査結果値0123420150102132532123

必須フィールド

必須フィールド「HL7 表 - 0125 値型」

必須フィールド「HL7 表 0085 - 検査結果状態コ11

検査結果状態

F

14

検査日時

202000811123456

ード解釈」
存在すれば必須

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20200821115310||ACK^R01^ACK|99999999991234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500006<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

9

メッセージ型

20200821115310

送信システムがメッセージを作成した日時

ACK^R01^ACK

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500006

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

確認応答コードAA

2

メッセージ制御 ID

12345678901234500006「HL7 表 0008 - 応答コード」
必須フィールド
通知メッセージの MSH-10 をエコ
ーバック© JAHIS 2022

125

（a-⑦）: LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から LIS へ送信する。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

DataUID = 0123420150102132532123

確認条件

MSH|^~¥&|Modality||LIS||20200821115500||QBP^ZS3^QBP_Q11|12345678901234500008|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QPD|ZS3^Storage Commitment^JHSS0002|Q002|0123420150102132532123<CR>
RCP|I|99^RD|R^リアルタイム^HL70394<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115500

9

メッセージ型

QBP^ZS3^QBP_Q11

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500008

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS3^Storage Commitment^JHSS0002

必須フィールド

2

照会タグ

Q002

応答と照会を突合する識別子

3

データ固有識別 ID

0123420150102132532123

検索条件■ RCP セグメント
SEQ

値

ELEMENT NAME

備考

1

照会優先度

I

応答のためのタイムフレーム2

数量制限要求99^RD

受け入れられる応答の最大長

3

応答様式

R^リアルタイム^HL70394© JAHIS 2022

126

応答メッセージのタイミングとグ
ルーピング

応答メッセージ（LIS→Modality）
項目名
データ保存確認

項目値

備考

成功

データ保存コミット

MSH|^~¥&|LIS||Modality||20200821115510||RSP^ZS4^RSP_K11|99999999991234500008|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500008<CR>
QAK|Q002|OK|ZS3^Storage Commitment^JHSS0002|1<CR>
QPD|ZS3^Storage Commitment^JHSS0002|Q002|0123420150102132532123<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115510

送信システムがメッセージを作成
した日時

9

メッセージ型

RSP^ZS4^RSP_K11

10

メッセージ制御 ID

99999999991234500008

必須フィールド
必須フィールド
メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
確認応答コード

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

2

メッセージ制御 ID

12345678901234500008

通知メッセージの MSH-10 をエコーバック■ QAK セグメント
SEQ

値

ELEMENT NAME

確認メッセージの QPD-2 と同一で

1

照会タグ

Q002

2

照会応答状態OK

3

メッセージ照会名

ZS3^Storage Commitment^JHSS0002

4

合致データトータル数

1© JAHIS 2022

備考
ある必要がある「HL7 表 0208 - 照会応答状態」

127

■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS3^Storage Commitment^JHSS0002

必須フィールド

2

照会タグ

Q002

応答と照会を突合する識別子

3

データ固有識別 ID

0123420150102132532123

検索条件（a-⑧）: 検査ステータス通知（検査終了）をモダリティ（心電計）から LIS へ通知する。
検査ステータス通知が、Modality→LIS→HIS という流れで処理する場合、MSH セグメントは各システ
ムで再作成される。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号201508210089

検査名

標準１２誘導心電図検査ステータス

検査終了

MSH|^~¥&|Modality||LIS||20200821115400||ORU^R01^ORU_R01|12345678901234500007|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
ORC|SC|202008210089|||CM||||20200821114325|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01^内科^HL70069<CR>
OBR|1|202008210089||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR><EOM>© JAHIS 2022

128

■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であること
ネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115400

送信システムがメッセージを作成した日時

9

メッセージ型

ORU^R01^ORU_R01

10

メッセージ制御 ID

12345678901234500007

必須フィールド
必須フィールド
メッセージを一意に識別する番号または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード>
姓名~フリガナ~ローマ字

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅© JAHIS 2022

YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000

129

■ ORC セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

オーダ制御「HL7 表 0119 - オーダ制御コー

SC

ド」
必須フィールド
2

依頼者オーダ番号

第 1 成分は、個々のオーダを識別す

202008210089

る文字列
5

オーダ状態

「HL7 表 0038 - オーダ状態」

CM

必須フィールド
9

トランザクション日時

ORC-1 に反映される現在の処理を

20200821115120

始めるイベントの日時
10

入力者

112233^中田^隆^^^^^^^L^^^^^I

12

依頼者

112233^中田^隆^^^^^^^L^^^^^I

要求をアプリケーションに実際に入力した人の識別情報
必須フィールド
要求を作成することに責任がある人（依頼する医師など）の識別情報

13

入力場所

要求を入力した人がオーダ入力した

01^^^^^C

時にいた物理的な場所
必須フィールド17

入力組織01^内科^HL70069

ORC-10 で指定した人がオーダを入力した時に属している組織■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

備考
必須フィールドORC-2 と同一
必須フィールド

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

F

「HL7 表 0123 - 結果状態」

要求された試験／検査／検査セットの識別子コード© JAHIS 2022

130

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20200821115410||ACK^R01^ACK|99999999991234500007|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500007<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

7

メッセージ日時

20200821115410

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド
送信システムがメッセージを作成
した日時

9

メッセージ型

ACK^R01^ACK

必須フィールド
必須フィールド

10

メッセージ制御 ID

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994

99999999991234500007

メッセージを一意に識別する番号
または他の識別子■ MSA セグメント
SEQ

値

ELEMENT NAME

1

確認応答コード

2

メッセージ制御 ID

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

12345678901234500007

通知メッセージの MSH-10 をエコーバック（a-⑨）: 検査ステータス通知（検査終了）を LIS から HIS へ通知する。
（a-⑧と同じ）（a-⑧）を参照のこと。

（a-⑩）: 生理検査結果通知にて検査結果を LIS から HIS へ送信する。
（a-⑥と同じ）（a-⑥）を参照のこと。

© JAHIS 2022131

（b-①）: 生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
（a-①と同じ）（a-①）を参照のこと。

（b-②）: モダリティ（心電計）より LIS へ検査予定日をキーに生理検査依頼照会を行い、検査予定のオー
ダ情報（複数）をモダリティ（心電計）に保存する。
（a-④と同じ）（a-④）を参照のこと。

（b-③）: モダリティ（心電計）をネットワークに接続し、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
（a-⑥と同じ）（a-⑥）を参照のこと。

（b-④）: LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から LIS へ送信する。
（a-⑦と同じ）（a-⑦）を参照のこと。

（b-⑤）: 実施したオーダに対して検査ステータス通知（検査終了）を LIS から HIS へ通知する。
（a-⑨と
同じ）
（a-⑨）を参照のこと。

（b-⑥）: 生理検査結果通知にて検査結果を LIS から HIS へ送信する。
（a-⑩と同じ）（a-⑩）を参照のこと。

（c-①）: 生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
（a-①と同じ）（a-①）を参照のこと。

（c-②）: 検査実施前にモダリティ（心電計）より LIS へ患者 ID をキーに患者情報照会を行う。
JAHIS データ交換規約 共通編 Ver.1.3「付録‐1 メッセージ例」を参照のこと。

（c-③）: 患者情報照会後、心電図検査を実施し、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
（a-⑥と同じ）（a-⑥）を参照のこと。

© JAHIS 2022132

（c-④）: LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から LIS へ送信する。
（a-⑦と同じ）（a-⑦）を参照のこと。

（c-⑤）: 実施したオーダに対して検査ステータス通知（検査終了）を LIS から HIS へ通知する。
（a-⑨と
同じ）
（a-⑨）を参照のこと。

（c-⑥）: 生理検査結果通知にて検査結果を LIS から HIS へ送信する。
（a-⑩と同じ）（a-⑩）を参照のこと。

（d-①）: 生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
（a-①と同じ）（a-①）を参照のこと。

© JAHIS 2022

133

（d-②）: 検査終了後、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
モダリティ（心電計）には患者属性情報として患者 ID のみ入力する。
送信メッセージ（Modality→LIS）
項目名

項目値

患者 ID

1234567890

検査名

標準１２誘導心電図

検査日時2020/08/21 12:34:56

測定日時

2020/08/21 12:34:56

付帯情報データ（メッセージ参照）

MFER データ（メッセージ参照）

DataUID

0123420150102132532123

備考

HL7 CDA R2

MSH|^~¥&|Modality||LIS||20200821115300||ORU^R01^ORU_R01|12345678901234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI<CR>
OBR|1|||9A110^標準１２誘導心電図^JC10|||20200821123456||||||||||||||||||F<CR>
TQ1||1|||||20200821123456<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥
HL7 CDA R2をBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub..¥X0D0A¥
MFERデータをBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||F|||20200821123456<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||0123420150102132532123||||||F|||20200821123456<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

7

メッセージ日時

ネットワーク全体で一意に識別可能であること
ネットワーク全体で一意に識別可能であること必須フィールド

20200821115300

送信システムがメッセージを作成した日時

9

メッセージ型

ORU^R01^ORU_R01

10

メッセージ制御 ID

12345678901234500006

必須フィールド
必須フィールド
メッセージを一意に識別する番号または他の識別子© JAHIS 2022

134

SEQ

値

ELEMENT NAME

備考

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド■ OBR セグメント
SEQ
1

値

ELEMENT NAME
セット ID - 検査要求

備考

1
必須フィールド

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10要求された試験／検査／検査セットの識別子コード7

検査日時20200901123456

存在すれば必須

25

結果状態

F

「HL7 表 0123 - 結果状態」■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20200821123456

備考
検査日時

■ OBX セグメント(1)SEQ

値

ELEMENT NAME

1

OBX セット ID

1

2

値型

ED

3

検査項目

MIME^MIMEPackage^JHSS0001

備考
必須フィールド「HL7 表 0125 - 値型」
必須フィールド^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed;boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥

5

検査結果値

Content-Type:

必須フィールド

application/x-hl7-cda-level-one+xml¥X0D0A¥

HL7 CDA R2 とMFER データをそPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZ

れぞれ Base64 エンコードしたテキ

GluZz0idXRmLTgiPz4NCjw/eG1sLXN0eW

ストを MIME 形式でパッケージ化

xlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy
ZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24g
eG1sbnM9InVybjpobDctb3JnOnYzIiB4bW
xuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥
X0D0A¥© JAHIS 2022

135

--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgR
UNHICAgICAgIBceTklIT04gS09IREVOXkVDR
1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALB
gH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUE
Y9MC4wNAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥

必須フィールド
11

検査結果状態「HL7 表 0085 - 検査結果状態コ

F

ード解釈」
14

検査日時

20200821123456

存在すれば必須■ OBX セグメント(2)SEQ

値

ELEMENT NAME

備考

1

OBX セット ID

3

2

値型

ST

3

検査項目

DUID^DataUID^JHSS0001

必須フィールド

5

検査結果値0123420150102132532123

必須フィールド

必須フィールド「HL7 表 0125 - 値型」

必須フィールド
11

検査結果状態14

検査日時「HL7 表 0085 - 検査結果状態コ

F

ード解釈」

© JAHIS 2022

202000811123456

136

存在すれば必須応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20200821115310||ACK^R01^ACK|99999999991234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500006<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20200821115310

送信システムがメッセージを作成
した日時

9

メッセージ型

10

メッセージ制御 ID

ACK^R01^ACK

必須フィールド
必須フィールド

99999999991234500006

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
確認応答コード

備考
必須フィールドAA「HL7 表 0008 - 応答コード」
必須フィールド

2

メッセージ制御 ID

12345678901234500006

通知メッセージの MSH-10 をエコーバック（d-③）: LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から LIS へ送信する。
（a-⑦と同じ）（a-⑦）を参照のこと。

（d-④）: LIS にて検査結果とオーダ情報を紐づけ、検査ステータス通知（検査終了）を LIS から HIS へ通知する。
（a-⑨と同じ）（a-⑨）を参照のこと。

© JAHIS 2022

137

（d-⑤）: 生理検査結果通知にて検査結果を LIS から HIS へ送信する。
（a-⑩と同じ）（a-⑩）を参照のこと。

（e-①）: 検査終了後、生理検査結果通知にて検査結果をモダリティ（心電計）から LIS へ送信する。
（d②と同じ）（d-②）を参照のこと。

（e-②）: LIS に生理検査結果が保存されたことを確認するため、データ保存確認をモダリティ（心電計）から LIS へ送信する。
（a-⑦と同じ）（a-⑦）を参照のこと。

（e-③）: 事後オーダとして患者 ID に患者情報とオーダ情報を添えて生理検査依頼（安静時 12 誘導心電図検査オーダ等）が HIS から LIS へ送信される。
（a-①と同じ）（a-①）を参照のこと。

（e-④）: LIS にて検査結果とオーダ情報を紐づけ、検査ステータス通知（検査終了）を LIS から HIS へ通知する。
（a-⑨と同じ）（a-⑨）を参照のこと。

（e-⑤）: 生理検査結果通知にて検査結果を LIS から HIS へ送信する。
（a-⑩と同じ）（a-⑩）を参照のこと。

（e-⑥）: 仮患者 ID を使用した場合、患者情報更新にて患者属性情報を HIS から LIS へ送信される。
JAHIS データ交換規約 共通編 Ver.1.3「付録‐1 メッセージ例」を参照のこと。

© JAHIS 2022

138

（f-①）: HIS が LIS へ生理検査結果照会を行う。
送信メッセージ（HIS→LIS）
項目名

項目値

備考

患者 ID = 1234567890

照会条件

依頼者オーダ番号=0123456789

MSH|^~¥&|HIS||LIS||20200821120000||QRY^R02^QRY_R02|12345678901234600000|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QRD|20200821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|0123456789<CR>
QRF|EKG||||CM<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

HIS

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド

7

メッセージ日時

20150821120000

9

メッセージ型

QRY^R02^QRY_R02

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234600000

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 2022

139

■ QRD セグメント
SEQ
1

値

ELEMENT NAME
照会日時

備考
必須フィールド

20200821120000

照会を作成した日時
必須フィールド2

照会フォーマットコード「HL7 表 0106 - 照会応答フォー

R

マットコード」
3

照会優先度

I

4

照会 ID

OSQ0158207

数量制限請求

999^RD

必須フィールド「HL7 表 0091 - 照会優先度」
必須フィールド
照会に対し一意の識別子
必須フィールド
必須フィールド

8

対象人物フィルタ

1234567890^東京^太郎

対象人物、あるいは誰に関する照会
かを識別(患者 ID)^(姓)^(名)必須フィールド

9

対象フィルタ「HL7 表 0048 - 対象主題フィル

RES

タ」
RES（結果）を指定

10

対象部門データコード

必須フィールド

0123456789

依頼者オーダ番号を指定■ QRF セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

対象場所フィルタ

EKG

問合せが関連する部門、システム、
サブシステムを識別

5

他の QRY 対象フィルタ© JAHIS 2022

照会条件に検査ステータスを指定

CMしたい場合は CM(検査終了)固定

140

応答メッセージ（LIS→HIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0001 東京都港区鹿ノ門 6 丁目 1 番 1 号

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号202008210089

検査名

標準１２誘導心電図

検査日時2020/08/21 12:34:56

測定日時

2020/08/21 12:34:56

MFER データ（メッセージ参照）

付帯情報データ（メッセージ参照）

HL7 CDA R2

MSH|^~¥&|LIS||HIS||20200821120010||ORF^R04^ORF_R04|99999999991234600001|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234600000<CR>
QRD|20200821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|0123456789<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|202008210089||9A110^標準１２誘導心電図^JC10|||20200821123456|||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR>
TQ1||1|||||20200821123456<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥
HL7 CDA R2をBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥X0D0A¥
MFERデータをBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||F|||20200821123456<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||0123420150102132532123||||||F|||20200821123456<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールドセパレータ|

必須フィールド

2

符号化文字

^~¥&

必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

HIS© JAHIS 2022

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること

141

SEQ

値

ELEMENT NAME

備考
必須フィールド

7

メッセージ日時

20200821120010

9

メッセージ型ORF^R04^ORF_R04

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234600001

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1
2

値

ELEMENT NAME
確認応答コード

メッセージ制御 ID

備考
必須フィールドAA「HL7 表 0008 - 応答コード」

12345678901234600000

確認メッセージの MSH-10 をエコーバック。

■ QRD セグメント
SEQ
1

値

ELEMENT NAME
照会日時

20200821120000

備考
必須フィールド
照会を作成した日時
必須フィールド2

照会フォーマットコード「HL7 表 0106 - 照会応答フォー

R

マットコード」
3

照会優先度

I

4

照会 ID

OSQ0158207

数量制限請求

999^RD

必須フィールド「HL7 表 0091 - 照会優先度」
必須フィールド
照会に対し一意の識別子
必須フィールド
必須フィールド

8

対象人物フィルタ

1234567890^東京^太郎

対象人物、あるいは誰に関する照会
かを識別(患者 ID)^(姓)^(名)必須フィールド

9

対象フィルタ「HL7 表 0048 - 対象主題フィル

RES

タ」
RES（結果）を指定

10

対象部門データコード© JAHIS 2022

必須フィールド

0123456789

依頼者オーダ番号を指定

142

■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

備考
必須フィールド
必須フィールド5

患者氏名

東京^太郎^^^^^L^I~トウキョウ^タロウ

成分：<姓>^<名>^^^^^L^<名前表^^^^^L^P~TOKYO^TARO^^^^^L^A

示コード
姓名~フリガナ~ローマ字

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0001^^H^東京都港区鹿ノ門6 丁目
1 番1 号^PRN^PH^^^^^^^^^03-0000-0000■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号202008210089

4

検査項目群 ID

9A110^標準１２誘導心電図^JC10

備考
必須フィールドORC-2 と同一
必須フィールド
要求された試験／検査／検査セットの識別子コード7

検査日時20200821123456

16

依頼者

112233^中田^隆^^^^^^^L^^^^^I

ORC-12 と同一

25

結果状態

F

「HL7 表 0123 - 結果状態」■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20200821123456

備考
検査日時

■ OBX セグメント(1)SEQ

値

ELEMENT NAME

1

OBX セット ID

1

2

値型

ED

3

検査項目 ID

MIME^MIMEPackage^JHSS0001

備考
必須フィールド「HL7 表 0125 - 値型」
必須フィールド^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed;boundary="HL7-CDA-boundary"¥X0D0A¥

5

検査結果値

Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type:application/x-hl7-cda-level-one+xml¥X0D0A¥

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZ© JAHIS 2022

143

必須フィールド
HL7 CDA R2 とMFER データをそれぞれ Base64 エンコードしたテキ
ストを MIME 形式でパッケージ化

GluZz0idXRmLTgiPz4NCjw/eG1sLXN0eW
xlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy
ZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24g
eG1sbnM9InVybjpobDctb3JnOnYzIiB4bW
xuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥
X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgR
UNHICAgICAgIBceTklIT04gS09IREVOXkVDR
1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALB
gH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUE
Y9MC4wNAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥

必須フィールド
11

検査結果状態「HL7 表 0085 - 検査結果状態コ

F

ード解釈」
14

検査日時

20200821123456

存在すれば必須■ OBX セグメント(2)SEQ

値

ELEMENT NAME

備考

1

OBX セット ID

3

2

値型

ST

3

検査項目

DUID^DataUID^JHSS0001

必須フィールド

5

検査結果値0123420150102132532123

必須フィールド

必須フィールド「HL7 表 0125 - 値型」

必須フィールド
11

検査結果状態「HL7 表 0085 - 検査結果状態コ

F

ード解釈」
14

検査日時

20200821123456

存在すれば必須

該当検査が無く、“ゼロ件”である旨応答する場合
リクエストされた条件に対する結果がゼロ件であった場合、OBR-25（結果状態）の値に”Z”（No record ofthis patient(Used only on queries)）をセットする。この場合、応答メッセージ例は以下となる。
MSH|^~¥&|LIS||HIS||20200821120010||ORF^R04^ORF_R04|99999999991234600001|P|2.5||||||~ISO
IR87||
ISO 2022-1994<CR>
MSA|AA|12345678901234600000<CR>
QRD|20200821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|0123456789<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|||""|||||||||||||||||||||Z<CR><EOM>© JAHIS 2022144

該当検査が複数あった場合
リクエストされた条件に対する結果が複数件あった場合（条件が患者 ID のみであった場合など）、OBR
以下を繰り返す。OBR-1（セット ID）はインクリメントされる。特にことわりが無ければ、OBR セグメン
トは以下となる。
MSH|^~¥&|LIS||HIS||20200821120010||ORF^R04^ORF_R04|99999999991234600001|P|2.5||||||~ISO
IR87||
ISO 2022-1994<CR>
MSA|AA|12345678901234600000<CR>
QRD|20200821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|""<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0001^^H^東京都港区鹿ノ門 6 丁目 1 番 1 号||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|202008210010||9A110^標準１２誘導心電図^JC10|||20200821100034|||||||||112234^新橋^一郎^^^^^^^L^^^^^I||||||||||F<CR>
TQ1||1|||||20200821100034<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||F|||20200821100034<CR>
OBX|2|ST|DUID^DataUID^JHSS0001|1|202009010000232||||||F|||20200821100034<CR>
OBR|2|202008210020||9A110^標準１２誘導心電図^JC10|||20200821114325|||||||||112233^中田^隆^^^^^^^L^^^^^I||||||||||F <CR>
TQ1||1|||||20200821114325<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0
L3hzbCIgaHJlZj0iRnVrdWRhX2UxMi54c2wiPz4KPEVDR09ic2VydmF0aW9uIHhtbG5zPSJ1cm46aGw3LW9yZzp2
MyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAyL...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTJsZWFkcyBFQ0cAAAAAAAAAAAsEAfoH0AwEAPcTEAoBAA0BAAQEAAATiAUEAAAACAYEAAAAAQgBAT8ABAkCAAE/AQQJAgACPwIECQIAAz8DBAkCAAQ/BAQJAgAFPwUECQIABj8GBAkCAAc/BwQJAgAIEQVE
cmlmdAEBAAMFQVNDSUkWCFJFU1QtRUNHFx1GVUtVREEgREVOU0hJXkZDUC...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||F|||20200821114325<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||202008210000542||||||F|||20200821114325<CR><EOM>© JAHIS 2022

145

３．心電図等の波形情報と検査結果情報の記述
３．１．MFER 波形のリンク情報をメッセージに記述する例
心電計などの小型の医療機器では、簡易な通信機能のみ実装されているに過ぎない。また、本規約ではMFER ファイル等結果データの送信プロトコルは規定しないが、結果データをリンク情報から別途取得する
手法は、小規模システムではより複雑となるケースもある。したがって、結果データは MIME パッケージ
として HL7 メッセージに埋め込む方法を推奨するが、下位互換のためにリンク情報を使用する方法例を記載する。本例では、心電図結果の自動解析所見と主な測定値は XML で記述し、心電図波形結果は MFER
記述して各々リンク情報を送信する。
OBX|1|RP|MFER^MFER ファイル
^JHSS0001||/MFEROut/00005_000001000_20200821105057451.mwf||||||R|||20200821123456<CR>
OBX|2|RP|XML^付帯情報ファイル^JHSS0001||/MFEROut/00005_000001000_20200821105057451.xm||||||R|||20200821123456<CR>

３．２． 自動測定結果の記述例
計測値を HL7 メッセージに埋め込む例を以下に示す。
OBX|7|NM|8867-4^Heart rate^LN^2.16.840.1.113883.6.1||67|bpm|||||F<CR>
OBX|8|NM|8625-6^PR interval^LN^2.16.840.1.113883.6.1||180|ms|||||F<CR>
OBX|9|NM|8633-0^QRS duration^LN^2.16.840.1.113883.6.1||94|ms|||||F<CR>
OBX|10|NM|8634-8^QT interval^LN^2.16.840.1.113883.6.1||398|ms|||||F<CR>
OBX|11|NM|8626-4^P wave axis^LN^2.16.840.1.113883.6.1||38|deg|||||F<CR>
OBX|12|NM|8632-2^QRS axis^LN^2.16.840.1.113883.6.1||30|deg|||||F<CR>
OBX|13|NM|8638-9^T wave axis^LN^2.16.840.1.113883.6.1||20|deg|||||F<CR>
OBX|14|NM|10040-4^S wave amplitude in lead V1^LN^2.16.840.1.113883.6.1||1.500|mV|||||F<CR>
OBX|15|NM|9995-2^R wave amplitude in lead V5^LN^2.16.840.1.113883.6.1||1.605|mV|||||F<CR>© JAHIS 2022

146

付録‐２. 本規約で定義される OID
1.2.392.200270.4.4.5 を本規約の root となる OID とし、レベル 8 を枝番としてそれぞれのオブジェクトのOID を連番で採番していくこととする。
付録2-1 – 本規約内で採番されているOID
OID
1.2.392.200270.4.4.5
1.2.392.200270.4.4.5.1
1.2.392.200270.4.4.5.2© JAHIS 2022

説明
生理検査データ交換規約 root
生理検査結果データ（JHSS0001）
生理検査メッセージイベントタイプ（JHSS0002）

147

付録‐３．作成者名簿作成者（社名五十音順）
日高 浩敦

三栄メディシス（株）

中田 英男

日本電気（株）木村 雅彦

日本アイ・ビー・エム（株）

藤咲 喜丈

日本光電工業（株）

村松 和彦

日本光電工業（株）

小林 聡

フクダ電子（株）

山田 剛

フクダ電子（株）© JAHIS 2022

148

日付
2007/08
2013/04

バージョン
Ver. 1.0
Ver.2.0

2016/11

Ver.3.0C

2022/04

Ver.3.1C

改定履歴
内容
初版
・患者情報照会メッセージを QBP/RSP に変更した。
・生理検査依頼照会を QBP/RSP に変更した。
・データ保存確認 QBP/RSP を追加した。
・ORU/ACK メッセージにおいて、ADT^A04 を廃止した。
・サンプル電文を見直した。
・誤字や誤表現を修正した。
・JAHIS データ交換規約 共通編 Ver.1.1 に記載された内容と同一の場合は、その記載内容を参照するようにした。
・他データ交換規約について外部有識者からの指摘事項を踏まえ、各所見直した。
・親子オーダについての記述方法を明記した。
・OBX-5 において、CDA の記述方法を HL7 原文に従い修正した。
・サンプル電文を見直した。
・誤字や誤表現を修正した。
・JAHIS データ交換規約 共通編 Ver.1.3 での変更内
容にあわせ、章構成、記載内容を見直した。
・本規約に記載するメッセージ類を実際の生理検査で必要な機能を踏まえて整理し、記載順、サンプル電文などを見直した。
・本規約に関連するシステムについて付録１に代表的なシナリオと本規約に記載するメッセージ類の利用について記載し、利用者の注目するシステムに関連するメッセージ、利用方法を明確にした。
・共通編に対して、本規約固有な仕様の説明である「【生理】」の表記を見直した。
・誤字や誤表現を修正した。

（JAHIS 標準 22-004）
2022 年 4 月発行
JAHIS 生理データ交換規約 Ver.3.1C
発行元 一般社団法人 保健医療福祉情報システム工業会〒105-0004 東京都港区新橋 2 丁目 5 番 5 号（新橋 2 丁目ＭＴビル 5 階）
電話 03-3506-8010

FAX 03-3506-8070（無断複写・転載を禁ず）© JAHIS 2022

149