7. 関連セグメント詳細
7.1 MSH - Message Header Segmentメッセージ・ヘッダ・セグメント
MSH セグメントは、メッセージの構文の目的、発信源、宛先、特性を定義する。
MSH属性
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

LEN
1
4
180
180
180
180
26
40
13
20
3
60
15
180
2
2
3
16
250
20
10

DT
ST
ST
HD
HD
HD
HD
TS
ST
CM
ST
PT
ID
NM
ST
ID
ID
ID
ID
CE
ID
ID

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

Japan
R
R
O
O
O
O
R
O
R
R
R
R
O
O
O
O
N
R
O
O
O

RP/#

Y

ITEM #
00001
00002
00003
00004
00005
00006
00007
00008
00009
00010
00011
00012
00013
00014
00015
00016
00017
00692
00693
01317
01598

ELEMENT NAME
Field Separator フィールド区切文字 ｜Encoding Characters コード化文字
Sending Application 送信アプリケーション
Sending Facility 送信施設
Receiving Application 受信アプリケーション
Receiving Facility 受信施設
Date/Time Of Message メッセージ日付/時間
Security セキュリティー
Message Type メッセージ型
Message Control ID メッセージ制御ID
Processing ID 処理ID
Version ID バージョンID
Sequence Number シーケンス番号
Continuation Pointer 継続ポインタ
Accept Acknowledgment Type 受諾肯定応答型
Application Acknowledgment Type アプリ肯定応答型
Country Code 国コード
Character Set 文字セット
Principal Language of Message 主要言語
Alternate Character Set Handling Scheme 文字セット操作法
Conformance Statement ID 適合文書ＩＤNOTE

MSHフィールド定義
MSH-1 Field Separator フィールド区切文字 (ST) 00001
定義： セグメントIDと最初の実フィールド(MSH-2-コード化文字)間のセパレーター。そのようなセパレータとしての他に、残りのメッセージでセパレータとして使う文字を定義する。
推奨値は | である。
MSH-2 Encoding Characters コード化文字 (ST) 00002
定義： 次の順番で並べられた4文字、つまり、成分セパレータ、反復セパレータ、エスケー
プ文字、副成分セパレータ。推奨値は ^~¥& である。メッセージ区切文字の解説を参照。
MSH-3 Sending Application 送信アプリケーション (HD) 00003
定義： 送信アプリケーションを識別するために用いる。
MSH-4 Sending Facility 送信施設 (HD) 00004
定義： 送信元施設を区別するため送信側の施設コードや略称などをセットする。
MSH-5 Receiving Application 受信アプリケーション (HD) 00005
定義： 受信アプリケーションを識別するために用いる。
MSH-6 Receiving Facility 受信施設 (HD) 00006
定義： 受信先施設を区別するため受信側の施設コードや略称などをセットする。
MSH-7 Date/time Of Message メッセージ日時 (TS) 00007
定義： 送信システムがメッセージを作成した日時。時間帯を指定した場合、それはメッセージ全体でデフォルトの時間帯として使われる。
MSH-8 Security セキュリティ (ST) 00008
定義： セキュリティの実装に関する情報であるが、その使用法は未定である。

Copyright©2002 JAHIS V2.0

73

JHLDEX20.DOC 2002/06/26

MSH-9 Message Type メッセージ型 (CM)Components:

00009<message type (ID)> ^ <trigger event (ID)>

定義： 第1成分は、HL7テーブル0076 - メッセージ型にリストされているメッセージ型である。第2成分は、HL7テーブル0003 - イベント型コードにリストされているトリガー・イベン
ト・コードである。受信システムはこのフィールドを使い、認識すべきデータ・セグメントを知り、また、これを転送するアプリケーションを知る。
テーブル 0076 - Message type メッセージ型 (検査依頼結果関連のみ掲載)
Value

Description

ACK

General acknowledgment message

ADR

ADT response

ADT

ADT message

一般肯定応答患者管理(ADT)応答

ORM

患者管理(ADT)メッセージ
Observation Result/Record Response 検査結果／診療記録応答
Order message オーダーメッセージ

ORR

Order acknowledgment message

ORU

Observ result/unsolicited 検査結果

OSQ
OSR

Order status query オーダ状況問合せ
Order status response オーダ状況応答

QRY

Query, original Mode

ORF

オーダ肯定応答メッセージ

問合せ

テーブル 0003

Event typeイベント型 (検査依頼結果関連のみ掲載)

Value

Description

A01
A02

ADT/ACK ADT/ACK -Admit a patient 患者管理(ADT)/ACK - 入院／来院の通知
Transfer a patient 患者管理(ADT)/ACK - 患者を転送する

A04

ADT/ACK -Register a patient

A06

ADT/ACK -A07

ADT/ACK -患者管理(ADT)/ACK - 患者の登録
Transfer an outpatient to inpatient 患者管理(ADT)/ACK - 外来患者を入院患者に変更
Transfer an inpatient to outpatient 患者管理(ADT)/ACK - 入院患者を外来患者に変更

A08

ADT/ACK -Update patient information

A11

ADT/ACK -A12

患者管理(ADT)/ACK - 患者情報の更新

ADT/ACK -患者管理(ADT)/ACK - 入院／来院通知を取り消す
Cancel transfer 患者管理(ADT)/ACK - 転院の取り消し

A19

QRY/ADR -Patient queryO01

ORM – Order message

O02

ORR – Order response

Q06

OSQ/OSR -Cancel admit

患者の問合せオーダーメッセージ

R01

一般オーダ応答メッセージORMに対する応答
Query for order status 検査依頼の照会
ORU – Unsolicited transmission of an observation 検査結果転送

R02

QRY – Query for results of observation

R04

検査結果の照会
ORF – Response to query; transmission of requested observation

検査結果の照会応答

MSH-10 Message control ID メッセージ制御ID (ST) 00010
定義： メッセージを一意に識別する番号または他の識別子。
MSH-11 Processing ID 処理ID (PT)
Components:

00011<processing ID (ID)> ^<processing

mode (ID)>

定義： メッセージを処理するかどうか決めるのに使用する。
テーブル 0103 - Processing ID 処理ID
Value
D
P
T

Description
Debugging デバギング
Production プロダクション
Training トレーニング

テーブル 0207 - Processing mode 処理モード
Value
A
R
I
T
not present

Copyright©2002 JAHIS V2.0

Description
Archive
Restore from archive
Initial load
Current processing, transmitted at intervals(scheduled or on demand)
Not present (the default, meaning current processing)74

JHLDEX20.DOC 2002/06/26

MSH-12 Version ID バージョンID (ID) 00012
定義： 受信システムは、バージョンIDを認識しメッセージが確実に解釈されるようにする。
本規約のバージョンIDは2.4を指定する。
テーブル 0104 - Version ID バージョンID
Value

Description

2.0

Release 2.0

September 1988

2.0D

Demo 2.0

October 1988

2.1

Release 2.1

March 1990

2.2

Release 2.2

December 1994

2.3

Release 2.3

March 1997

2.3.1

Release 2.3.1

May 1999

2.4

Release 2.4

November 2000

MSH-13 Sequence Number シーケンス番号 (NM) 00013
定義： 値がヌルでなければ、シーケンス番号管理が行われているものとする。送信側では受信アプリケーション・施設毎にシーケンス管理することとし、増分は1とする。
MSH-14 Continuation Pointer 継続ポインタ (ST) 00014
定義： アプリケーションに特有の方法で継続を定義するのに使用する。
施設にて定義（但し、推奨しない）。
MSH-15 Accept Acknowledgment Type 受諾肯定応答型 (ID) 00015
定義： このメッセージに応答して受諾肯定応答を返すことが要求される条件を定義する。
拡張肯定応答モードで要求される。取りうる値をHL7テーブル0155に示す。
MSH-16 Application Acknowledgment Type アプリケーション肯定応答型 (ID) 00016
定義： このメッセージに応答してアプリケーション肯定応答を返すことが要求される条件を定義する。拡張肯定応答モードで要求される。取りうる値をHL7テーブル0155に示す。
テーブル 0155 - Accept/application acknowledgment conditions アプリケーション肯定応答型

注記：

Value

Description

AL
NE

Always 常に
Never 決してないER

Error/reject conditions only エラー/リジェクト状態のみ

SU

Successful completion only 正常終了時のみ

MSH-15とMSH-16が省略(または両方ともnull)の場合、オリジナルの肯定応答モード規則が使われる。

MSH-17 Country Code 国コード (ID) 00017
定義： メッセージの発信国を定義する。主に通貨単位などのデフォルト要素を指定するのに使用される。ISO 3166は、使用可能な国コードのリストを提供する。
通常は本フィールドは使用しない。

Copyright©2002 JAHIS V2.0

75

JHLDEX20.DOC 2002/06/26

MSH-18 Character Set 文字セット (ID) 00692
定義： メッセージ全体に使用する文字セットコードを定義する。有効な文字セットをHL7
テーブル0211に示す。
テーブル 0211 - Character sets 文字セット
Value

Description

ASCII8859/1The printable 7-bit ASCII character set .

8859/2The printable characters from the ISO 8859/2 Character set

8859/3The printable characters from the ISO 8859/3 Character set

8859/4The printable characters from the ISO 8859/4 Character set

8859/5The printable characters from the ISO 8859/5 Character set

8859/6

The printable characters from the ISO 8859/6 Character set

8859/7

The printable characters from the ISO 8859/7 Character set

8859/8The printable characters from the ISO 8859/8 Character set(省略時)

The printable characters from the ISO 8859/1 Character set

8859/9The printable characters from the ISO 8859/9 Character set

ISO IR14

Code for Information Exchange (one byte) (JIS X 0201-1976)

ISO IR87

Code for the Japanese Graphic Character set for information interchange (JIS X 0208-1990)

ISO IR159

Code of the supplementary Japanese Graphic Character set for information interchange (JIS X
0212-1990)

注:文字セットにかかわらずフィールド区切り文字は 7-bit ASCII 文字セットである。

異なる文字セットの反復はデータ型PNとXPNのみに適用される。本フィールドの指定がない
もしくは反復の第一成分がNullの場合はsingle-byte character set (ASCII (ISO IR-6))が適用される。本フィールドが出現し第一成分が特定される場合この文字セットがメッセージのデフォ
ルト文字セットとなる。これはシングルバイト文字セットでなければならない。 (例えば
ISO-IR 6, ISO-IR 13, ISO-IR 14, ISO-IR 100, etc.) 第二第三成分は代替文字セットが使用できダブルバイト文字セットも含まれる。 (例えば ISO IR87) デフォルト文字セットは常にシングルバイト文字セットであり、ISO-IR 6 (ISO 646) or ISO-IR 14 (JIS X 0201-1976)の G0 域である。
半角カタカナは全てのフィールドで使用しないようにすること。漢字を使用する場合~ISO
IR87が一般的で、さらにJIS補助漢字を使用する場合続けて~ISO IR159とする。
MSH-19 Principal language of message 主要言語 (CE) 00693
定義： メッセージの主要言語を定義する。コードはISO 639を使用。
MSH-20 Alternate character set handling scheme 文字セット操作法 (ID) 01317
定義： 文字セットを切り替えるためのエスケープシーケンス方式を定義する。ISO 2022-1994
を使用する。
MSH-21 適合文書ＩＤ (ID) 01598
定義：各サイトもしくはＨＬ7 で制定された文書の為に用いる。適合文書は文法、構文及び特別なメッセージの為に詳細な説明，または、メッセージのセットを含む。適合文書の使用例
は HL7 5 章の 照会 にある。
このフィールドの繰り返しは，適合文書の作成や名称付けを行う場合，更に多くの柔軟性を持つ。例えば，最初の繰り返し，標準の適合文書の参照をができ、次に変更も可能である。
ＨＬ７の値−標準適合文書は HL7 ﾃｰﾌﾞﾙ 0449 - Conformance statementsに定義されている。
テーブル 0449 - Conformance statements
Value

Copyright©2002 JAHIS V2.0

Description

76

JHLDEX20.DOC 2002/06/26

7.2 NTE - Notes and Comments Segment

注釈コメントセグメント

注釈とコメントを送るためのメッセージに共通のフォーマットである。
他のメッセージやセグメントで表現可能な事項をNTEセグメントで代用してはならない。受信アプリケーションではNTEセグメントの内容を表示や印刷する以外のシステム的取り扱いはされない事を前提とする。
NTE属性
SEQ

LEN

DT

OPT

Japan

RP/#

1

4

SI

O

O

2

8

ID

O

O

3

65536

FT

O

O

Y

4

250

CE

O

O

Y

TBL#
0105
0364

ITEM #ELEMENT NAME

00096

Set ID - NTE セットID-NTE

00097

Source of Comment コメント発生源

00098

Comment コメント

01318

Comment Typeコメントタイプ

NOTE

NTEフィールド定義
NTE-1 Set ID - NTE セットID-NTE (SI) 00096
定義: ひとつのメッセージ中に複数のNTEセグメントが含まれる場合に使用される。番号付けについては、アプリケーション・メッセージの定義に記述されなければならない。
NTE-2 Source Of Comment コメント発生源 (ID) 00097
定義: コメントの発生源を明示する。これは導入の際にサイトで拡張される可能性がある。
テーブル 0105 – Source Of Comment コメント発生源
Value

Description

L
P

Ancillary (filler) department is source of comment 実施者がコメント発生源である
Orderer (placer) is source of comment 依頼者がコメント発生源である

O

Other system is source of comment

他のシステムがコメント発生源である

NTE-3 Comment コメント (FT) 00098
定義: 先行するセグメントに従属するコメント。
NTE-4 Comment type (CE) 01318
Components： <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドは送信されるコメントのＩＤを示す。
参照

使用者定義テーブル 0364 - Comment type
使用者定義テーブル 0364 - Comment type
Value

Copyright©2002 JAHIS V2.0

Description

PI

Patient Instructions 患者指示AI

Ancillary Instructions 追加指示

GI

General Instructions 一般的指示

1R

Primary Reason 一次理由

2R

Secondary Reason 二次理由

GR

General Reason 一般的理由

RE

RemarkDR

Duplicate/Interaction Reason
重複/指示理由

77

備考

JHLDEX20.DOC 2002/06/26

7.3 PID - Patient Identification Segment

患者識別セグメント

PIDセグメントは、患者識別情報を通信する主要な手段としてすべてのアプリケーションによって使用される。このセグメントは患者を永久に識別する情報と調査情報を含むが、この大部分はそれほど頻繁に変化しない。
PID属性
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

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

DT
SI
CK
CX
ST
XPN
XPN
TS
IS
XPN
CE
XAD
IS
XTN
XTN
CE
CE
CE
CX
ST
DLN
CX
CE
ST
ID
NM
CE
CE
CE
TS
ID

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

Japan
O
O
R
O
R
N
O
R
N
N
O
N
O
O
N
O
N
O
N
N
O
N
N
N
N
N
N
O
O
O

31
32
33
34
35
36
37
38

1
20
26
40
250
250
80
250

ID
IS
TS
HD
CE
CE
ST
CE

O
O
O
O
C
C
O
O

O
O
O
O
C
C
O
O

RP/#

Y
Y
Y

Y
Y
Y
Y

Y

Y

2

ITEM#
00104
00105
00106
00107
00108
00109
00110
00111
00112
00113
00114
00115
00116
00117
00118
00119
00120
00121
00122
00123
00124
00125
00126
00127
00128
00129
00130
00739
00740
00741

01535
01536
01537
01538
01539
01540
01541
01542

ELEMENT NAME
Set ID - Patient ID セットID−患者ID
Patient ID (External ID) 患者ID(外部ID)
Patient ID (Internal ID) 患者ID(内部ID)
Alternate Patient ID - PID 代替患者ID
Patient Name 患者氏名
Mother's Maiden Name 母親の旧姓
Date/Time of Birth 生年月日年齢
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 SSN番号−患者
Driver's Lic Num - Patient 運転免許証番号−患者
Mother's Identifier 母親の識別子
Ethnic Group 人種のグループ
Birth Place 誕生場所
Multiple Birth Indicator 多胎児誕生標識
Birth Order 誕生順序
Citizenship 市民権
Veterans Military Status 退役軍人状況
Nationality 国籍
Patient Death Date and Time 患者死亡日時
Patient Death Indicator 患者死亡識別Identity Unknown Indicator 身元不明識別Identity Reliabillty Code 身元信頼度
Last Update Date/Time 最終更新日
Last Update Facility 最終更新施設
Species Code 種
Breed Code 品種
Strain 血統
Production Class Code 製品クラスコード

NOTE

PIDフィールド定義
PID-1 Set ID - Patient ID セットID−患者ID (SI) 00104
定義：セグメントの反復が許されるメッセージについては、反復を識別するためにセットID
フィールドが使用される。例えば、交換及び照会のトランザクションは、セットID値1、2、3、などの多数のPIDセグメントを持つことができる。
PID-2 Patient ID (external ID) 患者ID(外部ID) (CK) 00105
定義：患者がオフィスなどの外部の別の施設からきていればその施設のIDなどをここに表現する。これは多数の異種の会社や施設が共有することができるIDとなる。
PID-3 Patient ID (internal ID 患者ID(内部ID) (CX) 00106
定義：患者を一意的に識別するため施設によって使用されるID(たとえば患者IDやカルテ番号、
請求書番号など)。患者番号を設定。
ORMメッセージを使用せず伝票による検査依頼で本フィールドに該当する情報が得られない
場合、ラボ側により付番されるIDを代入し付番組織を明示する。

Copyright©2002 JAHIS V2.0

78

JHLDEX20.DOC 2002/06/26

PID-4 Alternate Patient ID - PID 代替患者ID (ST) 00107
定義：第3のIDが患者を識別するために必要とされるかもしれない。例えば訪問番号、訪問期
日あるいは社会保障番号を含んでいる。患者IDとカルテ番号を併用するようなばあい従とな
るIDはこのフィールドを使用する。
PID-5 Patient Name 患者氏名 (XPN) 00108
Components： <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)> ^<name type code名前タイプ (ID) > ^ <name representation code名前表示(ID)>
本規約では以下の形式で利用する。
成分：<姓>^<名>^^^^^L^<名前表示コード>
複数の名前表示形式が存在する場合には、反復セパレータにより複数記述する。また、少な
くとも、英数字もしくは表音文字による患者氏名が記述されなければならない。
テーブル 0200 - Name Type 名前タイプコード
Value
A
L
D
M
C

Description
Alias Name 別名
Legal Name 法律上の名前
Display Name 表示名
Maiden Name 旧姓(婚姻前の名前)
Adopted Name 養子による名前

テーブル 0465 – Name Representation Code 名前表示コード
Value
I
A
P

Description
Ideographic (i.e., Kanji) 表意文字(漢字)Alphabetic (i.e., Default or some single-byte) シングルバイトの英数字
Phonetic (i.e., ASCII, Katakana, Hiragana, etc.) 表音文字(ASCII,仮名)

定義：患者氏名をMSH-18文字セットで指定した文字コードで使用する。例えばMSH-18にASCII~ISO IR87をセットした場合、PID-5はYamada^Tarou^^^^^L^A~山田^太郎^^^^^L^I~ヤマダ^タロウ^^^^^L^Pとなる。反復の順序には意味を持たない。姓と名の区別が困難な場合、姓のフィールドを代用するものとする。半角カタカナは全てのフィールドで使用しないようにすること。
患者の名札や検査検体のラベルなどと本フィールドの内容が同じであるよう、法律上の名前｢L｣を用いることが望ましく、運用に注意すべきである。
PID-6 Mother's Maiden Name 母親の旧姓 (XPN) 00109
定義：母親の旧姓、同じラストネームを持つ患者を明確に識別するために使用する。本フィールドに出現する名前タイプは｢M｣である。
通常は本フィールドは使用しない。
PID-7 Date/Time Of Birth 生年月日 (TS) 年齢 00110
定義：患者の生年月日、新生児などは誕生時刻まで記述。
生年月日に続けて年齢nnnuを記載することもできる、また年齢単位uとして Y 年令、L 月令、
W 週令、D 日令を使用、省略時は年令Yとする(YYYYLLDDHHMMSS^nnnu)。例えば19900301^7 1990年3月1日生7才、^10 10才、^5D 5日齢など、和暦は不可。
本規約では「YYYYMMDD」形式による、患者の生年月日。
PID-8 Sex 性別 (IS) 00111
定義：患者の性別。 使用者定義テーブル0001−性別を推奨する。
使用者定義テーブル 0001 Sex – 性別
Value
F
M
O
U

Description
Female女性
Male男性
Otherその他
Unknown未知PID-9 Patient Alias 患者の別名 (XPN) 00112
通常は本フィールドは使用しない。

Copyright©2002 JAHIS V2.0

79

JHLDEX20.DOC 2002/06/26

PID-10 Race 人種 (CE) 00113
定義：患者の同意を得て使用することができる。
通常は本フィールドは使用しない。
PID-11 Patient Address 患者住所 (XAD)
定義：患者の現住所。

00114

PID-12 County Code 郡コード (IS) 00115
定義：患者の郡コード。
通常は本フィールドは使用しない。
PID-13 Phone Number - Home 電話番号−自宅 (XTN)

00116

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

00117

PID-15 Primary Language 言語−患者 (CE) 00118
定義：患者の主要な言語。
通常は本フィールドは使用しない。
PID-16 Marital Status 婚姻状況 (CE) 00119
Components： <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
本規約では以下の形式で利用する。
成分：<ＩＤ>^<テキスト>
定義：患者の(社会的)婚姻状況。 使用者定義テーブル0002−婚姻状況を推奨する。
使用者定義テーブル 0002 - Marital Status 婚姻状況
Value
A

Description
Separated 別居

DDivorced 離婚

M

Married 既婚

SSingleW

未婚
Widowed 死別

C

Common Law

GLiving together

P

Domestic partner

R

Registered domestic partner

E

Legally SeparatedN

Annulled

I

Interlocutory

B

UnmarriedU

Unknown

O

Other

T

Unreported

PID-17 Religion 宗教 (CE) 00120
通常は本フィールドは使用しない。
PID-18 Patient Account Number 患者会計番号 (CX) 00121
定義：料金、支払いなどがすべて記録される勘定によって割り当てられる数字。患者の会計を識別するために使用される。
PID-19 SSN Number - Patient SSN番号−患者 (ST)
定義：患者の社会保障番号。
通常は本フィールドは使用しない。

00122

PID-20 Driver's License Number - Patient 患者の運転免許証番号 (DLN) 00123
定義：患者の運転免許証番号。いくつかのサイトは、患者を識別する一意的な番号としてこれを使用してもよい。第2の成分のデフォルトは患者が登録されている州である。
通常は本フィールドは使用しない。

Copyright©2002 JAHIS V2.0

80

JHLDEX20.DOC 2002/06/26

PID-21 Mother's Identifier 母親の識別子 (CX) 00124
定義：例えば新生児用にリンク・フィールドとして使用される。典型的に、患者IDあるいは会計番号が使用されるかもしれない。
PID-22 Ethnic Group 人種のグループ (CE) 00125
定義：患者の民族的起源を定義する。
通常は本フィールドは使用しない。
PID-23 Birth Place 誕生場所 (ST) 00126
定義：患者の誕生の場所を示す。
通常は本フィールドは使用しない。
PID-24 Multiple Birth Indicator多胎児誕生標識 (ID) 00127
定義：患者が多胎児の一人であったかどうか示す。Y/Nインジケータを使用。
通常は本フィールドは使用しない。
PID-25 Birth Order 誕生順序 (NM) 00128
定義：患者が多胎児の一人であった場合、誕生順序を示す値。
通常は本フィールドは使用しない。
PID-26 Citizenship 市民権 (CE) 00129
定義：患者の市民権の国を示す。推奨値として、使用者定義テーブル0171（HL7-ﾁｬﾌﾟﾀｰ3）−
国コード又はISO3166を参照すること。通常は本フィールドは使用しない。
PID-27 Veterans Military Status 退役軍人の状況 (CE)
通常は本フィールドは使用しない。

00130

PID-28 Nationality 国籍 (CE) 00739
定義：患者の属する国籍や国グループを示す。市民権と違い複数指定可。
PID-29 Patient Death Date and Time 患者死亡日時 (TS)
定義：患者死亡日時、臨床研究や管理用。

00740

PID-30 Patient Death Indicator 患者死亡識別 (ID) 00741
定義：患者が死亡したか否かY/Nで表現。
PID-31

Identity unknown indicator 身元不明識別 (ID)01535

定義：このフィールドは患者確認が行われているかどうかを示す。
参照 HL7 ﾃｰﾌﾞﾙ 0136 - Yes/no indicator

PID-32

Y

身元不明

N

身元確認済みIdentity reliability code 身元保証コード (IS)01536

定義：このフィールドは、トランザクション経由で送られた患者データの信頼性を示す。この値は、患者データのＰＩＤの誕生日や社会保障番号が確認されたものかどうかを示す。
参照 使用者定義テーブル 0445 - Identity Reliability Code
使用者定義テーブル 0445 - Identity Reliability Code
Value

Copyright©2002 JAHIS V2.0

Description
US

Unknown/Default Social Security Number
社会保障番号不明

UDUnknown/Default Date of Birth 誕生日不明

UA

Unknown/Default Address

AL

Patient/Person Name is an Alias

81

住所不明
患者名不明

JHLDEX20.DOC 2002/06/26

PID-33

Last update date/time

最終更新日付 (TS)01537

定義： 患者情報ＰＩＤセグメントの最終更新日
PID-34

Last update facility 最終更新施設 (HD)01538

定義：患者ＰＩＤセグメントの最終更新施設。これを元にこの情報を受信したデータを採用するかどうかを判断する。もし，受信したサイトはそのデータが信頼性の高い物であるならばそれを利用することの判断ができる。信頼の置ける施設からの更新情報は病院にとって信頼すべき物として扱われる。
PID-35Species code 種 (CE)01539

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドは生物学的種類を示す。これは，一般的，もしくは科学的な名称を含む。ＳＮＯＭＥＤは推奨されるコーデングシステムである。このフィールドが指定されていなければ人間として扱われる。
参照 使用者定義テーブル 0446 - Species Code
使用者定義テーブル 0446 - Species Code
Value

Description
No suggested values defined

条件付規則：もし PID-36 品種コードまたは PID-38 製品クラスコードが値を持つ時は、このフィールドも値を持つ必要がある。
例：

PID-36...|L-80700^Canine, NOS^SNM3|...
...|L-80100^Bovine^SNM3|...
...|L-80A00^Feline^SNM3|...

Breed code 品種 (CE)01540

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：動物の特定な品種。このフィールドは動物の種や血統に用いる物であり，全てのものに使える訳ではない。SNOMED は推奨されるコーディングシステムである。
参照 使用者定義テーブル 0447 - Breed Code
使用者定義テーブル 0447 - Breed Code
Value

Description
No suggested values defined

条件付規則：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|...

Copyright©2002 JAHIS V2.0

82

JHLDEX20.DOC 2002/06/26

PID-38

Production class code 製品クラスコード (CE)01542

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドは、一次使用の生きているもの、飼育されているものを示すコードとテキストを含む。
参照 使用者定義テーブル 0429 - Production class Code例：...|DA^Dairy^L|...
...|MT^Meat^L|...
...|RA^Racing^L|...

使用者定義テーブル 0429 - Production class Code
Value

Copyright©2002 JAHIS V2.0

Description
飼育/自然保存

BR

Breeding/genetic stockDA

Dairy 酪農

DR

Draft

DU

Dual Purpose

LY

Layer, Includes Multiplier flocks

MT

Meat

肉

OT

Other

その他

PL

PleasureRA

Racing

競争

SH

Show

ショウ

NA

Not ApplicableU

Unknown

生
多目的
層、多群

蓄え

非適用

不明

83

JHLDEX20.DOC 2002/06/26

7.4 PV1 - Patient Visit Segment

来院情報セグメント

PV1セグメントは、来院に関する情報を通信するために登録/ADTアプリケーションによって使用される。このセグメントは複数の来院統計記録を同じ患者の会計に送るため、又は単一の来院記録を複数の会計に送るために、使用することができる。個々のサイトは必ずこのセグメントを使用しなければならない。
PV1属性
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

LEN
4
1
80
2
250
80
250
250
250
3
80
2
2
6
2
2
250
2
250
50
2
2
2
2
8
12
3
2
1
8
10
12
12
1
8
3
25
250
2
1
2
80
80
26
26
12
12
12
12
250
1
250

DT
SI
IS
PL
IS
CX
PL
XCN
XCN
XCN
IS
PL
IS
IS
IS
IS
IS
XCN
IS
CX
FC
IS
IS
IS
IS
DT
NM
NM
IS
IS
DT
IS
NM
NM
IS
DT
IS
CM
CE
IS
IS
IS
PL
PL
TS
TS
NM
NM
NM
NM
CX
IS
XCN

Copyright©2002 JAHIS V2.0

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

Japan
N
R
O
N
N
N
O
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
O
O
N
N
N
N
N
N
N

RP/#

Y
Y
Y

Y
Y

Y

Y
Y
Y
Y

Y

ITEM#
00131
00132
00133
00134
00135
00136
00137
00138
00139
00140
00141
00142
00143
00144
00145
00146
00147
00148
00149
00150
00151
00152
00153
00154
00155
00156
00157
00158
00159
00160
00161
00162
00163
00164
00165
00166
00167
00168
00169
00170
00171
00172
00173
00174
00175
00176
00177
00178
00179
00180
01226
01224

ELEMENT NAME
Set ID - Patient Visit セットID−来院
Patient Class 患者クラス
Assigned Patient Location 患者所在場所
Admission Type 入院タイプ
Preadmit Number 仮入院番号
Prior Patient Location 患者の以前の所在
Attending Doctor 主治医
Referring Doctor 紹介医師
Consulting Doctor コンサルタント医師
Hospital Service 病院サービス
Temporary Location 一時的な所在
Preadmit Test Indicator 仮入院検査標識
Readmission Indicator 再入院標識
Admit Source入院元
Ambulatory Status 外来の状況
VIP Indicator VIP標識
Admitting Doctor 入院許可医師
Patient Type 患者タイプ
Visit Number 来院番号Financial Class 財務クラス
Charge Price Indicator 有償価格標識
Courtesy Code 優待コード
Credit Rating 信用格付け
Contract Code 契約コード
Contract Effective Date 契約発効日
Contract Amount 契約金額
Contract Period 契約期間
Interest Code 利息コード
Transfer to Bad Debt Code 不良負債転換コード
Transfer to Bad Debt Date 不良負債転換日付
Bad Debt Agency Code 不良負債代理コード
Bad Debt Transfer Amount 不良負債転換額
Bad Debt Recovery Amoun 不良負債回収額t
Delete Account Indicator 会計削除標識
Delete Account Date 会計削除日付
Discharge Disposition 退院処置
Discharged to Location 退院先Diet Type 給食タイプ
Servicing Facility サービス施設
Bed Status ベッド状況
Account Status 会計状況
Pending Location 保留所在
Prior Temporary Location 退院先の一時的な所在
Admit Date/Time 入院日付/時刻
Discharge Date/Time 退院日付/時刻
Current Patient Balance 患者の差引不足高Total Charges 合計金額
Total Adjustments 合計調整金額
Total Payments 合計支払金額
Alternate Visit ID 代替来院ID
Visit Indicator 来院識別
Other Healthcare Provider 他のヘルスケア供給者

84

NOTE

JHLDEX20.DOC 2002/06/26

PV1フィールド定義
PV1-1 Set ID - Patient Visit セットID−来院 (SI) 00131
定義：トランザクションを一意的に識別する番号。
PV1-2 Patient Class 患者クラス (IS) 00132
定義：サイトにおいて患者を分類するためにシステムで使われる共通のフィールド。入院、外来などの区別を表現する。
使用者定義テーブル 0004 - Patient class 患者クラス
Value
E
I
O
P
R
B
C

Description
Emergency 救急
Inpatient 入院患者
Outpatient 外来患者
Preadmit 予備入院
Recurring Patient 再来院患者
Obstetrics 産科
Checkup 人間ドック
注：「I」「O」以外を使用する場合は両者間にて調整の上、用いる。

PV1-3 Assigned Patient Location 患者所在場所 (PL)
成分:

00133

<point of care 病棟・診療科・診察室など (IS )> ^ <room 病室 (IS )> ^ <bed 病床 (IS )> ^ <facility 施設 (HD)> ^< location status 状態 (IS )> ^ <person location type 区分 (IS)> ^ <building 建物 (IS )> ^ <floor 階 (IS )>^ <location description 詳細 (ST)>

定義：病院、診療科、病棟、病室、ベッド等を表現する。新規の場所は最初に割当てた場所、あるいは患者の移動先の場所である。トランザクションの取消しや、退院の場合、現在の部
屋番号をこのフィールド表現する。
注：PLデータ型のフィールドは値の第5の成分(ベッド状況)が存在する場合、それは、PV1‑40の値に取って代わる。
本規約では通常の場合、下記内容とする。
定義：患者が最初に割り当てられた所在、あるいは患者が移動する先の所在を以下の書式で指定する。
成分：<科コード>^<病室コード>^<ベッド番号>^<病棟コード>
注：各種コードは両者間にて調整の上、用いる。

使用者定義テーブル 0116 - Bed status ベッド状況
Value
C

Description
Closed 閉鎖

HHousekeepingO

OccupiedU

Unoccupied

K

ContaminatedI

Isolated

清掃

使用
空き
汚染

隔離

PV1-4 Admission Type 入院タイプ (IS) 00134
定義：患者が入院していたか入院予定の状況を示す。
使用者定義テーブル 0007 - Admission type 入院タイプ
Value
A
E
L
R

Description
Accident 事故
Emergency 救急
Labor and Delivery 陣痛および出産
Routine 通常

PV1-5 Pre-admit Number 仮入院番号 (CX) 00135
定義：患者の仮入院番号を一意的に識別する。システムでは、仮入院番号を請求番号として患者が入院した後も使用し続けることもできる。
PV1-6 Prior Patient Location 患者の以前の所在 (PL) 00136
定義：新患であればここはNULLである。患者が転院されていれば、それは以前の患者所在を含んでいる。

Copyright©2002 JAHIS V2.0

85

JHLDEX20.DOC 2002/06/26

PV1-7 Attending Doctor 主治医 (XCN) 00137
定義：主治医の情報で、複数の名前やIDを持つ場合もある。
PV1-8 Referring Doctor 紹介医師 (XCN) 00138
定義：紹介医師の情報で、複数の名前やIDを持つ場合もある。
PV1-9 Consulting Doctor コンサルティング医師 (XCN)
定義：コンサルティング医師の情報。

00139

PV1-10 Hospital Service 病院サービス (IS) 00140
定義：患者が受ける処置又は手術のタイプ。トリガーイベントA01,A02,A14,A15に関して要求されるフィールド。
PV1-11 Temporary Location 一時的な所在 (PL) 00141
定義：割り当てられた所在以外の所在であって、一時的に必要なもの(たとえばOR)。.
PV1-12 Pre-admit Test Indicator 仮入院検査標識 (IS) 00142
定義：患者は入院するために仮入院検査を受けねばならないことを示す。
PV1-13 Re-admission Indicator 再入院標識 (IS) 00143
定義：患者が施設および環境に再入院することを示す。再入院はR、そうでなければNullである。再発患者の来院も示すことができる。
PV1-14 Admit Source 入院元 (IS) 00144
定義：患者がどこに入院していたかを示す。
PV1-15 Ambulatory Status 外来の状況 (IS) 00145
定義：提案値として使用者定義テーブル0009-外来状況を参照すること。
使用者定義テーブル 0009 - Ambulatory Status 外来状況
Value
A0
A1
A2
A3
A4
A5
A6
A7
A8
A9
B1
B2
B3
B4
B5
B6

Description
No functional limitations 機能制限なし
Ambulates with assistive device 補助機器を使用して来院
Wheelchair/stretcher bound 車椅子/担架を使用して来院
Comatose; non-responsive 意識不明；反応なし
Disoriented 方向感覚なし
Vision impaired 視力障害あり
Hearing impaired 聴力障害あり
Speech impaired 言語障害あり
Non-English speaking 英語以外を話す
Functional level unknown 機能のレベル未知
Oxygen Therapy 酸素治療
Special equipment (tubes, IVs, catheters) 特別の装置(チューブ、IV、カテーテル)
Amputee 手足の切断手術を受けた人
Mastectomy 乳房切除術
Paraplegic 対麻痺
Pregnant 妊婦

PV1-16 VIP Indicator VIP標識 (IS) 00146
定義：VIPのタイプを識別する使用者定義コード。
PV1-17 Admitting Doctor 入院時医師 (XCN) 00147
定義：入院時の医師の情報、複数の名前やIDのこともある。
PV1-18 Patient Type 患者タイプ (IS) 00148
定義：患者のタイプを示すサイト特定の値。
PV1-19 Visit Number 来院番号 (CX) 00149
定義：患者の各来院に割り当てられた一意的な数。
PV1-20 Financial Class 財務クラス (FC) 00150
定義：診療報酬の源を識別する目的で患者に割り当てられた、主要な財務のクラス。

Copyright©2002 JAHIS V2.0

86

JHLDEX20.DOC 2002/06/26

PV1-21 Charge Price Indicator 有償価格標識 (IS) 00151
定義：部屋およびベッドの料金にどの価格表を使用するか決めるために使用されるコード。
PV1-22 Courtesy Code 優待コード (IS) 00152
定義：患者が特定の優待を受けるかどうか示すコード。
PV1-23 Credit Rating 信用格付け (IS) 00153
定義：過去の信用経験を決定する使用者定義コード。
PV1-24 Contract Code 契約コード (IS) 00154
定義：会計残高を決済するための施設および保証人による契約のタイプを識別する。
PV1-25 Contract Effective Date 契約有効日付 (DT)
定義：契約が始まる日付。

00155

PV1-26 Contract Amount 契約金額 (NM) 00156
定義：保証人によって各期に契約ごとに支払われる金額。
PV1-27 Contract Period 契約期間 (NM) 00157
定義：使用者が定義する期間で、契約の持続期間を指定する。
PV1-28 Interest Code 利息コード (IS) 00158
定義：任意の未決済の金額に対し保証人に請求される利息額を示す。
PV1-29 Transfer To Bad Debt Code 不良負債変換コード (IS) 00159
定義：会計が不良負債に転換されたこと及び理由を示す。
PV1-30 Transfer To Bad Debt Date 不良負債変換日付 (DT)
定義：会計が不良負債状況に転換された日付。

00160

PV1-31 Bad Debt Agency Code 不良負債代理コード (IS) 00161
定義：会計が転換された先の不良負債代理を一意的に識別する。
PV1-32 Bad Debt Transfer Amount 不良負債転換額 (NM)
定義：不良負債に転換された金額。

00162

PV1-33 Bad Debt Recovery Amount 不良負債回収額 (NM)
定義：会計上の保証人から回収された金額。

00163

PV1-34 Delete Account Indicator 会計削除標識 (IS) 00164
定義：会計がファイルから削除されたこと及びその理由を示す。
PV1-35 Delete Account Date 会計削除日付 (DT) 00165
定義：会計がファイルから削除された日付。
PV1-36 Discharge Disposition 退院処置 (IS) 00166
定義：退院(つまり、帰宅；期限満了；など)の時の患者の処置。
PV1-37 Discharged To Location 退院先 (CM)
定義：患者の退院先の施設を示す。

00167

PV1-38 Diet Type 給食タイプ (CE) 00168
定義：患者用の特別の給食タイプを示す。
PV1-39 Servicing Facility サービス施設 (IS) 00169
定義：複数の施設環境の中でこの来院が関係している施設を示す。
PV1-40 Bed Status ベッド状況 (IS) 00170
定義：下位互換のためののみ使用。PLデータ型の第5成分状況を使用すること。
PV1-41 Account Status 会計状況 (IS)
定義：会計状況

Copyright©2002 JAHIS V2.0

00171

87

JHLDEX20.DOC 2002/06/26

PV1-42 Pending Location 保留所在 (PL) 00172
定義：患者が移動する先の看護ステーション、部屋、ベッド、施設IDおよびベッド状況を示す。 第5の成分(ベッド状況)中に値がある場合、それは、PV1-40の値に取って代わる。
PV1-43 Prior Temporary Location 以前の一時的な所在 (PL) 00173
定義：患者が到着しているか出発している場合、又は一般更新イベントのために使用される。
PV1-44 Admit Date/Time 入院日時 (TS)
定義：入院の日付/時刻。

00174

PV1-45 Discharge Date/Time 退院日時 (TS)
定義：退院の日付/時刻。

00175

PV1-46 Current Patient Balance 患者の差引不足額 (NM)
定義：来院患者の現在の差引不足額。
PV1-47 Total Charges 合計有償金額 (NM)
定義：来院有償金額の合計

00177

PV1-48 Total Adjustments 合計調整金額 (NM)
定義：来院調整金額の合計
PV1-49 Total Payments 合計支払金額 (NM)
定義：来院の支払い金額の合計

00176

00178
00179

PV1-50 Alternate Visit ID 代替来院ID (CX) 00180
定義：来院ID番号。このIDは入院時に患者を一意的に識別するために使用される。
PV1-51 Visit Indicator 来院標識 (IS) 01226
定義：データ送信が患者の来院によるのか会計によるのかの識別に使用。
使用者定義テーブル 0326 - Visit Indicator 来院標識
Value
A
no value

Description
Account Level 会計
Visit Level 来院

PV1-52 Other Healthcare Provider 他のヘルスケア供給者 (XCN) 01224
定義：他のヘルスケア供給者を示す。(例えば看護婦，付き添い，補助医師)複数の関係者に送ることができる。

Copyright©2002 JAHIS V2.0

88

JHLDEX20.DOC 2002/06/26

7.5 PV2 - Patient Visit - Additional Information Segment 患者来院-補足説明
PV2セグメントは、PV1セグメント上で含まれる来院特定情報の継続である。
PV2属性
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

LEN
80
250
250
250
25
25
2
26
26
3
3
50
250
8
1
1
8
2
1
1
1
1
250
2
1
8
2
8
8
250
2
1
26
1
1
1

DT
PL
CE
CE
CE
ST
ST
IS
TS
TS
NM
NM
ST
XCN
DT
ID
IS
DT
IS
ID
NM
IS
ID
XON
IS
IS
DT
IS
DT
DT
CE
IS
ID
TS
ID
ID
ID

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

Japan
C
N
N
N
N
N
N
O
O
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N

37
38
39
40
41
42
43
44
45
46
47

1
250
250
250
250
250
2
2
250
8
26

ID
CE
CE
CE
CE
CE
IS
IS
CE
DT
TS

O
O
O
O
O
O
O
O
O
O
C

N
O
O
O
O
O
O
O
N
O
O

Copyright©2002 JAHIS V2.0

RP/#

TBL#
0129

Y
0130

0136
0213
0214
0136
0215
0136
Y
0216
0217
0112

0218
0219
0136
0136
0136
0136

Y
Y

Y

0136
0430
0431
0432
0433
0434
0315
0316
0435

ITEM#
00181
00182
00183
00184
00185
00186
00187
00188
00189
00711
00712
00713
00714
00715
00716
00717
00718
00719
00720
00721
00722
00723
00724
00725
00726
00727
00728
00729
00730
00731
00732
00733
00734
00735
00736
00737

00738
01543
01544
01545
01546
01547
00759
00760
01548
01549
01550

ELEMENT NAME
Prior Pending Location 以前の保留所在
Accommodation Code 設備コード
Admit Reason 入院理由
Transfer Reason 転院理由
Patient Valuables 患者貴重品
Patient Valuables Location 患者貴重品所在
Visit User Code 来院ユーザ・コード
Expected Admit Date/Time 予定入院日付
Expectie dischange Date/Time 予定退院日付
Estimated Length Of Inpatient Stay 入院患者滞在予定日数
Actual Length Of Inpatient Stay 入院患者滞在実績日数
Visit Description 来院記述
Referral Source Code 紹介元
Previous Service Date 前診療日付
Employment Illness Related Indicator 雇用疾病関連ＩＤ
Purge Status Code 除去状態コード
Purge Status Date 除去状態期日
Special Program Code 特別プログラム・コード
Retention Indicator 保持標識
Expected Number of Insurance Plans 適用保険予定数
Visit Publicity Code 来院周知コード
Visit Protection Indicator 来院保護標識
Clinic Organization Name 病院組織名
Patient Status Code 患者状態コード
Visit Priority Code 来院優先権コード
Previous Treatment Date 前処理期日
Expected Discharge Disposition 予定退院処置
Signature On File Date ファイル期日署名
First Similar Illness Date 第一類似病気日
Patient Charge Adjustment Code 患者料金調節コード
Recurring Service Code 再発サービス・コード
Billing Media Code 請求媒体コード
Expected Surgery Date & Time 予定手術期日および時間
Military Prtnership Code 軍事パートナーシップ・コード
Military Non-Availabilty Code 軍事非利用性コード
Newborn Baby Indicator 新生児ＩＤ
Baby Detained Indicator 乳児保留ＩＤ
Mode of Arrival Code 到着手段
Recreation Drug Use Code 使用娯楽薬コード
Admission Level of Care Code 入院病状レベルコード
Precaution Code 患者特質コード
Patient Condition Code 患者状態コード
Living Will Code 患者意志確認コード
Organ Donor Code 臓器供給者コード
Advance Directive Code 申し送り指示コード
Patient Status Effective Date 患者状態有効コード
Expected LOA Return Date/Time 外泊予定日時

89

JHLDEX20.DOC 2002/06/26

NOTE

PV2フィールド定義
PV2-1 Prior Pending Location 以前の保留所在（PL）00181
Components:<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location description (ST)>
Subcomponents of facility:<namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

定義：このフィールドは保留取消し転送（A27（保留取消し入院））メッセージに対して要求される。他のすべてのイベントでは、それはオプションである。
PV2-2 Accommodation Code 設備コード（CE）00182
定義：このフィールドはこの来院用の特定の患者設備を示す。使用者定義テーブル0129−設
備コード（HL7 ﾁｬﾌﾟﾀｰ8）を参照すること。
通常は本フィールドは使用しない。
PV2-3 Admit Reason 入院理由（CE）00183
定義：このフィールドは患者入院の理由の短い記述を含んでいる。
通常は本フィールドは使用しない。
PV2-4 Transfer Reason 転院理由（CE）00184
定義：このフィールドは、患者転院の理由の短い記述を含んでいる。
通常は本フィールドは使用しない。
PV2-5 Patient Valuables 患者貴重品（ST）00185
定義：このフィールドは入院中にチェックされた患者貴重品の短い記述を含んでいる。
通常は本フィールドは使用しない。
PV2-6 Patient Valuables Location 患者貴重品所在（ST）00186
定義：このフィールドは患者の貴重品の所在を示す。
通常は本フィールドは使用しない。
PV2-7 Visit User Code 来院ユーザ・コード（IS）00187
定義：このフィールドは個々の施設のニーズにより、患者の来院をさらに分類する（たとえば、ティーチングフラッグ＝ＴＥは、患者がティーチングケースであることを示す）。使用
者定義テーブル0130−来院ユーザ・コード（HL7 ﾁｬﾌﾟﾀｰ3）を参照すること。
通常は本フィールドは使用しない。
PV2-8 Expected Admit Date 予定入院日付（TS）00188
定義：このフィールドは患者の入院が予定される日付を含んでいる。このフィールドはさらに外来患者／緊急患者登録の日付／時間を反映するために使用される。
PV2-9 Expected Discharge Date 予定退院日付（TS）00189
定義：このフィールドは患者の退院予定の日付および時間を含んでいる。これは計画された
仕事量をより正確に決定するために補助的に使用されるイベントに関連しない日付である。
このフィールドはさらに外来患者／緊急患者の予期される退院期日／時間または入院患者を反映するために使用される。
PV2-10 Estimated Length Of Inpatient Stay 入院患者滞在予定日数（NM）00711
定義：このフィールドは、入院患者の滞在の予定日数を指定する。
通常は本フィールドは使用しない。
PV2-11 Actual Length Of Inpatient Stay 入院患者滞在実績日数（NM）00712
定義：このフィールドは、入院患者の滞在の実際の日数を含んでいる。入院患者の滞在の実際の日数は、入院日付および退院日付から計算できないことがある。なぜなら途中に自宅に戻った日数が含まれるかもしれないからである。
通常は本フィールドは使用しない。

Copyright©2002 JAHIS V2.0

90

JHLDEX20.DOC 2002/06/26

PV2-12 Visit Description 来院記述（ST）00713
定義：このフィールドは、来院の簡潔なユーザ定義記述を含んでいる。
通常は本フィールドは使用しない。
PV2-13 Referral Source Code 紹介元（XCN）00714
定義：このフィールドは紹介をした人または組織の識別番号を含んでいる。この人／組織は、患者を専門医に紹介する医師と同じではない。例えば、ジョー・スミスは私を病院（または病院のジョーンズ博士）に紹介した。
通常は本フィールドは使用しない。
PV2-14 Previous Service Date 前診療日付（DT）00715
定義：このフィールドは、同じ再発する条件のための前のサービスの日付を含んでいる。これは第三者にある病気（例えば事故関連）を請求するため要求されるフィールドである。
通常は本フィールドは使用しない。
PV2-15 Emloyment Illness Related Indicatior 雇用疾病関連ＩＤ（ID）00716
定義：このフィールドは、患者の病気が雇用と関連するかどうか明示する。有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。
PV2-16 Purge Status Code 除去状態コード（IS）00717
定義：このフィールドは、会計のための除去状態コードを含んでいる。それは除去処理を決定するためにアプリケーションプログラムによって使用される。推奨値については、使用者
定義テーブル0213−除去状態を参照すること。
通常は本フィールドは使用しない。
使用者定義テーブル 0213 - Purge Status 除去状態
Value
P
D
I

Description
除去マーク。ユーザは来院をもはや更新することができない。
削除マーク。また、ユーザはそれに対する新しいデータを入力できない。
インアクティブマーク。また、ユーザは、それに対する新しいデータを入力できない。

PV2-17 Purge Status Date 除去状態日付（DT）00718
定義：このフィールドは、データがシステムから除去される日付を含んでいる。
通常は本フィールドは使用しない。
PV2-18 Special Program Code 特別プログラム・コード（IS）00719
定義：このフィールドは医療払い戻しのために必要になった来院のための特定の健康保険プ
ログラムを指定する。例えば小児健康援助、選択手術プログラム、家族計画などを含んでいる。推奨値については、使用者定義テーブル0214−特別のプログラム・コード（HL7 ﾁｬﾌﾟﾀｰ
3）を参照すること。
通常は本フィールドは使用しない。
PV2-19 Retention Indicator 保持ＩＤ（ID）00720
定義：このフィールドによって、ユーザは来院における財務および人口分析除去プロセスを制御できる。それは特定の高い優先権来院上の人口分析および財務のデータを保存するために使用される。有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。
PV2-20 Expected Number Of Insurance Plans 適用保険予定数（NM）00721：
定義：このフィールドは、この来院をカバーする適用保険の数を含んでいる。
通常は本フィールドは使用しない。
PV2-21 Visit Publicity Code 来院周知コード（IS）00722
定義：このフィールドは、ユーザに定義されたコードであって、どのレベルの周知（例えば公にしない、家族だけ）が特定の来院に許されるかを示すコードを含んでいる。推奨値については、使用者定義テーブル0215−周知コード（HL7 ﾁｬﾌﾟﾀｰ6）を参照すること。患者レベル
周知コードについては、PD1-11−患者周知コードを参照すること。
通常は本フィールドは使用しない。

Copyright©2002 JAHIS V2.0

91

JHLDEX20.DOC 2002/06/26

PV2-22 Visit Protection Indicator 来院保護ＩＤ（ID）00723
定義：このフィールドは個人の保護を識別するが、それは個人情報へのアクセスを、特定の来院に対する適切な権限を持っていないユーザから保護すべきかどうか、順番に、決定する。
有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。患者レベル保護
標識に関してはPD1-12−患者保護標識を参照すること。
通常は本フィールドは使用しない。
PV2-23 Clinic Organization Name 病院組織名（XON）00724
定義：このフィールドは、看護の（来院）エピソードに関係している組織名またはサブ・ユ
ニットおよび識別子を含んでいる。例えば、施設内のアレルギーまたは腫瘍学クリニックが指定されることがある。
通常は本フィールドは使用しない。
PV2-24 Patient Status Code 患者状態コード（IS）00725
定義：このフィールドは、看護のエピソードの状態を示す：例えば、アクティブ入院患者に対する退院入院患者。推奨値については、使用者定義テーブル0216−患者状態（HL7 ﾁｬﾌﾟﾀｰ
3）を参照すること。
通常は本フィールドは使用しない。
PV2-25 Visit Priority Code 来院優先権コード（IS）00726
定義：このフィールドは、来院の優先権を含んでいる。例えば、入院は非常時か選択的か緊急かである。推奨値については、使用者定義テーブル0217-来院優先権（HL7 ﾁｬﾌﾟﾀｰ3）を参照すること。
通常は本フィールドは使用しない。
PV2-26 Orevuiys Treatment Date 前処理日付（DT）00727
定義：このフィールドは、この来院に先立って最後に患者が受けたなんらかの処置の日付を含んでいる。以前の病院来院の場合には、以前の退院期日であることが多い。
通常は本フィールドは使用しない。
PV2-27 Expected Discharge Disposition予定退院処置（IS）00728
定義：このフィールドは、どのような患者の処置が来院の終わりに期待されるかを述べる。
推奨値については、使用者定義テーブル0112−退院処置（HL7 ﾁｬﾌﾟﾀｰ3）を参照すること。
通常は本フィールドは使用しない。
PV2-28 Signature On File Date ファイル署名日付（DT）00729
定義：このフィールドは、署名が保険請求目的のために得られた日付を含んでいる。
通常は本フィールドは使用しない。
PV2-29 First Similar Illness Date 第1類似病気日付（DT）00730
定義：このフィールドは、患者に持病があるかどうか決めるために使用される。
通常は本フィールドは使用しない。
PV2-30 Patient Charge Adjustment Code 患者料金調節コード（CE）00731
定義：このフィールドは、この患者の料金にどの調整をすべきかを示すユーザに定義されたコードを含んでいる。推奨値については、使用者定義テーブル0218−料金調整（HL7 ﾁｬﾌﾟﾀｰ
6）を参照すること。
通常は本フィールドは使用しない。
PV2-31 Recurring Service Code 再発サービス・コード（IS）00732
定義：このフィールドは、処理が連続的かどうか示す。推奨値については、使用者定義テー
ブル0219−再発サービス（HL7 ﾁｬﾌﾟﾀｰ3）を参照すること。
通常は本フィールドは使用しない。
PV2-32 Billing Media Code 請求媒体コード（ID）00733
定義：このフィールドは、会計がテープ請求から拒絶されることになっているかどうか示す。
有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。

Copyright©2002 JAHIS V2.0

92

JHLDEX20.DOC 2002/06/26

PV2-33 Expected Surgery Date & Time予定手術期日および時間（TS）00734
定義：このフィールドは、手術をする予定の日付および時間を含んでいる。
通常は本フィールドは使用しない。
PV2-34 Military Partnership Code 軍事パートナーシップコード（ID）00735
定義：このフィールドは、軍事施設が、そのサービスの使用のため非軍事施設と契約したことを示す。有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。
PV2-35 Military Non-Availability Code 軍事非利用性コード（ID）00736
定義：このフィールドは、患者が治療に非軍事施設を使用する許可を持っているかどうか示す。有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。
PV2-36 Newborn Baby Indicator 新生児ＩＤ（ID）00737
定義：このフィールドは、患者が新生児かどうか示す。有効な値については、HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。
PV2-37 Baby Detained Indicator 乳児保留ＩＤ（ID）00738
定義：このフィールドは、乳児が母親の退院の後に保留されるかどうか示す。HL7テーブル0136−はい／いいえ標識を参照すること。
通常は本フィールドは使用しない。
PV2-38Mode of arrival code 到着手段コード (CE)01543

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義： 患者がどのようにして医療施設に運ばれたかの識別。
参照 使用者定義テーブル 0430 - Mode of arrival code
使用者定義テーブル 0430 - Mode of arrival code

PV2-39Value

Description

A

Ambulance

C

Car 車

F

On foot

H

Helicopter ヘリコプター

救急車

徒歩

P

Public Transport

O

Other

U

Unknown

公共交通

その他
不明

Recreational drug use code 使用娯楽薬コード

(CE)

01544

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義： このフィールドは患者がどんな娯楽薬を使っているかを記述する。
参照：使用者定義テーブル 0431 - Recreational drug use code
使用者定義テーブル 0431 - Recreational drug use code
Value

Copyright©2002 JAHIS V2.0

Description
アルコール

A

AlcoholK

Kava カワカワ

M

Marijuana

マリファナ

T

Tobacco – smoked

煙草C

Tobacco – chewed

噛み煙草

O

Other

U

Unknown

その他

93

不明

JHLDEX20.DOC 2002/06/26

PV2-40

Admission level of care code 入院病状レベルコード (CE)01545

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドは入院時の病状レベルについて記述する。
参照：使用者定義テーブル 0432 - Admission level of care code
使用者定義テーブル 0432 - Admission level of care code
Value

DescriptionACPV2-41

Acute

急性
慢性

CH

Chronic

CO

Comatose 昏睡状態

CR

CriticalIM

Improved

快方

MO

Moribund瀕死

Precaution code 患者特質コード (CE)

危篤

01546

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義： このフィールドは、非臨床での必要な指導について記述する。
参照：使用者定義テーブル 0433 - Precaution code
使用者定義テーブル 0433 - Precaution code

PV2-42

Value

Description

A

Aggressive

B

Blind

C

Confused

D

Deaf

聾唖

I

On IV

レベル４

N

"No-code" (i.e. Do not resuscitate)P

Paraplegic

O

Other

U

Unknown

Patient condition code

活動的

盲目
混乱

コードなし

麻痺

その他
不明

患者状態コード

(CE)

01547

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義： このフィールドは医学以外の団体に，例えばファミリー、雇用者、宗教者、メディア等と通信する場合の患者状態コードを記述する。
参照：使用者定義テーブル 0434 - Patient condition code
使用者定義テーブル 0434 - Patient condition code
Value
A

Copyright©2002 JAHIS V2.0

Description
Satisfactory 良好
危篤C

CriticalP

Poor 病弱

S

Stable

安定

O

Other

その他

U

Unknown

94

不明

JHLDEX20.DOC 2002/06/26

PV2-43

Living will code

患者意志確認コード (IS)00759

定義： このフィールドは、患者の意志について記述する。また、その意志を医療施設が管理しているかをも記述する。
参照：使用者定義テーブル 0315 - Living will code、PD1-7 Living will code もあわせて参照のこと（HL7 ﾁｬﾌﾟﾀｰ 3）
使用者定義テーブル 0315 - Living will code
Value

PV2-44

Description
イエス、患者意志確認あり

Y

Yes, patient has a living willF

Yes, patient has a living will but it is not on file
イエス、患者意志確認ありしかし、ファイルなし

NNo, patient does not have a living will and no information was provided
ノー、患者意志確認なし、情報も無い

I

No, patient does not have a living will but information was provided
ノー、患者意志確認なし、しかし，情報あり

U

Unknown

不明

Organ donor code 臓器提供者コード (IS)00760

定義： このフィールドは、本人が臓器を提供する意志があるかどうかを記述する。また、臓器提供者カード，または，同様な書類が医療関連施設にファイルされているかを記述する。
参照：使用者定義テーブル 0316 - Organ donor code、
PD1-8 Organ donor もあわせて参照のこと（HL7 ﾁｬﾌﾟﾀｰ 3）
使用者定義テーブル 0316 - Organ donor code
Value

PV2-45

DescriptionY

Yes, patient is a documented donor and documentation is on file
イエス、患者は臓器提供の意志があり，書類もある

F

Yes, patient is a documented donor, but documentation is not on file
イエス、患者は臓器提供の意志がある、しかし、書類は無い

N

No, patient has not agreed to be a donor
ノー、患者は臓器提供の意志が無いI

No, patient is not a documented donor, but information was provided
ノー、患者は臓器提供の書類は無いが、意志はあるR

Patient leaves organ donation decision to relatives
患者は，臓器提供の判断を家族に委ねている

P

Patient leaves organ donation decision to a specific person
患者は臓器提供の判断を特定の人に委ねているU

Unknown

不明

Advance directive code 申し送りコード (CE)01548

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義： このフィールドは，医療関連施設に対する申し送りを記述する。
参照：使用者定義テーブル 0435 -Advance directive code、PD1-15 Advance directive code もあわせて参照のこと（HL7 ﾁｬﾌﾟﾀｰ 3）
使用者定義テーブル 0435 -Advance directive code
Value
DNR

Copyright©2002 JAHIS V2.0

Description
Do not resuscitate
蘇生できない95

JHLDEX20.DOC 2002/06/26

PV2-46

Patient status effective date 患者状態有効日付 (DT)01549

定義：このフィールドは PV2-24 患者状態が有効となった日付を示す。
参照: ＰＶ2-24 – Ｐａｔｉｅｎｔ Ｓｔａｔｕｓ。
PV2-47

Expected LOA return date/time 外泊予定日時 (TS)01550

定義：このフィールドは条件により記述される。A21−患者が外泊になるとき。A22−外泊から患者が戻ると同様に外泊のキャンセル(A53)，外泊トリガーからの患者キャンセル（A54）の日付が記述される。

Copyright©2002 JAHIS V2.0

96

JHLDEX20.DOC 2002/06/26

7.6 AL1 - Patient Allergy Information Segment

患者アレルギー情報

AL1セグメントは、多様なタイプの患者アレルギー情報を含んでいる。ほとんどのこの情報は使用者定義テーブルによる。各AL1セグメントは単一の患者アレルギーについて記述する。
AL1属性
SEQ
1
2
3

LEN
250
250
250

DT
CE
CE
CE

OPT
R
O
R

Japan
R
O
R

4
5
6

250
15
8

CE
ST
DT

O
O
O

O
O
O

RP/#

ITEM#
00203
00204
00205
00206
00207
00208

ELEMENT NAME
Set ID – Allergy セットID − アレルギー
Allergy Type アレルギータイプ
Allergy Code/Mnemonic/Description
コード/記憶法/記述
Allergy Severity アレルギー重症度
Allergy Reaction アレルギー反応
Identification Date 認識日付

NOTE

AL1フィールド定義
AL1-1 Set ID - Allergy セットID−アレルギー (CE) 00203
定義：患者の記録中のアレルギー記述の追加・変更・削除のために個々のトランザクション
を一意的に識別する数字である。セグメントの反復が許されるメッセージについては、反復を識別するためにセットIDフィールドが使用される。
反復を識別するための一意識別子。初期値１、増分１。
AL1-2 Allergy Type アレルギータイプ (CE) 00204
定義：一般的なアレルギーカテゴリー(薬、食物、花粉など)を示す。使用者定義テーブル0127
参照
使用者定義テーブル 0127 - Allergy Type アレルギータイプ
Value
DA
FA
MA
MC

Description
Drug Allergy 薬剤アレルギー
Food Allergy 食事アレルギー
Miscellaneous Allergy 様々なアレルギー
Miscellaneous Contraindication 様々な禁忌

AL1-3 Allergy Code/Mnemonic/Description アレルギーコード/記憶法/記述 (CE) 00205
定義：一意的に、特別のアレルギーを識別する。この要素は、ある外部かつ標準のコード化
するシステム(それは識別されねばならない)に一致させたり、あるいは、局所的な記述、主に文章の記述あるいは記憶法の記述によっても良い。
本規約では、アレルギー情報に関する詳細を以下の書式にて記述。
<コード>^<テキスト>
注：コードは両者間で調整の上、臨床病理学会コードか接頭語「L」をつけたユーザ定義コードを用いる。

AL1-4 Allergy Severity アレルギー重症度 (CE) 00206
定義：アレルギー(重度、中程度、軽度など)の一般的な重症度を示す。使用者定義テーブル0128
参照
使用者定義テーブル 0128 - Allergy Severity アレルギー重症度
Value
SV
MO
MI

Description
Severe重度
Moderate 中程度
Mild
軽度

AL1-5 Allergy Reaction アレルギー反応 (ST) 00207
定義：特定のアレルギー反応(震え、くしゃみ、発疹など)を短く文章で記述したもの。
AL1-6 Identification Date 認識日付(DT) 00208
定義：アレルギーが識別された日付

Copyright©2002 JAHIS V2.0

97

JHLDEX20.DOC 2002/06/26

7.7 ORC - Order Common Segment

共通オーダーセグメント

共通オーダーセグメント(ORC)は、すべてのオーダーに共通なデータ要素を伝達するために使用される(要求されるすべてのタイプのサービス)。場合によっては、ORC は文字列 ORC|OK|<依頼者オーダー
番号>|<実施者オーダー番号>|<CR>のように単純になる。
詳細内容がオーダーのために必要ないならば、オーダー詳細セグメントは省略してよい。たとえば、オーダーを保留するためには、ORC で次のフィールドを付けて伝達する(HD の値付きの ORC-1−オーダ
ー制御、ORC-2−依頼者オーダー番号、および ORC-3 実施者オーダー番号)。
ORC のフィールドとオーダー詳細セグメントの中のフィールドとの間にいくつかの重複がある。これ
らは以下の節に述べる。原則として、ORC と OBR に重複する情報は、OBR セグメントのものを優先する。

ORC 使用注記a)依頼者オーダーグループ
本規格では、複数のオーダーを 1 つのグループに集めるメカニズムをサポートする。大抵の場合、これは1 人の患者に対して｢依頼セッション｣を表すために使用される。
オーダーグループは、ORC-4-依頼者グループ番号に関連するオーダー(ORCs)のリストである。グループ
は、依頼者が最初のオーダーに依頼者グループ番号を付けた時に確立する。オーダーグループは、同じ依頼者グループ番号を有するすべての ORCs およびすべての詳細セグメントから成る。オーダーは、グループからキャンセルを使用して除去したり、取換えや親子メカニズムを使用して追加したりできる。新規オーダーは、その他の方法でのグループへの追加はできない。
b)重複フィールド
ORC は、すべてのオーダー(すなわち要求されたサービス)に共通なフィールドを一様に定義するよう意図されている。ただし、一部の ORC フィールドは、一部のオーダー詳細セグメント(たとえば OBR、RXO)
では重複する。たとえば、ORC-2 依頼者オーダー番号は、OBR-2 依頼者オーダー番号フィールドど同じ意味および目的を持つ。これによって過去のバージョンおよび ASTM との上位互換性が保たれる。
これらのフィールドを使用する規則では、ORC に現れない値はオーダー詳細セグメントに現れねばならない。しかし、両方の箇所に値を入れて混乱を避けることが望ましい。
c)親/子 − キャンセル、保留、中断
親オーダーのキャンセル、保留または中断の要求の伝達は、その要求は親オーダーおよびすべての関連の
子オーダーに対して再帰的に適用されるよう意図されている。たとえば
1)EKG アプリケーションが 3 回の EKG に対するオーダーを受け、これが 3 日連続で毎朝行われるとする。
2)EKG アプリケーションは 3 つの子オーダーを、各々の要求された EKG に対して 1 つづつ作成する。
3)元の親オーダーを取消す要求が受取られた時に 1 日目の EKG が実施されていた。
(親は取消せなかった)
4)残りの、未実施の子は要求の結果として取り消される。
ORC属性
SEQ
1
2
3
4
5
6
7

LEN
2
22
22
22
2
1
200

DT
ID
EI
EI
EI
ID
ID
TQ

OPT
R
C
C
O
O
O
O

Japan
R
R
C
O
O
O
X

8
9
10
11
12
13

200
26
250
250
250
80
250

CM
TS
XCN
XCN
XCN
PL

O
O
O
O
O
O

O
O
O
O
O
O

XTN
TS
CE

O
O
O

O
O
O

14
15
16

26
250

Copyright©2002 JAHIS V2.0

RP/#

Y/2

ITEM#
00215
00216
00217
00218
00219
00220
00221

ELEMENT NAME
Order Control オーダ制御
Placer Order Number 依頼者オーダ番号
Filler Order Number 実施者オーダ番号
Placer Group Number 依頼者グループ番号
Order Status オーダ状態
Response Flag 応答フラグ
Quantity/Timing 数量/タイミング

00222
00223
00224
00225
00226
00227

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 オーダ制御コードの理

00228
00229
00230

98

JHLDEX20.DOC 2002/06/26

NOTE

OBR‑27
を使用

SEQ

LEN

DT

OPT

Japan

RP/#

ITEM#

17
18
19
20

250
250
250
250

CE
CE
XCN
CE

O
O
O
O

O
O
O
O

00231
00232
00233
01310

21
22
23
24
25

250
250
250
250
250

XON
XAD
XTN
XAD
CVVE

O
O
O
O
O

O
O
O
O
O

01311
01312
01313
01314
01473

ELEMENT NAME
由Entering Organization 入力組織
Entering Device 入力装置
Action By 発動者
Advanced Beneficiary Notice Code
受益者注意コードOrdering Facility Name オーダ施設名
Ordering Faciloity Address オーダ施設住所
Ordering Facility Phone Number オーダ施設電話番号
Ordering Provider Address オーダ実施者住所
Order Status Modifier オーダ状態変更

NOTE

ORCフィールド定義
ORC-1 Order Control オーダー制御 (ID) 00215
定義：オーダーセグメントの機能を決定する。採りうる値はHL7テーブル0119 -オーダー制御を参照。コードは大別すると次の3つのカテゴリーに入る。
a) イベント要求
イベントを発動するために、『NW』(新規オーダー)とか『CA』(オーダー要求のキャンセル)のようなコードが使用される。
b) イベント肯定応答承認
イベント要求に返答するために、『OK』(オーダーが受け入れられた)とか『CR』(要求されたようにオーダーが取り消された)のようなコードが使用される。
c) イベント通知
イベントが発生したことを他のアプリケーションに知らせるために、『OC』(オーダーが取り消された)とか『OD』(オーダーが中断された)のようなコードが使用される。いかなる
アプリケーション応答も必要としない。
イベント要求コードは、イベントを発動することを意図する。イベント肯定応答コードは、イベントを要求したアプリケーションに応答することを意図する。イベント通知コードは、他のアプリケーションにたとえば次のようなことを知らせることを意図する。すなわち実施
者がオーダーに対し何かアクションをとりそれを他のアプリケーション、たとえば依頼者が知る必要がある場合等である。
実施者、依頼者、および他のアプリケーションは、イベント要求、イベント肯定応答、およびイベント通知型トリガーイベントを相互互換的に使用できる。しかしながら、あるオー
ダー制御コード(例 CR)は実施者のみが生成することができ、他のオーダー制御コード(例CA)は依頼者のみが生成することができる。
臨床検査依頼照会応答ではNW（新規オーダー）固定
テーブル 0119 – Ordeer Control Code オーダー制御コードとその意味
Description
New order 新規オーダー
Order accepted & OK オーダー受付 & OK
Unable to Accept Order 受付オーダーキャンセル

Originator2
P
F
F

Field Note3
I
I(ﾊﾝﾄｼｪｲｸ時使用可)
n(使用しない)

CA
OC
CR
UC

Cancel order request オーダーキャンセル依頼
Order canceled オーダーキャンセル完了
Canceled as requested オーダーキャンセル完了(要求通り)
Unable to cancel オーダーキャンセル(不能)

P
F
F
F

a
(ﾊﾝﾄｼｪｲｸ時使用可)

DC
OD
DR
UD

Discontinue order request オーダー中断要求
Order discontinued オーダー中断
Discontinued as requested オーダー中断(要求通り)
Unable to discontinue オーダー中断(不能)

P
F
F
F

c(CAにて対応)(CAにて対応)(CAにて対応)(CAにて対応)

HD
OH
UH
HR

Hold order requestオーダー保留要求
Order held オーダー保留Unable to put on hold オーダー保留(不能)On hold as requested オーダー保留(要求通り)

P
F
F
F

(使用しない)(使用しない)(使用しない)(使用しない)

Value
NW
OK
UA

1

Copyright©2002 JAHIS V2.0

99b

JHLDEX20.DOC 2002/06/26

Value1

Description

Originator2

Field Note3

RL
OE
OR
UR

Release previous hold 前回保留オーダーを解放
Order released オーダー解放
Released as requested オーダー解放(要求通り)
Unable to release オーダー解放(不能)

P
F
F
F

(使用しない)(使用しない)(使用しない)(使用しない)

RP
RU
RO
RQ
UM

Order replace request オーダー修正依頼
Replaced unsolicited オーダー修正通知(実施者)
Replacement order 修正後オーダー
Replaced as requested オーダー修正受理
Unable to replace オーダー修正(不能)

P
F
P,F
F
F

e,d,h
f,d,h(RPにて対応)
g,d,h,l(RPにて対応)
d,e,g,hPA
CH

Parent order 親オーダー
Child order 子オーダー

F
F,P

I
i

XO
XX
UX
XR

Change order request オーダー変更要求
Order changed, unsol. オーダー変更(非要求)
Unable to change オーダー変更(不能)Changed as requested オーダー変更(要求通り)

P
F
F
F

(RPにて対応)(RPにて対応)(RPにて対応)(RPにて対応)

DE
RE
RR
SR
SS
SC
SN
NA
CN

Data errors データエラー
Observations to follow 検査付帯情報
Request received 要求受付
Response to send order status request 送信オーダー状態応答
Send order status request 要求
Status changed オーダー状態要求送信
Send order number 状態変更
Number assigned オーダー番号送信
Combined result 統合検査結果

P,F
P,F
P,F
F
P
F,P
F
P
F

(使用しない)j(使用しない)k(使用しない)(使用しない)(使用しない)(使用しない)l(使用しない)l(使用しない)
m

RF
AF
DF
FU
OF
UF
LI
UF

Refill order request 補充オーダー要求
Order refill request approval 補充オーダー要求承認
Order refill request denied 補充要求オーダー拒否
Order refilled, unsolicited オーダー補充済、非要求
Order refilled as requested オーダー補充済、
Unable to refill 補充不可
診療or医療メッセージへのリンクオーダ
診療or医療メッセージからのアイリンクオーダ

F, P
P
P
F
F
F

o
p
q
r
s
t
(使用しない)(使用しない)注記:
1

オーダー制御値フィールド。

2『F』：この値は、実施者から開始し、依頼者他に送られる。『P』：この値は、依頼者または、依頼者特権(インタフェースネゴ
シエーションにおいて同意したような)を持つ他のアプリケーションから開始する。“

3

コードの説明ついては、次のテーブルの注を見ること。

ORC のオーダー制御コードのためのテーブルの注。
a)CA
オーダキャンセル依頼は、以前にオーダーしたサービスを行わないようにとの要求である。
キャンセル要求の確認は、実施者によっておこなわれる。たとえば、CRの(ORC-1-オーダー
制御)値を持つメッセージである。

b) UC
UC オーダーキャンセル(不能)コードは、依頼されたサービスが実施者によって取り消せないポイントにあるとき、あるいは、現場の取り決めで実施者によるキャンセルを禁止するとき使用される。このコードの使用は、ORC-6-応答フラグに従う。
c)DC
オーダー中断要求コードは、進行中の依頼されたサービスをやめるために使用される。それは、キャンセル要求と同じではない。それは、オーダーが起こるのを防止するために使用される。

d) RP, RQ, RU, RO
オーダー修正依頼は、以前に依頼された、1個以上のオーダーの置き換えである。取換えられ

Copyright©2002 JAHIS V2.0

100

JHLDEX20.DOC 2002/06/26

たオーダーは、あたかも取り消されたオーダーのように扱われる。依頼されたサービスが取換えられるかどうか、いつ取換えるかは、現場独自で決定する。オリジナルのオーダーがもとのままであることをサイトが要求するならば、親/子オーダー制御コードを使用する。このような時は、オーダー修正コードを使用しない。
取換えられる各々のオーダーには、RP(実施者に対するオーダー修正依頼)のORC-1-オーダー
制御値またはRU(実施者によって作成された、オーダー修正通知(実施者))を使用すること。
RUは実施者によって使用され、依頼者および、または他のシステムに通知するためのものである。現場の取り決めによって、ORCセグメント(RPまたはRUと)の後には、そのオリジナルのオーダー詳細セグメントが続いてもよい。ORCセグメント(RPまたはRUと)の後には、RO(修正後オーダーを示す)のORC-1-オーダー制御値をもつ、ORCセグメントが続かなければならない。現場の取り決めによっては、RO値を持つORCは、オーダー詳細セグメントが後に続いてもよい。
たとえば、部門のアプリケーションが2個のOBRオーダーを3つの異なったオーダーで取換えていたと仮定する。セグメントの連続は、次の通りになる。
図 4-2. RU and RO usage (example)
Segment
ORC
OBR

Order Control
RU

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

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

ORC-6-応答フラグの値によって、OBRセグメントが存在せねばならないかどうかが決定される。この取換え方法は、取換えのすべての可能なケースを扱う：1個から1個へ、多数から1個へ、1個から多数へ、および多数から多数へである。もし依頼者が実施者に2つのRPの付いた
この要求を送り実施者から依頼者への応答があるとすると、2つのRU(オーダー修正通知(実施者))は2つのRQ(オーダー修正受理)となる。
図 4-3. RQ and RO usage (example)
Segment
ORC
OBR

Order Control
RQ

Comment
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 segmente)

RP, RQ
オーダー取換要求コードは依頼アプリケーションの要求に応じて、実施者が1個以上の新規オーダーを1個以上の新規オーダと取換えることを許可する。

f)

RU
オーダー修正通知(実施者)コードは依頼アプリケーションから要求されることなしに実施
アプリケーションが別なアプリケーションに知らせることを許可する。

g) RO, RQ
取換えオーダーコードは実施者のアプリケーションによってオーダーされたサービスの正Copyright©2002 JAHIS V2.0

101

JHLDEX20.DOC 2002/06/26

確な取換えを指示する別なアプリケーションに送られる。それは上記のRPとRUのオーダー
制御コードによって使用される。
h) RP, RQ, RU, RO
ROの制御値をもつORCセグメントのオーダー番号の規則は取換え型(RPまたはRU)によって決定される。
RU型(すなわち実施者からのオーダー修正通知)のときには、実施者オーダー番号は、実施
アプリケーションによっていつものように生成される。依頼者オーダー番号は、RUのオー
ダー制御値つきの最初に送られたORCの依頼者オーダー番号と全く同一である。
RP型(すなわち別のアプリケーションから実施者へのオーダー修正依頼)のときには、依頼者オーダー番号は、新規オーダーのための手続きを使用して、依頼アプリケーションによって生成される。実施者オーダー番号は、新規オーダーのためと同一の手順を使用して、実施アプリケーションによって生成される。
取換えシーケンスがORUメッセージ(すなわち検査結果報告の間に)において使用される時の、オーダー修正に使用されるべき推奨セグメントを以下に述べる。
1) ROのオーダー制御値つきのORC
2) いかなるOBRセグメント(いかなるオーダー詳細セグメントによって変えられる)
3) 任意に、検査結果セグメント(OBX)が後に続く
4) NTEセグメントは、定型ORUメッセージにおけるのと同様にOBR(あるいはいかなる
オーダー詳細セグメント)またはOBXセグメントの後に続けられる。
i)

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

Example of two child orders

Segment
ORC
ORC
OBR

Order Control
PA
CH

Comment
1st parent ORC
1st child ORC
1st child order

ORC
OBR

CH

2nd child ORC
2nd child order

親子パラダイムの依頼者番号の割り当ては、実施者の依頼者が子オーダーを生成するかど
うか、または依頼者がSN/NAトランザクションをサポートするかどうかに依存する。依頼者が子オーダーを作成するならば、それはその通常の手続きに応じてそれらの依頼者番号を割り当てる。実施者が子を作成するならば、そこで2つの可能性がある：各々の子はその親の依頼者番号を受け継ぐか、あるいは、実施者は依頼者が依頼者番号を割り当てるよう要求するためにSN/NAトランザクションを使用する。どちらのケースでも、実施アプリケーションは、その通常の手続きに応じて子の実施者番号を作成する。
子オーダーが送られるときは常に、ORCセグメントのORC-8-親に、親の実施者番号(実施者から開始するならば)および親の依頼者番号(実施者から開始するならば、あるいは依頼者から開始するならば)が割り振られる。
親子のメカニズムは、たとえば、毎朝、連続して3回のEKGのオーダーを発行するといったように、親オーダーを拡張することのために使用される。
j)

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

Copyright©2002 JAHIS V2.0

102

JHLDEX20.DOC 2002/06/26

図 4-5. RE usage (example)
Segment

MSH
PID
ORC
RXO

Order Control

Comment

NW

First new orderFirst order segment

ORC
RXO
[ORC
OBR]
OBX
OBX
OBX
OBX

NW

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

ORC
RXO

NW

RE

3rd order
3rd order segment

HL7のこのバージョンにおいて、結果は、1個以上のOBXセグメントとしてオーダーと共に送ることができる。但し、ORCとOBRセグメントを必ずしも含む必要はない。
検査情報は、ORCを使用せずに、ORUメッセージを用いて伝えることができる。
ORUメッセージのOBRセグメントに含まれない情報を伝える必要が生じるときがある。この場合、ORCがORUメッセージに含まれることを推奨する。
REのオーダー制御値は、ORMメッセージにおいてのみ要求される。オーダーの後に検査結果(OBX)が続くことを示唆するためである。REコードはORUメッセージでは必要ではない。
なぜならOBRセグメントの後に検査結果(OBX)を続けることができるからである。
k) RR
下位互換性のため。現在のバージョンにおいては、受付了解応答に等しい。要求受信コー
ドは、オーダーメッセージが受け取られて、後で処理されることを示す。すなわち、そのオーダーは、より正確な応答をするための処理をまだ実行していないということである。
l)SN, NA, NW
オーダー番号の要求に関与する3つの状態がある(ORC-2-依頼者オーダー番号またはORC-3実施者オーダー番号)。
1) 実施アプリケーションが、たとえば、HISのような集中アプリケーションからORC-3-実施者オーダー番号を要求する必要があるとき。
2) 実施アプリケーションが、たとえば、オーダのような他のアプリケーションからORC-2依頼者オーダー番号を要求する必要があるとき。
3) アプリケーション(実施アプリケーションでない)が新規オーダーのためにORC-3-実施者
オーダー番号を割り当てたいとき
1)
実施アプリケーションが、集中実施者オーダー番号を必要とする場合。
SN 送信オーダー番号コードは、実施者のために、ORC-3-実施者オーダー番号をある、HISのような集中(その他のアプリケーションと呼ぶ)から要求するためのメカニズムを提供する、たとえば中央HISである。これはSNのORC-1-オーダー制御値を含んでいるORM
メッセージを送ることによって行う。このORCはNullのORC-3-実施者オーダー番号とORC-2-依頼者オーダー番号を持つ。これらは実施者がオーダーを開始するとき、実施
アプリケーションによって作成されたものである。
ORM(SN型)メッセージは、以下の2つの方法によって肯定応答される。
i) OKのORC-1-オーダー制御値を含んでいるORRメッセージによる。要求されなかった
ORMメッセージは、NAのORC-1-オーダー制御値つきのORCを含んでいて、後のある時間に送られる。
ii) 以下で述べるNAのORC-l-オーダー制御値を含んでいるORRメッセージによって実現できる。
NA番号を割り当てられたコードは、その他のアプリケーションが実施アプリケーションに、
最近割り当てられた実施者オーダー番号を知らせることを許す。ORC-1-オーダー制御
値は、NAの値、ORC-2-依頼者オーダー番号(SN値を持つORCから)、および最近割り当
てられた実施者オーダー番号を含む。
注： 依頼者オーダー番号と実施者オーダー番号の両方が、実施者のアプリケーションIDを持つ。.

Copyright©2002 JAHIS V2.0

103

JHLDEX20.DOC 2002/06/26

Code
SN
NA

From

ORC-2-Placer Order Number

ORC-3-Filler Order Number

filler application
Other application

placer order number^filler application ID
placer order number^filler application ID

null
filler order number^filler application ID

2)
実施アプリケーションが、依頼者オーダー番号を必要とする場合
SN 送信オーダー番号コードは、実施アプリケーションがORC-2-実施者オーダー番号をその他のアプリケーションから要求するためのメカニズムを提供する。これはSNのORC-1-オーダー制御値を含んでいるORMメッセージを送ることによって行う。この
ORCはnullのORC-2-依頼者オーダー番号とORC-3-実施者オーダー番号を持つ。これらは実施者がオーダーを開始するとき、実施アプリケーションによって作成されたものである。
ORM(SN型)メッセージは、2つの方法によって肯定応答される
i) OKのORC-1-オーダー制御値を含んでいるORRメッセージによって。要求されなかったORMメッセージは、NAのORC-1-オーダー制御値つきのORCを含んでいて、後のある時間に送られる。
ii) 以下で述べるNAのORC-l-オーダー制御値を含んでいるORRメッセージによって。
NA 番号を割り当てられたコードは、『その他』アプリケーションが実施アプリケーションに、最近割り当てられたORC-2-依頼者オーダー番号を知らせることを許す。ORCは、
NAのORC-1-オーダー制御値、最近割り当てられたORC-2-依頼者オーダー番号、およびORC-3-実施者オーダー番号(SN値を持つORCから)を含む。
注： 新しいORC‑2‑依頼者オーダー番号は、依頼者のアプリケーションIDを持っている。

Code
SN
NA

From
ORC-2-Placer Order Number
Filler application Null
Other application placer order number^placer application ID

ORC-3-Filler Order Number
filler order number^filler application ID
filler order number^filler application ID

3)
アプリケーションが、実施者オーダー番号を割り当てたい場合
NW オーダーを作成するアプリケーション(実施アプリケーションではない)が、実施者に新規オーダーの実施者オーダー番号を割り当てたいとき、またはRO (RO following an RP). この場合、その他のアプリケーションがORC3-実施者オーダー番号を完成する。この時には、実施者オーダー 番号の2番目の成分として、実施アプリケーションIDを使用する。
Code

From

ORC-2-Placer Order Number

NW , RO Other application to the filler placer order number^placer application ID

ORC-3-Filler Order Number
filler order number^filler application IDm) CN
統合検査結果コードは、複数のオーダーに関連する結果を送るためのメカニズムを提供する。この状態が、通常、放射線科医が、複数のオーダーで表示された複数の検査に対して単一のレポートを作成するときに放射線科レポートに見られる。たとえば、リューマチ性の関節炎患者のひざと手のフィルムは、放射線科医の側でひとつのレポートを生成することがある。
そのような結果が報告されるとき、CNコードが最後のORC以外の全てのREを置き換える。
結果は最後のORCとそのOBRに続く。3つのORCに続く単一の報告の例は下記の通りである：
MSH|...
PID|...
ORC|CN|...
OBR||A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...
ORC|CN|...
OBR||A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|...
ORC|RE|...
OBR||A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...
OBX||CE|73916&IMP||Radiologist's Impression|...
OBX||CE|73642&IMP||Radiologist's Impression|...

Copyright©2002 JAHIS V2.0

104

JHLDEX20.DOC 2002/06/26

OBX||FT|73642&GDT||Description|...

n) UA
オーダー受付不可コードが使用されるのは､新しいオーダーを実施者が受付できないときである｡受付できない理由としては､その患者にアレルギーのある薬剤の処方を要求したこと､またはそのオーダーを実施するための機器が利用できないことが考えられる｡これはMSAセグメント内で定義される通信レベルでの受付とは異なることに留意すること.
o) RF
RFは実施者または依頼者の両方による要求を受け入れる｡実施者は依頼者からの補充許可を要求しているかもしれない｡依頼者システムは､補充が実施者システムによって行われるよう要求しているかもしれない｡
p) AF
AFは補充または補充の量を許可する依頼者からの返答である｡
q) DF
DFは依頼者がオーダーの補充を許可しないことを示す｡下記のオーダー制御コード理由を使用して､要求拒否の理由を示してもよい｡これらの値は､｢NCPDF SCRIPT回答セグメント
コードリスト修飾子｣に由来することに留意すること｡
AA

Patient unknown to the provider

AB

Patient never under provider careAC

Patient no longer under provider care

AD

Patient has requested refill too soon

AE

Medication never prescribed for the patientAF

Patient should contact provider firstAG

Refill not appropriater)FU
FUは依頼者に対して､実施者が補充を患者の要求によるオーダーに対して発行したことを通知する｡.

s)OF
OFは補充に対する依頼者システムの要求に直接応答する｡

t)

UF
UFは実施者システムが許可補充要求に対してアプリケーションレベル拒否を示す｡

ORC-2 Placer Order Number 依頼者オーダー番号 ( EI) 00216
定義：依頼アプリケーションのオーダー番号
第1成分は、個々のオーダー(たとえば、(OBR))を識別する15文字までの文字列である。それは、依頼者(依頼アプリケーション)によって割り当てられる。それは、特定の依頼アプリケーションからのすべてのオーダーの中から一意に一つのオーダーを識別する。第2成分は依頼
アプリケーションのアプリケーションIDを含む。アプリケーションIDは、アプリケーションに一意に関連する6つの文字までの文字列である。ひとつの施設または相互に通信する施設のグループは、アプリケーションで一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプリケーションIDを割り当ててもよい。2つの成分は、共通の区切り文字によって分離される。
このように一意ではなく、真の依頼者がいくらかあいまいな3つの状態がある。
a) RU取替えに続く、ROのORC-1-オーダー制御値の場合；b) CH(子オーダー)のORC-1-オーダー制御値の場合；
c) SN(番号を送ること)のORC-1-オーダー制御値の場合；
ORC-2-依頼者オーダー番号がこれらの場合どのように割り当てられるかの詳細については、
ORC-1-オーダー制御の下のテーブルの注を参照すること。
ひとつの施設または相互に通信する施設のグループは、アプリケーションで一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプ
リケーションIDを割り当ててもよい。アプリケーションIDリストは、本規格の他の箇所で文書化されている、施設のマスタ辞書の1つになる。第三者アプリケーション(オーダーの依頼者
および実施者以外)がORMとORRのメッセージ送受信ができるので、このフィールドの依頼ア
プリケーションIDは、ネットワーク上の送信および受信アプリケーションと同じでなくとも

Copyright©2002 JAHIS V2.0

105

JHLDEX20.DOC 2002/06/26

よい(MSHセグメントにおいて述べた)。
ORC-2-依頼者オーダー番号は、OBR-2-依頼者オーダー番号と同じある。依頼者オーダー番
号がORCの中に存在していないならば、それは関連したOBR内に存在しなければならない。
その逆もまた真である。もし両方のフィールド、すなわちORC-2-依頼者オーダー番号およびOBR-2-依頼者オーダー番号が設定されるならば、それらは同じ値でなければならない。結果がORUメッセージで送られるとき、ORCは必要ないが、依頼者オーダー識別番号がOBRセグ
メント内に存在せねばならない。
これらの規則は、上位互換性のためORCとOBRの両方の中に存在している他のフィールドにも適用する。(たとえば、数量/タイミング、親番号、オーダー依頼者、および依頼コールバ
ック用電話番号)。
複数の検査オーダを一意に識別できる。15文字までの文字列から構成されるオーダー番号
注：バーコード出力を想定するため、15文字までとする。
ORC-3 Filler Order Number 実施者オーダー番号 ( EI) 00217
定義： 実施アプリケーションに関連したオーダー番号。その第1成分は、オーダー詳述セグ
メントを識別する15文字の文字列である(例 OBR)。それは、オーダー実施(受け取る)アプリ
ケーションによって割り当てられる。この文字列は、特定の実施アプリケーション(例 臨床検査)の他のオーダーから、そのオーダー(オーダー詳細セグメントにおいて明示されるように)を、一意に識別せねばならない。一意性は長時間にわたって持続しなければならない。
第2成分は、実施アプリケーションIDを含んでいる。実施アプリケーションIDは、6文字までの文字列であり、アプリケーションをネットワーク上の他のアプリケーションから識別する。実施者オーダー番号の第2成分は、オーダーの実際の実施者を常に識別する。
ある施設または相互通信施設グループは、アプリケーションの一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプリケーションIDを割り当ててもよい。アプリケーションIDリストは、本規格の他の箇所で文書化されている、施設のマスタ辞書の1つになる。第三者アプリケーション(オーダーの依頼者および実施者以外)がORMとORRのメッセージ送受信ができるので、このフィールドの依頼アプリケーション
IDは、ネットワーク上の送信および受信アプリケーションと同じでなくともよい(MSHセグメ
ントにおいて確認したように)。
ORC-3-実施者オーダー番号は、OBR-2-実施者オーダー番号と同じある。実施者オーダー番
号がORCの中に存在していないならば、それは関連したOBR内に存在しなければならない。
(この規則はORCおよびOBRの中の他の同一フィールドに対するものと同じであり、上位互換
性およびASTMとの互換性を促進する。)これが特に重要なのは、結果がORUメッセージで送られる。この場合、ORCは必要ないが、実施者オーダー識別番号がOBRセグメント内に存在せねばならない。
実施者オーダー番号(OBR-3あるいはORC-3)は、オーダーとその関連した検査を一意に識別する。たとえば、ある施設が検査をいくつかの関連アプリケーションから集め、それを共通のデータベースの中に入れ、この共通のデータベースがまた別のアプリケーションによって検査のために照会される、と仮定する。この場合、共通のデータベースアプリケーションによって送られた実施者オーダー番号と依頼者オーダー番号は、それぞれオリジナルの実施者
および依頼者であろう。すなわち共通のデータベースアプリケーションによって割り当てられた新しいものではない。
同様に、実施者あるいは依頼者でないオーダーの第三者アプリケーションが、オーダーの状態を修正する(たとえば、それをキャンセルすること)権限があるならば、その第三者アプリ
ケーションは、実施者にORMメッセージを送る。そこには、『CA』に等しいORC-1オーダー制御の付いたORCセグメント、およびオリジナル依頼者オーダー番号および実施者オーダー
番号を含む。いずれもそれ自身が割り当ることはない。
本規約ではOBR-3-実施者オーダー番号と同一内容とする。
ORC-4 Placer Group Number 依頼者グループ番号 (EI) 00218
定義：オーダー依頼アプリケーションが複数セットのオーダーを一緒にグループ化して後でそれらを識別できるようにする。
第1成分は、15文字までの文字列であって、これがすべての他のオーダーグループを特定の依頼アプリケーションから一意に識別する。それは依頼アプリケーションによって割り当て

Copyright©2002 JAHIS V2.0

106

JHLDEX20.DOC 2002/06/26

られて、ORCの依頼者オーダー番号と同じシリーズでもよいが、これは必須ではない。
第2成分は、依頼アプリケーションIDであり、これはORC-2-依頼者オーダー番号の第2成分と同じである。
ORC-5 Order Status オーダー状態(ID) (ID) 00219
定義： オーダーの状態。取りうる値についてはHL7テーブル0038-オーダー状態を参照すること。このフィールドの目的は、要求された場合または状態が変更になった場合に、オーダーの状態を報告することであり、オーダー自体を処理する事ではない。オーダー状態は、メッ
セージが送られるとき送信アプリケーションに知られていた状態を反映させる。実施者だけがこのフィールドに値を付けることができる。
HL7テーブル0038に示すオーダー状態は、HL7テーブル0119-オーダー制御と同じ様な内容を含んでいるが、目的は異なる。オーダ状態は、ORC-1-オーダー制御値のSRまたはSCにおいて典型的に使用される。これはオーダーの状態を、要求を受けた時または当事者に随時報告するためである。
臨床検査依頼では使用しない。
テーブル 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 進行中、予定

ORC-6 Response Flag 応答フラグ (ID) 00220
定義：これによって依頼者(送信)アプリケーションは、実施者から返されるべき情報の量を決定できる。要求されたレベルの応答は、即時には可能ではないかもしれない、しかし、それが可能なときは、実施者(受信)アプリケーションは、情報を送らなければならない。フィール
ドがnullであるとき、フィールドのデフォルト値はDである。取りうる値についてはHL7テー
ブル0121-応答フラグを参照のこと。
テーブル 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
定義：優先度、数量、頻度およびアトミックサービスのタイミングを決定する。オーダーセ
グメントは、アトミックサービスを記述するものとして考えられる必要がある。それは、第6.4節において詳細に定義される複合フィールドである。
たとえば、OBRセグメントが血液の単位を記述するとし、このフィールドによって三つの単位が毎朝続けて与えられるように要求する。この場合ORC-7-数量/タイミングは『1-XQAM＾X3』である。ORC-7-数量/タイミングは、OBR-27-数量/タイミングと同じである。
本規約では使用しない（OBR-27を使用する）。
ORC-8 Parent 親 (CM)Components:

00222<parent's placer order number (EI)> ^ <parent's filler order number (EI)>

Subomponents of parent’s placer order number:<entity identifier (ST)> & <application identifier 1(IS)> & <universal

identifier (UI)>
Subomponents of parent’s filler order number:<entity identifier (ST)> & <application identifier 1(IS)> & <universal identifier(UI)>

定義：親子のメカニズムの関係が存在するとき子を親に関係付ける。親子のメカニズムは、
ORC-1-オーダー制御の注のところで述べられる。第1成分は、親オーダーの依頼者オーダー番

Copyright©2002 JAHIS V2.0

107

JHLDEX20.DOC 2002/06/26

号を含んでいる。それは、オーダーが子であるとき要求される。
第2成分は、親オーダーの実施者オーダー番号を含んでいる。
依頼者オーダー番号と実施者オーダー番号との成分は、このフィールドの2つの成分の副成分として送られる。ORC-8-親は、OBR-29-親と同じである。
ORC-9

Date/Time Of Transaction トランザクション日時 (TS) 00223
定義： このトランザクションがオーダーアプリケーションに入る日時。新規オーダーを作成するメッセージの場合は、これは、オーダーが入れられた日付および時間である。
たとえば、キャンセルなどの他のメッセージの場合は、このトランザクションが送信アプ
リケーションに入る日時である。この日付と時間は、現在のトランザクションのためのもの
で、オリジナルのオーダーへの訂正のための『取り換え』た時刻ではない。同様に、このセグメントのORC-10-入力者、ORC-11-検証者、およびORC-13-入力の場所も現在のトランザク
ションに関連づけられ、オリジナルのオーダーに関連づけてはいない。

ORC-10 Entered By 入力者 (XCN) 00224
定義： 要求をアプリケーションに実際に打鍵した人の所属氏名。それは、要求が不正確に入れられ、関連部門が要求を明らかにする必要がある場合、監査証跡となる。現場の取り決め
によって、ID 番号または名前成分は、省略されてもよい。
要求をアプリケーションに実際に打鍵した操作者のID。
ORC-11 Verified By 検証者 (XCN) 00225
定義： 入れられた要求の精度を検証した人の所属氏名。それが使用されるのは、要求が技師によって入力され、看護婦などのより高い権威者によって検証される必要がある場合である。
現場の取り決めによって、ID 番号や名前成分は、省略されてもよい。
ORC-12 Ordering Provider オーダー依頼者 (XCN) 00226
定義： 要求を作成することに責任がある依頼する医師などの所属氏名。ORC-12-オーダー依頼者は、OBR-16-オーダー依頼者と同じである。
要求を作成することに責任がある依頼する医師などID。
ORC-13 Enterer's Location 入力者の場所 (PL) 00227
定義： 要求を入力した人の場所(たとえば、部門、階)。それは、部門のあるサブカテゴリーを含むためサイト固有のベースに基づいて使用されてもよい複合フィールドである。たとえば、ICU4は、4階のICUの場所の呼称とするなど。
ORC-14 Call Back Phone Number コールバック用電話番号 (XTN) 00228
定義： 要求またはオーダーに関して、必要な他の情報を確認するための電話番号。ORC-14コールバック用電話番号は、OBR-17-オーダーコールバック用電話番号と同じである
ORC-15 Order Effective Date/Time オーダー有効の日時 (TS) 00229
定義： 変更要求が有効になった、あるいは、有効になる予定の日時。
ORC-9-トランザクション(日時)が、ORC-15-オーダー ［訳注：原文はORC-16-オーダーとなっているが、明らかな間違いのため修正した］有効日時の後またはそれに等しくなっているな
らば、ORCおよびその下のセグメントにおけるデータ値はこの日時に有効になった。
ORC-9-トランザクション 日時がORC-15-オーダー有効日時より前ならば、ORCおよびその下位セグメントのデータ値は、オーダー有効日時に有効になるよう計画される。
有効ORC-15-オーダー有効日時が空白にしておかれるならば、その値は、ORC-9-トランザ
クション日時と等しいと仮定される。また、トランザクション日時が空白であるならばMSH-7メッセージと等しいと仮定される。
ORC-15-オーダー有効日時(同じORCセグメントのオーダー制御コードイベントのために)が、ORC-7-数量/タイミングと異なる場合は、ORC-15-オーダー有効日時が優先する。一例としてORCイベントが実施者への連続オーダーに対する中断要求であり、かつオーダー有効日
時がORC-7-数量/タイミング終了日時の前にあるならば、オーダー有効日時が優先する。ORCの中で識別されたオーダーが子を持っているならば、開始しなかった子は取り消される必要がある；プロセスに子がいるならば、それは中断される必要がある；子が中断できる点を超えて前進しているならば、その状態は影響されない。

Copyright©2002 JAHIS V2.0

108

JHLDEX20.DOC 2002/06/26

ORC-16 Order Control Code Reason オーダー制御コード理由 (CE) 00230
定義： オーダー制御コード(HL7テーブル0119)によって述べたオーダーイベントの理由の説明。コード化したあるいはテキスト形式のどちらでもよい。オーダー特定のセグメント(たとえば、RXO、ORO、OBR)の後のNTEは、その特定のセグメントのためにコメントとなる。もうひとつ、オーダー制御コード理由の目的には、そのオーダーイベントの理由を拡張することがある。
ORC-1-オーダー制御がNWであるときは、ORC-16-オーダー制御コード理由に、普通は値を設定しない。ただし、設定できないわけではない。取り消されたオーダーのときには、たとえば、このフィールドは、一般的に、キャンセルの理由を説明するために使用される。
良く実証されたアレルギーのために医者からの処方オーダーをキャンセルした調剤システ
ムは、このフィールドでアレルギーの事実が多分報告される。
それが薬理相互作用のためにこのオーダーをキャンセルしたならば、このフィールドは、相互作用物質の少なくとも名称(およびコード、必要とするならば)となる。文章で相互作用、および相互作用の激しさの程度を述べる。
ORC-17 Entering Organization 入力組織 (CE) 00231
定義： 入力者がオーダーを入力/修正した時に属していた組織
ORC-18 Entering Device 入力装置識別 (CE) 00232
定義： オーダーを入力するため使用された物理的装置(端末やPC)の識別子
ORC-19 Action By 発動者 (XCN) 00233
定義： 対応するオーダー制御コードによって表されたイベントを発動した人の所属氏名。たとえば、オーダー制御コードがCA(オーダーキャンセル依頼)であるならば、このフィールドは、オーダーキャンセルを要求した人を表す。
ORC-20

Advanced beneficiary notice code 受益者注意コード (CE)01310

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドは患者もしくは患者の責任で保険外のサービスに対して費用の支払うことを保証していない状態を示す。この要素は、ＨＣＦＡの条件を満たす為に導入された。
参照：使用者定義テーブル 0339 – Advanced beneficiary notice code
使用者定義テーブル 0339 – Advanced beneficiary notice code
Value
1
2

ORC-21

Description
Service is subject to medical necessity procedures サービスは医学の必要性がある手続きである
Patient has been informed of responsibility, and agrees to pay forservice 患者は支払いの義務があり，それを通知されている

3

Patient has been informed of responsibility, and asks that thepayer be billed 患者は支払いを了承し請求書を送ることを要求し

4

Advanced Beneficiary Notice has not been signed 受益者注意はサインされていない

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

01311

Components:<organization name (ST)> ^ <organization name type code (IS)> ^ <ID Number (NM)> ^ <check digit (NM)> ^<code identifying the check digit scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier typecode (IS)> ^ <assigning facility ID (HD)> ^ <name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)>

定義：このフィールドは、オーダの発行者施設を記述する
ORC-22

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

01312

Components: In Version 2.3 and later, replaces the AD data type. <street address (SAD)> ^ <other designation (ST)> ^ <city(ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <othergeographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> ^ <address representation code(ID)> ^ <address validity range (DR)>

定義： このフィールドは、オーダの発行者施設の住所を記述する

Copyright©2002 JAHIS V2.0

109

JHLDEX20.DOC 2002/06/26

ORC-23

Ordering facility phone numberオーダ施設電話番号 (XTN)

01313

Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^<telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code(NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>

定義：このフィールドは、オーダの発行施設の電話番号を記述する
ORC-24

Ordering provider address オーダ提供者住所 (XAD)

01314

Components: In Version 2.3 and later, replaces the AD data type. <street address (SAD)> ^ <other designation (ST)> ^ <city(ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <othergeographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> ^ <address representation code(ID)> ^ <address validity range (DR)>

定義：このフィールドは、オーダの医療提供者住所を記述する
ORC-25

Order status modifier オーダ状態変更 (CWE)

01473

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)> ^ <coding system version ID (ST)> ^ alternate coding systemversion ID (ST)> ^ <original text (ST)>

定義： このフィールドは、ORC-5 オーダ状態の変更，または、再生の記述する。定義されたオーダ状態コードの追加のレベル特性、もしくは追加の情報を提供する為に使われる。
このオーダ状態はＨＬ７により定義されたものとは異なり，ＡＰにより状態コードを任意に設定できる。データタイプはＣＥである。
使用規則：このフィールドは ORC-5 状態が指定されていれば 使用される。
例：ＬＩＳは入院患者のオーダを処理することができる。最新情報は臨床検査を経て最新の進捗を示す。
もしくは，外部の検査センターに依頼するためにオーダの状態変更子を使う状態にすることができる。医療以外のオーダを使う例として、電話の利用オーダがあり患者の部屋に伝えた、しかし、一次的に切断された。ORC-5 オーダ状態は、入院患者を示し、ORC-25 状態変更子は、接続を絶たれた状態を示す。3 番目の例として薬局の調剤を含む。その処方薬の調剤がされつつあるということを知ることは常に必要ではない。ORC-25 オーダ状態変更子はレベルがプリントされたかを示し、その処方箋が書かれ、もしくは渡された。

Copyright©2002 JAHIS V2.0

110

JHLDEX20.DOC 2002/06/26

7.8 OBR - Observation Request Segment

検査要求セグメント

概説(ASTM 1238−91 から抜粋)
検査要求(OBR)セグメントは、診断、検査、身体検査あるいは所見などを要求するオーダーに特有な情報を伝送する。
検査要求セグメントは、診断要求(たとえば生理検査、EKG)あるいは検査要求(たとえば生体検査、身体検査)など特定要求の属性を定義する。依頼者があるまとまった検査を要求する場合、必ずオーダーセ
グメントを指定する。生理検査の場合、通常はオーダーセグメント内の情報が一つの検体に適用される。
しかし、依頼と生理検査には 1 対 1 の関係があるわけではない。互いに異なる複数の検査項目が一つの検体に対し実行できるとしても、それぞれの検査項目は通常、自分専用のオーダーセグメントを必要とする。
この場合、その検体を扱うそれぞれのオーダーセグメント内でその検体情報を複写しなければならない。
その他の診断検査(たとえば胸部 X 線検査)では通常、個々の診断検査ごとに一つの独立したオーダーセグ
メントを生成する。
単一のオーダー・セグメントにより複数の検査項目セットを依頼することができるが、検査実施者は、それぞれの実施項目セット(電解質、CBC、バイタルサインなど)ごとに、単独のオーダーセグメントを生成するものとする。サービス担当は、検査の報告にさいし、オリジナルのオーダーセグメントから新規オーダーセグメントそれぞれに適切なオーダー(検体)情報を複写し、一つ一つの オーダー セグメントが各検査項目セットの ヘッダ− として依頼者に返信されるようにする。
たとえば血液検体に溶血が見られたために、依頼された検査項目セットを実行できない場合、オーダー
セグメントは、X(検査が実行されなかったことを示す)相当の｢OBR−25−結果状態｣と共に依頼者に返される。この場合、検査セグメントは伝送されない。
検査がうまく終了した場合、依頼者に帰ってくるメッセージには、オーダーにより生成された検査ごとに、オーダー・セグメント(OBR)と検査(OBX)セグメントがこの順番で含まれる。そのような検査セグメ
ントの数は、プロセスで実行されたそれぞれの測定の数によって異なる。
依頼者は、依頼のさい OBX セグメントを送信し、結果診断に必要な臨床データをサービス担当者に提供することができる。
図 4−8 に OBR セグメント属性一覧を示す。このセグメント内の(＋)項目は依頼者ではなく実施者が作成し、その値は、OBR セグメントが報告書の一部として返信されたとき必要に応じて設定する。したがって、実施者が新規オーダーを受理する場合、(＋)項目の値を設定することはない。ただし実施者がオーダーを開始する場合は例外である。その場合、実施者オーダー番号が設定されるが、依頼者オーダー番号
はブランクでもよい。
検体関連検査の場合、星印(＊)の付いたフィールドのみが関係する。依頼者が検体を受理する場合は、依頼者がこれらのフィールドを指定する。実施者が検体を受理する場合、実施者がこれらのフィールドを指定する。
OBR−7−検査/採取日時および OBR−8−検査/採取終了日時(フラグを＃に設定)は生体関連検査時間である。検体検査の場合、この 2 つの情報は検体採取の開始と終了を表す。患者を直接検査する(BP や胸部 X 線など)場合は、検査の開始・終了時刻を表す。
OBR セグメント１つが、１検体材料に相当する。
OBR属性
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14

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

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

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

Japan RP/# ITEM # ELEMENT NAME
R
00237 Set ID – Observation Request ID設定 − 検査要求
R00216 Placer Order Number 依頼者オーダー番号O
00217 Filler Order Number + 実施者オーダー番号R
00238 Universal Service ID 検査項目群IDO
00239 Priority 優先度
O00240 Requested Date/time 要求日時
O00241 Observation Date/Time # 検査/採取日時
O00242 Observation End Date/Time # 検査/採取終了日時
O00243 Collection Volume * 採取量OY00244 Collector Identifier * 採取者識別子
O00245 Specimen Action Code * 検体処置コードO00246 Danger Code 危険(検体)コードO00247 Relevant Clinical Info. 関連臨床情報
O00248 Specimen Received Date/Time * 検体受理日時

Copyright©2002 JAHIS V2.0

111

NOTE
ORC内通し番号

OBX１番目の項目IDJHLDEX20.DOC 2002/06/26

SEQ
15
16
17
18

LEN
300
250
250
60

DT
CM
XCN
XTN
ST

OPT
O
O
O
O

Japan RP/# ITEM # ELEMENT NAME
R
00249 Specimen Source * 検体採取元
OY00226 Ordering Provider 依頼者
O
Y/2 00250 Order Callback Phone Number ｵｰﾀﾞｰｺｰﾙﾊﾞｯｸ用電話番号
O
00251 Placer field 1 依頼者フィールド1

19
20
21
22

60
60
60
26

ST
ST
ST
TS

O
O
O
C

O
O
O
O

00252
00253
00254
00255

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

CM
ID
ID
CM
TQ
XCN
CM
ID
CE
CM
CM
CM
CM
TS
NM
CE
CE
CE
ID
ID

O
O
C
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O
O

O
O
O
O
R
O
O
O
O
O
O
O
N
O
O
O
O
O
O
O

00256
00257
00258
00259
00221
00260
00261
00262
00263
00264
00265
00266
00267
00268
01028
01029
01030
01031
01032
01033

43

250 CEO

44

250 CE

O

45

250

CE

O

Y

46

250

CE

O

Y

47

250

CE

O

Y

Y
Y/5

Y
Y
Y
Y

Y
Y

O

Y

採取番号（複数採取管時）

Placer field 2 依頼者フィールド2
Filler Field 1 + 実施者フィールド1
Filler Field 2 + 実施者フィールド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 随行者要否

01034 Planned Patient Transport Comment 計画患者搬送コメント
00393 Procedure Code

Y

NOTE

手続きコード01316 Procedure Code Modifier

手続きコード修飾子

01474 Placer Supplemental Service Information
ビス情報
01475 Filler Supplemental Service Information
実施補給サービス情報

依頼者補給サー+：臨床検査依頼の場合は使用しない*：検体を受理した時に使用する。

OBRフィールド定義
OBR-1 Set ID - Observation Request セットID-OBR (SI) 00237
定義： 最初の送信オーダーには通し番号1が割り当てられ、2番目のオーダーには通し番号2が割り当てられるものとする。3番目以降同様。
複数検体時の上位ＯＲＣに対する通番。初期値１、増分１。
同一ORCセグメントに対して１から付番される通し番号。OBRセグメントは同一検体・同一採取管単位で生成するため、同一オーダ内での採取管本数にも相当する。
OBR-2 Placer Order Number 依頼者オーダー番号 ( EI) 00216
定義： ORC−2−依頼者オーダー番号に同じ。依頼側検体番号など。
第1成分は最大15文字の文字列で個々のOBRを識別する。これは依頼者(依頼アプリケーション)によって割り当てられ、ある依頼アプリケーションから送信されるすべてのオーダーの中から特定のオーダーを一意に識別する。アプリケーションIDは最大6文字の文字列で、特定のアプリケーションと一意に結び付けられている。
複数の検査オーダを一意に識別できる15文字までの文字列から構成されるオーダー番号。

Copyright©2002 JAHIS V2.0

112

JHLDEX20.DOC 2002/06/26

OBR-3 Filler Order Number 実施者オーダー番号 ( EI) 00217
定義： オーダーおよびその関連する検査に対する永久的な識別子。ラボ側検体番号など
第1成分は個々のOBRを識別する文字列である。これは実施(受信)アプリケーションによって割り当てられ、ある実施アプリケーション(たとえば臨床生理検査室)からのすべてのオーダーの中から特定のオーダーを一意に識別する。第2成分は実施アプリケーションIDである。OBR−3−実施者オーダー番号はORC−3と同一である。
OBR-4 Universal Service ID 検査項目群ID (CE) 00238
定義： 要求された検査/試験/セットの識別子コード。このコードは、ローカル・コードまたは 汎用 コードのいずれか、もしくはその両方を基準に設定できる。 汎用 手順による識別子を使用することが望ましい。
個々の検査項目を指示する場合は日本臨床病理学会臨床検査項目分類コードを使用する(5.6
検査項目コードについてを参照)。
個々の検査項目をOBXセグメントで指定する場合は、検査分野や検査セットを設定する。その場合コードや名称は施設固有である旨をコード体系Lで明示する。例：C123^生化学^L。
オーダ情報として伝達する検査項目は、通常、OBXセグメントを使用するため、OBRセグメ
ントにおけるこの要素は実際には意味を持たない。互換性の為、OBXセグメントに記述する
１番目の検査項目Idをダミーとして記述する。
OBR-5 Priority 優先度 (ID) 00239
定義： 使用せず。以前の優先度はOBR−27−数量/タイミングの第6成分で指示する。
OBR-6 Requested Date/Time 要求日時 (TS)
定義： 検査を依頼した日時

00240

OBR-7 Observation Date/Time 検査/採取日時 (TS) 00241
定義： 臨床検査関連日時。患者を直接検査した場合は、検査を実施した実際の日時である。
検体関連検査の場合、このフィールドは検体を採取した日時を表わすものとする。これは結果専用フィールドである。ただし、依頼者あるいは第三者が検体をすでに採取している場合はこの限りでない。
OBR-8 Observation End Date/Time 検査/採取終了日時 (TS) 00242
定義： 検査あるいは経時検体採取の終了日時。検査が長時間にわたって実施される場合、検査期間の終了時期を表す。検査が瞬時に終わる場合は、このフィールドはnullになる。これは結果フィールドである。ただし、依頼者、あるいは実施者以外の第三者がすでに検体を採取してしまっている場合はこの限りでない。
OBR-9 Collection Volume 採取量 (CQ) 00243
定義： 検体検査の場合検体量。デフォルト単位はMLである。特に、単位はISO標準単位略
語(ISO−2955、1977年)の表記に従うべきである。これは結果専用フィールドである。ただし、依頼者あるいは第三者が検体をすでに採取している場合はこの限りでない。
検体検査の場合、検査項目の特性により採取量の明示が必須の場合がある。この場合、それぞれの検査項目に指定された採取量の明示を行うこと。例えば24時間蓄尿であれば、採取の如何に関わらず1日量を記載すること。
注：検査材料が蓄尿の場合、一般的に24時間蓄尿量を記載する。OBR-7,OBR-8及びOBR-9が明示される場合でもOBR-9は一日量とみなす。採取時間帯の総量ではないことに注意。OBR-9の明示がない場合、1日量検体とはみなさない。
OBR-10 Collector Identifier 採取者ID (XCN) 00244
定義： 検体検査が要求された場合、このフィールドは、検体を採取した個人、部門あるいは施設を識別する。名前もしくはIDコード(あるいはその両方)を指定できる。
OBR-11 Specimen Action Code 検体処置コード (ID) 00245
定義： このオーダーに伴ってあるいは先行して実施される検体処置。検体に関する一般処置
は、このフィールドに付随するORCセグメント内のオーダー制御コードにより示されるが、このフィールドで一般処置をさらに詳細に規定する。たとえば、新規オーダー(ORC− NW )Copyright©2002 JAHIS V2.0

113

JHLDEX20.DOC 2002/06/26

が検査室へ送られた場合、検査室で検体を採取すべきかどうか( L あるいは O )がこのフィールドによって伝えられる。HL7テーブル0065−検体処置コード参照。
テーブル 0065 - Specimen action code 検体処置コード
Value
A
G
L
O
P
R
S
B
D
K
C
F
U
T
N

Description
Add ordered tests to the existing specimen 依頼検査を既存の検体に追加する
Generated order; reflex order 生成オーダー；反映オーダー
Lab to obtain specimen from patient 検査室が患者から検体を採取する
Specimen obtained by service other than Lab 検査室以外のサービスによる検体採取
Pending specimen; Order sent prior to delivery 保留検体；採取以前に依頼されたオーダー
Revised order 改訂オーダー
Schedule the tests specified below 指定した検査をスケジュールする
検体・作成標本の返却
希釈測定
特別な検体保管指定
測定項目優先順位指定あり
強制測定；検体量不足時希釈測定
強制測定；測定上限値を超えての最終値測定
採血者指定、特別な手技を持った人の採血
新生児採血

ORU（到着確認／検査結果）メッセージでは、ORM メッセージでの同フィールドを返す。
OBR-12 Danger Code 危険(検体)コード (CE) 00535
定義： 危険であることが知られている、あるいは疑われる患者・検体を示すコードかテキスト、あるいはその両方(たとえば陽性結核患者、肝炎患者の血液などの感染情報)。コードとテキストのどちらかあるいはいずれも指定しない場合がある。
成分: <危険情報コード(CE)>＾<危険情報テキスト(TX)>
OBR-13 Relevant Clinical Information 関連臨床情報 (ST) 00247
定義： このフィールドには、患者あるいは検体に関する追加臨床情報が記述される。このフィールドは、検査診断が要求された場合、疑われる病状や臨床所見を報告するのに使用する。
たとえば、血中ガスの二酸化炭素量、パップ試験時の月経周期、および検査診断に影響を及
ぼすその他の条件を報告する場合など。
ただし、オーダーセグメントの直後に一連のOBXセグメントを追加することで、より構造化された形式でこの種の情報を送ることが可能である。したがって、身体情報(身長・体重やバ
イタルサインなど)、検査情報、投薬情報などはOBXセグメントを利用することを推奨する。
OBR-14 Specimen Received Date/Time 検体受領日時 (TS) 00248
定義： 検体を必要とする検査の場合、診断サービスの実際のログイン時間/検体受領日時。
OBR-15 Specimen Source 検体採取元(検査材料) (CM) 00249
成分:<検体採取元名あるいはコード(CE)>＾<添加剤(TX)>＾<フリーテキスト(TX)>＾<部位(CE)>＾<部位修飾子(CE)>＾<採取方法修飾子(CE)>定義： 検体の採取部位や医療サービスの対象となる部位や検査材料を示す。検体採取後の検体検査では実際の提出材料を示すこと。日本臨床病理学会臨床検査項目分類コード材料の使用を推奨する(5.7 検査材料・採取部位コードについてを参照)。検査項目が材料を暗黙に指定している場合は指示不要である。
第1成分には、検体採取元名あるいはコード(CEデータ型成分と同様)が記述される。(検査名により検体採取元名が類推できる場合でも、検体採取元名を指定した方がよいことがある。たとえば血液培養−心臓血液)第2成分には、適用可能な場合、ヘパリン、EDTA(すなわちシュウ酸塩)など、検体に加える添加剤を記述する。
第3成分はフリーテキストで、オーダーの一部として採取法を指定する場合にその採取法を記述する。採取法が理論上検査結果となる場合はOBX結果セグメントを使用すべきである。
第4成分は検体を採取する部位を指定する。第5成分は部位修飾子である。たとえば、検体採取部位が 対肘窩(anticubital fossa) で、部位修飾子が 右 。成分はCE型で副成分よりなる。
第6成分は検体採取における扱いを示し、値は、F-凍結、R-冷蔵、空白-室温を用いる。
「−１５℃にて凍結」等の詳細な情報は、OBR-39のコメントにて指定する。

Copyright©2002 JAHIS V2.0

114

JHLDEX20.DOC 2002/06/26

OBR-16 Ordering Provider 依頼者 (XCN) 00226
定義： 検査依頼者のID。IDコードあるいは名前、またはその両方を指定できる。これはORC−12−依頼者と同じである。検査依頼医師をセットする。
OBR-17 Order Callback Phone Number オーダーコールバック用電話番 (XTN) 00250
号定義： 状態あるいは結果を標準フォーマットで報告するさいの電話番号。可能であれば、
内線または呼出番号(あるいはその両方)も併せて指定する。
OBR-18 Placer Field #1 依頼者フィールド＃1 (ST) 00251
定義： 依頼者フィールド＃1。依頼者によって送られたテキストは、結果と共に返される。
ORU（到着確認／検査結果）メッセージでは、採取管番号。複数採取管の時は、採取管数を
OBR-37で指定する。
OBR-19 Placer Field #2 依頼者フィールド＃2 (ST)
定義： 依頼者フィールド＃1に類似。

00252

OBR-20 Filler Field #1 実施者フィールド＃1 (ST) 00253
定義： 実施者(診断サービス)により任意の使用目的に定義可能。
ORU（到着確認／検査結果）メッセージでは、検体到着順番号。検体の物流把握や検査報告の時刻予測等に使う。
OBR-21 Filler Field #2 実施者フィールド＃2 (ST) 00254
定義： 実施者フィールド＃1に類似（実施者により任意の使用目的に定義可能）。
OBR-22 Results Rpt/Status Cheng - Date/Time 結果報告/状態変更−日時 (TS) 00255
定義： 結果の報告日時、あるいは状態の変更日時。このフィールドでは、結果を報告書に書込み・発行した日時を示す。あるいはオーダー状態に定義にされたような状態が入力・変更された日時を示す。通常、依頼側は最後に結果を受信した日時(前回更新日)より後で報告された結果だけ入力すべきである。(電文発信日ではない)
OBR-23 Charge To Practice 課金 (CM) 00256
HISは検査項目から課金情報を生成する。
OBR-24 Diagnostic Serv Sect ID 診断サービス部門ID (ID) 00257
定義： 診断を実施した診断サービス部門。検査が外部サービスによって実施された場合、そのサービスのIDがここに記録される。採りうる値については、HL7テーブル0074−診断サービス部門ID−を参照のこと。外注先検査センターをセットする。
テーブル 0074 - Diagnostic service section ID
Value
AU
BG
BLB
CUS
CTH
CT
CH
CP
EC
EN
HM
ICU
IMM
LAB
MB
MCB
MYC
NMS
NMR
NRS

Description
Audiology
Blood gases
Blood bank
Cardiac UltrasoundCardiac catheterization
CAT scanChemistry
Cytopathology
Electrocardiac (e.g., EKG, EEC, Holter)
Electroneuro (EEG, EMG,EP,PSG)
Hematology
Bedside ICU Monitoring
Immunology
Laboratory
Microbiology
Mycobacteriology
Mycology
Nuclear medicine scan
Nuclear magnetic resonanceNursing service measures

Copyright©2002 JAHIS V2.0

Value
OUS
OT
OTH
OSL
PHR
PT
PHY
PF
RAD
RX
RUS
RC
RT
SR
SP
TX
VUS
VR
XRC

115

診断サービス部門ID

Description
OB UltrasoundOccupational Therapy
Other
Outside Lab
Pharmacy
Physical Therapy
Physician (Hx. Dx, admission note, etc.l)
Pulmonary function
Radiology
RadiographRadiology ultrasoundRespiratory Care (therapy)
Radiation therapy
Serology
Surgidal Pathology
Toxicology
Vascular UltrasoundVirology
Cineradiograph

JHLDEX20.DOC 2002/06/26

OBR-25 Result Status 結果状態 (ID) 00258
定義： このオーダーの結果状態。状態は、オーダーに関連する結果すべてに適用される。
オーダー状態の照会のさい、OBXセグメントで実現されるレベルの応答より詳細なレベルの応答が必要でないときに、このフィールドがよく使用される。このフィールドへは、実施者
しか値を設定することができない。各結果の状態が必要な場合、OBX−11−検査結果状態を使用することができる。採りうる値については、HL7テーブル0123−結果状態−を参照のこと。
テーブル 0123 - Result status 結果状態
Value Description
O
Order received; specimen not yet received オーダー受信；検体未到着
I
No results available; specimen received, procedure incomplete 結果無効；検体到着、手続き不完全S
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
Results stored; not yet verified 結果ストア；未確認FFinal results; results stored and verified. Can only be changed with a corrected result. 最終結果；結果格納・確認済。
訂正結果のみ書き換え可能
X
No results available; Order canceled. 結果無効；オーダーキャンセル
Y
No order on record for this test. (Used only on queries) オーダーによらない検査結果(参照のみ可能)
Z
No record of this patient. (Used only on queries) 患者に対する結果なし(参照のみ可能)

到着確認時 ‘Ｉ 、部分結果報告時 ‘A’、未承認結果報告時 ‘R’、最終結果報告時 ‘F’とする
OBR-26 Parent Result 親結果 (CM) 00259
成分: <OBX-3-observation identifier of parent result> ^ <OBX-4-sub-ID of parent result> ^<OBX-5-observation results from parent (CE)>
定義： このフィールドは他のタイプ(たとえば毒物学)との連携を可能にするために定義される。この重要な情報は、OBR-29-親番号の情報と組み合わせて、このオーダーに関する親結果のOBXセグメントを一意に識別する。親結果内のOBXセグメント値は、この検査セットが報告する生物や化学種を示す。たとえば、現在の検査セットが感受性試験である場合、親結果の一意なOBXは、この感受性試験の対象となる生物である。親結果内の生物名が最終的に決定される前にいくつか変遷をたどることがあるので、この間接的な連係を使用するとよい。
第3成分には直接親結果の微生物名を記録する。この場合の生物は、親培養検査の結果どおりに記載すべきである。
このフィールドは、親結果がOBR-29-親番号によって識別される場合のみ必要になる。
標準に検査結果セグメント(OBX)を使用してこの情報を伝達する方法もある。生物が複数存在する場合、OBX−4−サブIDで複数の生物種から個々を識別する。この場合、サブID Nを持つ最初のOBXは、N番目の微生物を識別する値を持つ。また、サブID Nを持つ後続のOBXはそれぞれ、この生物の感受性試験に使用する感受性値を持つ。
OBR-27 Quantity/Timing 数量/タイミング (TQ) 00221
定義： 1回のサービスで施すサービスの数、そのサービスの繰り返し数に関する情報。これにより要求の継続時間を固定する。数量/タイミング解説参照。
成分: <数量(CQ)>＾<時間間隔(CQ)>＾<継続時間>＾＾＾<優先度(ID)>＾＾<テキスト(TX)>
第1成分には、該当する検査オーダに必要な数量（採取量etc）を指定する。成分中は「<数量>&<単位>」から構成される。間隔を持つ複数の検査指示の場合はその１回分についてを指示ずる。
「繰
第2成分は「<繰り返しパターン>&<明確な時間間隔>」から構成され、時間の間隔を表現する。
り返しパターン」は、１日における回数を主に表す用時コード。採取間隔の表現に用いる。
複数のコードの組み合わせには、空白文字１文字で区切って並べる。(使用者定義テーブル
0335−繰り返しパターン参照)。「明確な時間間隔」は、採取の具体的な時刻等をカンマ区切
りで複数個格納する。
第3成分は該当する検査オーダが実施される期間を指定する。
第6該当す成分はる検査の優先度を指定する。
第8成分は指示の完全なテキスト。
OBR-28 Result Copies To 結果配布先 (XCN) 00260
定義： 検査報告書を受け取る人。ローカルの取り決めによって、ID番号あるいは名前のいずれかを省略してもよい。報告書送付先として科別や病棟を指示してもよい。

Copyright©2002 JAHIS V2.0

116

JHLDEX20.DOC 2002/06/26

OBR-29 Parent Number 親番号 (CM) 00261
定義： ORC−8−親と同一。但し、ORUメッセージ（到着確認／検査結果）では、ORMメ
ッセージのORC-2(,ORC-3)と同一。 ＬＩＳ内での受付時はORUメッセージのORC-2と同一。
親子関係が存在する場合、このフィールドにより子供をその親に関連づける。たとえば、前回の検査(たとえば血液培養で展開された抗生物質感受性)によって展開された検査は、このフィールドに親(血液培養)の実施者オーダー番号を記録する必要がある。子オーダーの場合に、
このフィールドが必要になる。
親フィールドには、成分が2つある。第1成分には親の依頼者オーダー番号が入る。第2成分はオプションであり、ここには親の実施者オーダー番号が入る。このフィールドは、副成分をもつ、依頼者オーダー番号成分と実施者オーダー番号成分の2つの成分で伝達される。
OBR-30 Transportation Mode 患者移動モード (ID) 00262
定義： 適用可能な場合、患者を移動するかどうか(あるいは移動方法)。採りうる値に関しては、HL7テーブル0124−患者移動モード−を参照のこと
テーブル 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 車いすを使用する

OBR-31 Reason For Study 検査理由 (CE) 00263
定義： 適切な回答をうるのにこのフィールドを使用しなければならない検査もある。
OBR-32 Principal Result Interpreter 結果判定責任者 ( CM) 00264
定義： 検査を診断し、報告書の内容に責任を負う医師あるいは臨床医のID。
OBR-33 Assistant Result Interpreter 結果判定アシスタント ( CM)
定義： この検査の診断を支援した立会臨床医。
OBR-34 Technician 医療技術者 ( CM)
定義： 実施担当臨床技師。

00265

00266

OBR-35 Transcriptionist 口述筆記者 ( CM) 00267
定義： 報告書の口述筆記を担当する人、通常は本フィールドは使用しない。
OBR-36 Scheduled - Date/Time スケジュール日時 (TS) 00268
定義： 実施者がスケジュールした検査日時。このフィールドは、ある特定の検査をスケジュールして欲しいという要求に対する結果を表しており、これによりスケジュールされた検査日時を依頼者に通知することができる(結果専用)。
OBR-37 Number Of Sample Containers 検体容器数 (NM) 01028
定義：受領検体容器の数。検体受領の検証のために使用、オーダーの全検体数とは異なるかもしれない。同一検体・同一採取管での採取量オーバーフロー時の採取管本数を記述する。
記述なしの場合を含め、通常は１と解釈する。
OBR-38 Transport Logistics Of Collected Sample 採取検体搬送 (CE) 01029
定義：このフィールドは診断サービス実施者への検体到着で意味がある。これにより検査ス
ケジュールや結果に要する期間などが可能となる。例えば定期トラック便、郵便など。
OBR-39 Collector's Comment 採取者コメント (CE) 01030
定義：検体に関する付加的コメント、例えば｢変性により凝固困難｣、｢-15℃にて凍結｣。検体採取時のコメントを記述する。
OBR-40 Transport Arrangement Responsibility 搬送調整者 (CE) 01031
定義：予約検査などで検体搬送の手配などを行った者。例えば依頼者、実施者、患者など。
OBR-41 Transport Arranged 搬送調整結果 (ID)
定義：検体搬送手配の結果状態。

Copyright©2002 JAHIS V2.0

01032

117

JHLDEX20.DOC 2002/06/26

テーブル 0224 - Transport Arranged 搬送調整
Value
A
N
U

Description
Arranged
手配済み
Not Arranged 未手配
Unknown
不明

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

Description
Required必要
Not Required 不要
Unknown
不明

OBR-43 Planned Patient Transport Comment 患者搬送コメント (CE) 01034
定義：患者が診断サービス部門へ出向く際の搬送や随行に関するコメント。
OBR-44

Procedure code 手続きコード (CE)00393

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義： このフィールドのもしあればフィールド４において報告された汎用サービスＩＤと共に関連した手続きに割り当てられた唯一の識別子である。使用者定義テーブル 0088−手続き
コード（HL7-節 6.5.4.3 参照）に定義されたテーブルの値を使用される。このフィールドは，臨床関連のシステムと互換性を取る為ＣＥタイプである。
OBR-45

Procedure code modifier 手続きコード修飾子

(CE)

01316

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドはフィールド 44 において報告された手続きコードに適用できれば手続
きコード修飾子を含む。手続きコード修飾子は、HCFA や AMA のような監督官庁によって定義される。 多重修飾子は、報告される場合もある。
参照：使用者定義ﾃｰﾌﾞﾙ 0340 - Procedure code modifier for suggested values(HL7-節 6.5.4.16 参照)
OBR-46

Placer supplemental service information 依頼者補給サービス情報 (CE)01474

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

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

01475<identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>

定義：このフィールドは、OBR-4 汎用サービス ID によって報告された処置コードにより依頼者システムから実施者システムに送られる補給サービス情報として使われる。このフィー
ルドは OBR セグメントの他の不明なオーダ詳細情報を解決する為に使われる。典型的に、それは OBR-46 依頼者補給情報により実施者システムに反映される、そのオーダが修正されない限り実施者システムは実際にこれを用いて遂行された物のどちらかのケースを報告するのに使われる。多重補給サービス情報要素は報告される。

Copyright©2002 JAHIS V2.0

118

JHLDEX20.DOC 2002/06/26

参照：使用者定義テーブル 0411 - Supplemental service information values.
このフィールドは、検査が右、または、左に行われるべきであるかどうかのような詳細について述べるために使われ得る。 例えば、腕の治療及びオーダは右か左かを区別しないし、その治療が対比されるかに関わらない（オーダ基本ファイルがそのような区別をしないとき）。
使用者定義テーブル 0411 - Supplemental service information values
Value

Description
No suggested values
Individual implementations may use vocabularies such as the
SNOMED DICOM Micro-glossary (SDM) or private (local) entries.
特別な導入では SNOMED や DICOM，マイクログロッサリ，そして私用な物も用いられる

Copyright©2002 JAHIS V2.0

119

JHLDEX20.DOC 2002/06/26

7.9 OBX - Observation/Result Segment

検査結果セグメント

OBX セグメントは単一検査あるいは部分検査を転送するのに使用される。それは分割不可能なレポートの最小単位に相当する。その構造を図 7−9 に要約する。
その主な機能はレポート・メッセージで検査関連情報を伝達することである。しかし、OBX を検査オーダーに含めることもできる。この場合、実施者が作成する検査結果を解釈できるように、実施者が必要とする臨床情報を OBX で伝送する。たとえば、血液酸素を血液ガス検査室へオーダーする場合に吸気酸素を報告するのに OBX は必要であり、あるいはパップ試験を細胞診検査室へオーダーする場合に含まれているべき月経周期情報を報告するためにも OBX は必要である。また OBR で多項目検査の内容が不明
確な場合、OBX で個々の検査項目を指示することも可能である。例えば OBR で肝炎セット、OBX で
GOT,GPT,HBs 抗体や、OBR で 100g 糖負荷試験、OBX で血糖前値,血糖 30 分値など。また、検査結果
コメントをセットしたい場合検査結果コメントの扱いを参照。
OBX属性
SEQ

LEN

DT

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

SI
ID
CE
ST
*
CE
ST
ID
NM
ID
ID
TS
ST
TS
CE
XCN
CE
EI
TS

OP
T
O
R
R
C
C
O
O
O
O
O
R
O
O
O
O
O
O
O
O

Japan
O
R
R
C
C
O
O
O
O
O
R
O
O
O
O
O
O
O
O

RP/#

Y

Y/5
Y

Y
Y

ITEM#

ELEMENT NAME

NOTE

00569
00570
00571
00572
00573
00574
00575
00576
00577
00578
00579
00580
00581
00582
00583
00584
00936
01479
01480

Set ID – Observational SimpleセットID ― 単純検査
Value Type 値型
Observation Identifier 検査項目
Observation Sub-ID 検査副ID
Observation Value 検査値
Units 単位
References Range 基準値範囲
Abnormal Flags 異常フラグ
Probability 確率
Nature of Abnormal Test 異常検査の性質
Observ Result Status 検査結果状態
Date Last Obs Normal Values 最終検査正常値日付
User Defined Access Checks 使用者定義アクセス点検
Date/Time of the Observation 検査日時
Producer's ID 実施者ID
Responsible Observer 検査責任者
Observation Method 検査方法
Equipment Instunce Identifier 装置コード
Date/Time of the Analysis 分析日付

検査結果コメントの例
検査材料、検査方法、検査結果への補足、検査できなかったことへの説明、などのコメントは検査結果のOBX に続く OBX で表現する。コメントの値型は ST や TX が代表的と考えられるがコメントコードでの運用しか出来ない場合は二者間の協議で値型 CE でコードでの運用も可能である。出来る限りコメント内
容に制限のないフリーテキストを推奨する。
ＭＥＤＩＳ−ＤＣ臨床検査データ交換規約暫定版では統一結果コメントを定めていたのでその場合のsuffix も参考にされたい。下記はその例である。
OBX||NM|3A016000002327101^A/G 比^JC10||2.33||1.30-2.00|H|||F
検査結果
OBX||CE|3A016000002327101&TCM^^JC10||E01^参考値です^L||||||F
そのコメントOBXフィールド定義
OBX-1 Set ID - Observation Simple セットID-単純検査 (SI) 00569
定義： 同一のOBRセグメントに対し１から付番される通し番号。ASTMとの互換性を維持するためのもの
複数検体時の上位ＯＢＲに対する通番。初期値１、増分１。
OBX-2 Value Type値型 (ID) 00570
定義: OBX内の検査結果値のフォーマット。値がCEである場合､結果はコード化入力値でなければならない。値型がTXまたはFTである場合、結果はテキスト群である。値型の検査で採り

Copyright©2002 JAHIS V2.0

120

JHLDEX20.DOC 2002/06/26

うる値はHL7テーブル0125-値型に列記される(5.4データ型を参照)。たとえば、PNは成分区切
り文字により分離した6つの成分から成る。NMは有効な型であるが、通常数字として報告される検査では、結果の一部として非数値文字が報告されることが多いので(結果が測定器で計りきれないことを示すために>300を使う場合など)、文字列(ST)データ型を持つことがある。
たとえば">300"では、">"は記号であり桁"300"は数値と考えられる。
以下を除くすべてのHL7データ型が有効である｡
CM: 特定のデータ型でないから､
CQ: OBX-5-検査値の単位は、OBX-6-単位に必ず明示的に指定されるから､SIシーケンスID: HL7メッセージセグメント以外に適用されないから｡
実際の検査値がOBXでは送られていないが、他のどこかに存在する場合、RP値(参照ポインタ)を使用しなければならない。たとえば、検査が画像(ドキュメント関連画像あるいは医学関連
画像)から成る場合、画像そのものはOBXで送ることができない。その場合送信システムは、
参照ポインタを送信するよう選択することができる。受信システム側は、ACR-NEMAなどの他の標準インターフェースにより、あるいは適切なデータベースサーバーにより実際の画像へアクセスする必要がある場合は、いつでもこの参照ポインタを使用することができる。
テーブル 0125 - Value type 値型
Value
AD
CE
CF
CK
CN
CP
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
Composite ID And Name
Composite Price
Extended Composite ID With Check Digit
Date
Encapsulated Data
Formatted Text (Display)
Money
Numeric
Person Name
Reference Pointer
Structured Numeric
String Data.
Time
Telephone NumberTime Stamp (Date & Time)
Text Data (Display)
Extended Address
Extended Composite Name And Number For Persons
Extended Composite Name And Number For Organizations
Extended Person Number
Extended Telecommunications Number

値型の構成成分については 6.4 データ型を参照のこと
OBX-3 Observation Identifier 検査項目ID (CE)00571

成分: 〈識別子〉＾〈テキスト〉＾〈コーディング方式名〉＾〈代替識別子〉＾〈代替テキスト〉＾〈代替コーディ
ング方式名〉

定義： 検査項目を表す一意な識別子。例：5F190143002315151^HSV-1抗原。日本臨床病理学
会臨床検査項目分類コード体系に則りコーディングされた検査項目コードを使用(結果識別も含む)。検査結果コメントをセットする場合検査項目IDを接尾辞で修飾したコードを用いる。
検査結果コメントの扱いを参照。
大半のシステムでは、識別子は受信システムが検査情報を処理するために、他の検査属性を列記した検査項目マスタテーブルを参照するために使用される。検査IDと検査項目マスター
テーブルとの関係は、請求記録中の課金コードと課金マスターテーブルの関係に類似している。
このフィールドの第1識別子にローカルコードを使用する場合、普遍的な識別子もあわせて送信することを強く推奨する。それにより、様々な提供者が同じサービスについてそれぞれ結果を送信してきた場合(たとえば病院検査室と検査センターが老人ホームに生化学データを報告してきた場合)、受信側でそれらの結果を同じにすることができる。使用できる 普遍的な識別子には、国内においては前述の日本臨床病理学会のコードがあり、米国においてはLOINC
コードがあり検体検査結果と生理的変数(たとえば血圧、脈拍)が包含されている。神経生理学

Copyright©2002 JAHIS V2.0

121

JHLDEX20.DOC 2002/06/26

検査に関しては、｢波形結果データ型｣およびASTM E1467の附属書X2を参照すること。
本規約では以下の使用とする。
成分：<検査項目コード>＾<テキスト>＾JC10
定義：OBRセグメントにて指定した検体の検査項目を指定する。コードには日本臨床病理学
会臨床検査項目分類コードを用いる。
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セグ
メントを一意に識別することができる。
サブ識別子は、外科病理学などのレポートで関連成分をグループ化するのにも使われる。外科病理学レポートでは、1回の手術により得られた組織をすべて1つのレポートにまとめるということは昔からよくある。胆嚢および虫垂の検査を記述した単一の外科病理学レポートを考えてみる。このレポートは概ね図7−10に示すように転送されるだろう。
図 7-10. Example of sub-identifier usage
OBR|1|||88304&SURG PATH REPORT...
OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM...
OBX|2|TX|88304&GDT|1|THIS IS A NORMAL GALLBLADDER...
OBX|3|TX|88304&MDT|1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLYNORMAL GALLBLADDER TISSUE...
OBX|4|CE|88364&IMP|1|M-00100^NML^SNM...
OBX|5|CE|88304&ANT|2|T66000^APPENDIX^SNM...
OBX|6|TX|88304&GDT|2|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX...
OBX|7|TX|88304&MDT|2|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORYCHANGE...
OBX|8|CE|88304&IMP|2|M-40000^INFLAMMATION NOS^SNM...

図7-10の例では、レポートの各成分に対して2つのセグメントがある(2つある組織のそれぞれに対して1つのセグメント)。このように、88304&ANTセグメントが2個存在する；88304&GDT
セグメントが2個存在する。88304&MDTセグメントが2個存在する。胆嚢に適用されるセグメ
ントはすべてサブ識別子として1を持つ。虫垂に適用されるセグメントはすべてサブ識別子｢2｣を持つ。
検査サブIDはその他の目的でグループ化する場合にも使用できる。それはいくつかの種類の体液摂取及び排泄のレポートを編成するのに使用することができる。たとえば、複数の静脈より採血を実施した場合、それぞれ、多くの個別の検査(OBXセグメント)、採取量、採取の型(血液、D5W、血漿など)、静脈の部位などが必要になる。つまりそれぞれの部位ごとに個別の
OBXセグメントを必要とする。複数の静脈部位による場合、HL7では、第1の静脈部位に関係するOBXセグメントすべてに検査サブID｢1｣を割り当てることにより、それらのOBXセグメン
トを論理上リンクすることができる。同様に、サブID2を割り当てることにより、第2の静脈部位に関して、すべてのOBXをリンクすることができる。複数の外科的ドレインが存在する
場合に、その排泄に対しても同様のことができる。複数指定する必要がない場合、nullか1を使用すること。
OBX-5 Observation Value 検査結果値 (*) 00573
定義： 検査実施者により検査された検査結果値。検査結果値はこのセグメント中のOBX−2−値型で設定されるデータ型に応じて表記される。このフィールドはOBXセグメントの必須
フィールドである。数値なのかあるいは短いテキストなのかどうかに拘らず、回答はASCII
文字コードで記録されるものとする。
数値型の検査結果であっても比較演算子や接尾辞を持つ場合、値型が文字列STの場合と構造化数値SNの場合によって、検査結果値の表記が異なるので注意、例えば、ST型では100以上( >100 )や 2+であるが、SN型では >^100 や ^2^+ となる。可能な限りSN型を使用することを推奨する。

Copyright©2002 JAHIS V2.0

122

JHLDEX20.DOC 2002/06/26

論理上独立している検査の報告
放射線検査や｢病歴・身体計測｣などの叙述的レポートの主要箇所は、個別のOBXセグメントとして報告される。また、論理上独立している個々の検査は、個別のOBXセグメントで報告すべきである；つまり、1個のOBXセグメントには、論理上独立している複数検査の 結果を含んではならない。この要求事項により、OBX−6−単位およびOBX−8−異常フラグ、およびOBX−9−確率の内容が明白に解釈ができるようになる。たとえば電解質およびバイタル
サイン・セットは、4つの個別のOBXセグメントとして報告されるだろう。2つの診断(うっ血性心不全と肺炎など)は、それが退院サマリの一部として報告されたのかあるいは胸部X線レ
ポートの一部として報告されたのかに拘らず、さらに2つの個別のOBXセグメントとして報告されるだろう。同様に、単一の細菌培養内で分離された2つの細菌性生物は、2つの個別のOBX
セグメントとして報告されるだろう。
1つのOBXセグメントで、独立した2つの診断 記述文 を報告することはできないが、2つの診断 記述文 がそれぞれ一部(修飾子)として一緒になって1つの診断記述文を構築するのであれば、定性値として複数回応答することができる(通常、反復区切り文字により分離されたCEデータ型として)。たとえば、右上葉(1つのコードとして記録される)と肺炎(別のコードとして記録される)の両方を1つのOBXセグメントで報告できるだろう。そのような複数の 値
は反復区切り文字により分離されるだろう。
共通の検査IDとサブIDを持つ複数のOBXセグメント
いくつかのシステムでは、単一の検査に複数データ型の 一部 が含まれることがある。よくある例は、数値結果の後にコード化注記(CE)が続くことである。この場合、論理検査情報
は複数のOBXセグメントで送ることができる。たとえば、あるセグメントは、数値結果を表すための数値データ型あるいは文字列データ型であるが、もう1つのセグメントはコード化注
記を表すCEデータ型である場合など。実施者が複数のコード化注記を報告しているとすると、その複数のコード化注記はすべて単一の論理検査情報を修正してしまうので、反復区切り文字で分離された1つのOBXセグメントで送信されるだろう。同じ検査IDとサブIDを持つ複数の
OBXセグメントは、最も重要なOBXセグメント(正常なフラグ/単位、および/あるいは、基準値および状態フラグを持つOBXセグメント)を最初に指定して、常に連続して送信すべきである。OBX6〜12の値は、同じOBX−3−検査項目とOBX−4−検査サブIDを持つ後続のOBXセグメントではnullとすべきである。置換または削除をする場合、同じ検査IDとサブIDを持つ複数のOBXセグメントは1単位として扱われる。どれか1つが置換または削除されると、すべてが置換される。
コード化値
OBXセグメントにCEデータ型の値が含まれる場合、検査はコードおよび(または)テキストの組み合わせとして保管される。(｢OBR 1｣の1番目と2番目のOBXセグメント、｢OBR 2｣の1番目と2番目のOBXセグメントに記述されている結果。)検査は、(推奨検査を表す)検査セット
ID、(診断を表す)診断コードか所見、または病理学レポートで使う部位、あるいは他の任意の種類のコード化結果などである。
コード化検査に保管された情報は必ずしもコード化する必要はない。たとえば、胸部X線診断がCEデータ型であったとしても、純粋テキストとして転送することができるだろう。この場
合は、たとえば以下のように記述して、 結果コード の第2成分としてテストを記録しなけ
ればならない。
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE.
しかし、個別の診断、指導などは、純粋テキストとして記録するとしても、個別の結果
セグメントに記録すべきである。すなわち、うっ血性心不全と肺炎は、
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|
ように送信するのでなく、以下のように送信すること。
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE|
OBX|2|CE|71020&IMP|2|^PNEUMONIA|.
テキスト記述(成分2)の代わりに、あるいはテキスト記述(成分2)に加えて、コンピューターが理解し得るコードを含む完全コード化結果(成分1)を送信すればさらによい。

Copyright©2002 JAHIS V2.0

123

JHLDEX20.DOC 2002/06/26

OBX-6 Units 単位 (CE) 00574
定義： 単位のデータ型はCEデータ型である。国内の臨床検査においては、現在普遍的な単位コード体系が定められていないので、検査結果に単位が付属する場合、必須フィールドとし、次のような成分で記載するものとする。
< 単位(ASCII)(ST) > ^ < 単位名称(漢字可)(ST) > ^ < コード体系名(L)(ST) >識別子成分またテキスト成分のいずれかは省略可能とする。
OBX-7 References Range 基準値範囲 (ST) 00575
Components: 数値型データの場合の書式は次のようである:a) lower limit-upper limit(when both lower and upper limits are defined, e.g.,
for potassium 3.5 - 4.5)b) > lower limit(if no upper limit, e.g., >10)c) < upper limit(if no lower limit, e.g., <15)
文字型データの場合: 正常値をこのフィールドに記載する。
定義： 検査で有毒物質の量を計測する場合、範囲の上限により毒性限界を表す。検査で薬剤の量を計測する場合、下限により治療の期待できる最小量を表し、上限によりそれ以上の薬剤投与により通常副作用が発生し得ることを表す。
OBX-8 Abnormal Flags 異常フラグ (ID) 00576
定義： 結果の正常状態を示すテーブルルックアップ。適用できる場合は、この値を送ることを強く推奨する。検査が抗生物質感受性の場合、解釈コードは次のとおりである： S＝敏感；R＝耐性；I＝中間；MS＝少し敏感；VS＝過敏。(詳細については、ASTM 1238−調査−を参照)。採りうる値については、使用者定義テーブル0078−異常フラグ−を参照。
検査室で、胸部X線あるいは微生物培養などのテキスト・レポートの正常状態を識別できる場
合、正常な場合はN、異常な場合はAとして報告すべきである。複数のコード(たとえば異常と悪化)を報告する場合は、反復区切り文字(たとえばA〜W)により分離されるだろう。
使用者定義テーブル 0078
Value
space
L
H
LL
HH
<
>
N
A
AA
null
U
D
B
W
S
R
I
MS
VS

Abnormal Flags 異常フラグ

Description
基準値内
Below low normal 基準値下限以下
Above high normal 基準値上限以上
Below lower panic limits パニック下限以下
Above upper panic limits パニック上限以上
Below absolute low-off instrument scale 測定限界下限未満
Above absolute high-off instrument scale 測定限界上限越Normal (applies to non-numeric results) 正常(非数値結果に適用)
Abnormal (applies to non-numeric results) 異常(非数値結果に適用)
Very abnormal (applies to non-numeric units, analagous to panic limits for numeric units) 非常に異常(数値単位のパニック値に対応するが、これは非数値単位に適用される)
No range defined, or normal ranges don't apply 範囲未定義、もしくは正常が適用されない
Significant change up 大幅な上昇変化
Significant change down 大幅な下降変化
Better--use when direction not relevant 改善 − 方向が適用されない場合使用
Worse--use when direction not relevant
悪化 − 方向が適用されない場合使用
For microbiology sensitivities only:微生物感受性の場合のみ
Sensitive 敏感
Resistant 耐性
Intermediate 中間
Moderately sensitive 少し敏感
Very sensitive
過敏OBX-9 Probability 確率 (NM) 00577
定義： 定性値を持つ結果の場合、結果が真である確率(結果が特定のコードとなる確率)。主として離散的コード化結果に適用される。0〜1(0と1を含む)のASCII文字列で表した10進数である。
OBX-10 Nature Of Abnormal Test 異常検査の特質 (ID) 00578
定義：判定の元になった集団を指示。 採りうるコードについては、HL7テーブル0080−異常検査の特質−を参照。

Copyright©2002 JAHIS V2.0

124

JHLDEX20.DOC 2002/06/26

テーブル 0080
Value
A
N
R
S

Nature Of Abnormal Testing 異常検査の特質

Description
An age-based population 年齢別集団
None - generic normal range 無し −A race-based population 人種別集団
A sex-based population 性別集団

一般正常範囲OBX-11 Observ Result Status 検査結果状態 (ID) 00579
定義： 採りうるコードについては、HL7テーブル0085−検査結果状態−を参照。このフィールドは、1つの検査項目についての、現在の結果完了状態を反映する。
検査依頼時に動的に検査要求を指定しなければならない場合、たとえば糖負荷試験におけるサンプリング時間（前、30、60、120分など）、OBXセグメントの結果状態を"O"とすること
でORMメッセージにおける検査項目の定義として使用できる。その場合検査項目は必須であるがOBX-2、OBX-5はNullである。
臨床検査依頼・到着確認メッセージでは、 O’のみ。
テーブル 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 theuniversal service ID in OBR-4 implies that it would be sought.
Order detail desctiption 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

OBX-12 Effective Date Last Obs Normal Value 最新正常値有効日付 (TS) 00580
定義： 測定方法の変更により、旧方式で得られた値が新規方式で得られた値と比較できな
くなる場合、そのような測定方法の変更などを表す。
正常値または単位がない場合null。存在する場合、記録日付と対応するこの日付の変更。新規
結果と旧結果を区別するためにローカルシステムで新規検査項目IDに現IDを割り当てるべきかどうかを判断できるよう、受信システムは、結果をマニュアルで見直すようトリガーをかけるべきであるOBX-13 User Defined Access Checks 使用者定義アクセス点検 (ST) 00581
定義： これにより実施者は、受信システムで検査を分類するのに使用する結果依存コードを記録できるようになる。
ほとんどの分類は固定の検査ID属性であり、関連検査マスタファイルで定義することができるので、このフィールドはめったに必要とされない。
しかし、受信システムが計算のやり直しを望まない場合がまれにあり、この場合そのような制御の仕方も検査結果値により変わることがある。たとえば抗酸菌感受性結果の場合である。
生物、検体採取部位、あるいは患者アレルギー状態に応じて、安価な抗生物質の感受性結果だけ表示したいと思う望むシステムもあるだろう。送信部門側では、特権ユーザ(たとえば感染症の専門医)はすべての結果を閲覧し、非特権ユーザは生物が反応した(敏感だった) 所望の 抗生物質だけを閲覧できるよう、すべての感受性を送信したいと思う。HL7では、その他のケースも生じると想定している。
OBX-14 Date-Time Of the Observation 検査日時 (TS) 00582
定義： 次の2つの状態で必要になる。まず、1つのレポートーヘッダー(OBR)の下で報告された複数の検査が互いに異なる日付を持つ場合である。これが起こりえるのは、同じセットのある測定と別の測定が異なる時間を持つ可能性がある、照会、負荷試験・シーケンス、あるいはクリアランス検査の場合である。
次に、OBXセグメントを依頼者から実施者へ送る場合にも検査日時は必要である。この場合

Copyright©2002 JAHIS V2.0

125

JHLDEX20.DOC 2002/06/26

には、転送中の検査の日付は要求検査の日付とは何の関係もないだろう。フランスでは慣例として、要求側部門が、新規セットの検査要求に加えて、1セットの最終検査結果を送る。こ
れらの検査の日付は実施者検査室にとって重要である。
どのような場合でも、検査日時は生理学的日時あるいは生理学的日時に最も近い日時である。
検体に対して行われるテストの場合は、該当日時は検体採集日時である。患者に対して直接行われる測定(たとえばX線画像、病歴、身体測定)の場合には、検査日時は測定が行われた日時である。
OBX-15 Producer's ID 実施者ID (CE) 00583
定義： 検査実施責任者の一意な識別子。たとえば検査結果が外部検査室により提供される
場合、実施者IDを明示的に報告すべきである。このフィールドがnullの場合、受信システム側
は、送信施設が検査を実施したと仮定する。外注先検査センターをセットする。
OBX-16 Responsible Observer 検査責任者 (XCN) 00584
定義： 要求された場合、検査に直接責任を負う個人(つまり検査を実行、もしくは検証した
人)の識別子。看護部門では、検査実施者は通常、検査(血圧測定)を実行した専門家である。
検査室では、検査実施者は解析を実行・検証した医療技術者である。検査実施者を表すコー
ドはCEデータ型として記録される。ローカル・コードとしてコードを送る場合、OBX−15−
実施者IDと組み合わせた時に、一意にして明白でなければならない。
OBX-17 Observation Method 検査方法 (CE) 00936
定義：検査項目案内などで公表している検査方法と異なる検査方法を実施した場合などはここに明示する。
OBX-18Equipment instance identifier 装置識別ＩＤ (EI) 01479
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>

定義：このフィールドは臨床検査に用いられる分析機の装置識別ＩＤである。 これは装置マスタ
ーリストのＩＤを指定するか空白を記述する、もしくは空白のときは生産者ＩＤ（OBX-15）を指定する。どの OBX で情報を転送することが考えられなくとも,装置タイプマスターリストからシ
リアル番号、その他は野情報を取り出せるようにすべきである。 このフィールドを繰り返すこと
は装置（最も低いレベル,第一）の階層型表現を認める。例えば、機器のモジュール、モジュールからなる機器、多重機器のクラス等。
OBX-19Date/time of the analysis 分析日付 (TS)01480

定義：このフィールドは、実装置ＩＤで指定された機器によって分析結果の世代と関連したタイムスタンプを転送する為に使われる。

Copyright©2002 JAHIS V2.0

126

JHLDEX20.DOC 2002/06/26

7.10 MSA - Message Acknowledgment Segmentメッセージ応答セグメント
MSA セグメントは、他のメッセージの肯定応答の特性を定義する。
MSA属性
SEQ
1
2
3
4
5
6

LEN
2
20
80
15
1
250

DT
ID
ST
ST
NM
ID
CE

OPT
R
R
O
O
B
O

Japan
R
R
O
O
O
O

RP/#

ITEM #
00018
00010
00020
00021
00022
00023

ELEMENT NAME
Acknowledgment Code 肯定応答ｺｰﾄﾞ
Message Control ID ﾒｯｾｰｼﾞ制御ID
Text Message ﾃｷｽﾄﾒｯｾｰｼﾞ
Expected Sequence Number 予想ｼｰｹﾝｽ
Delayed Acknowledgment Type 遅延肯定応答ﾀｲﾌﾟ
Error Condition ｴﾗｰ状態

NOTE

MSAフィールド定義
MSA-１ Acknowledgment Code 肯定応答ｺｰﾄﾞ 00018
定義： このフィールドでは肯定応答コードを含んでおり、メッセージ処理規則に従っている。
HL7テーブル0008−肯定応答コードを参照。
テーブル 0008 - Acknowledgment Code 肯定応答ﾀｲﾌﾟ
Value
AA
AE
AR
CA
CE
CR

Description
基本モード:アプリケーション受諾
拡張モード:アプリケーション肯定応答:受諾
基本モード:アプリケーションエラー
拡張モード:アプリケーション肯定応答:エラー
基本モード:アプリケーションリジェクト
拡張モード:アプリケーション肯定応答:リジェクト
拡張モード:受諾肯定応答:コミット受諾
拡張モード:受諾肯定応:コミットエラー
拡張モード:受諾肯定応:コミットリジェクト

MSA-2 Message Control IDメッセージ制御ID （ST） 00010
定義：このフィールドは送信システムから送られてきたメッセージのメッセージ制御IDを含んでいる。送信システムは、この応答と、それが目的とするメッセージを関連づける。
MSA-3 Text Message テキストメッセージ （ST） 00020
定義： エラー条件をより詳細に記述するオプションのテキストフィールド。このテキストは、
エラーログに印刷するか、あるいはエンドユーザに提示することができる。
MSA-4 Expected Sequence Number 次に来るべきシーケンス番号 （NM） 00021
定義： シーケンス番号プロトコルで使用するオプションの数値フィールド。
MSA-5 Delayed Acknowledgment Type 遅延肯定応答タイプ （ID） 00022
定義： このフィールドは下位互換性のためのものである。
テーブル 0102 - Delayed acknowledgment type 遅延肯定応答タイプ
Value
D
F

Description
メッセージが受領され、後の処理に備えて蓄積された処理の後の承認

MSA-6 Error Condition エラー条件 （CE） 00023
Components: <identifier (ID)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ID)> ^ <alternate text(ST)> ^ <name of alternate coding system (ST)>

定義：このフィールドは肯定応答システムがユーザ定義のエラーコードを使用し、ARタイプ
またはAEタイプの肯定応答をさらに規定することができる。このフィールドは、MSA-3−テ
キストメッセージの代わりに一般に使われる。
※エラーコードに関しては両者間で調整の上用いる。

Copyright©2002 JAHIS V2.0

127

JHLDEX20.DOC 2002/06/26

7.11 ERR - Error Segment エラーセグメント
ERR セグメントを使用して、エラーコメントを肯定応答メッセージに加える。
ERR属性
SEQ
1

LEN
80

DT
CM

OPT
R

Japan
R

RP/#
Y

TBL#

ITEM #
00024

ELEMENT NAME
Error Code and Location エラーコ
ードおよびロケーション

NOTE

ERRフィールド定義
ERR-1

Error Code and Location エラー・コードと位置 （CM）

00024

Components: <segment ID (ST)> ^ <sequence (NM)> ^ <field position (NM)> ^ <code identifying error (CE)>

定義：このフィールドは他のメッセージ内のエラーセグメントを識別する。セグメントIDタ
イプのセグメントが複数ある場合、第2成分はインデックスである。HL7コード化規則を使用しないシステムの場合、第3成分にデータ項目番号を使うことがある。第4成分はユーザ定義のエラーテーブルを参照し、現在副成分セパレーターがCEの成分セパレーターなので、どんな副成分を持ってもいけない。

Copyright©2002 JAHIS V2.0

128

JHLDEX20.DOC 2002/06/26

7.12 QRD – Query Definition Segment

問合せ定義セグメント

ＱＲＤセグメントを使用して問合せを定義する。応答では問い合わせメッセージの QRD セグメントを
エコーバックする。
QRD属性
SEQ
1
2
3
4
5
6
7
8
9
10

LEN
26
1
1
10
1
26
10
250
250
250

DT
TS
ID
ID
ST
ID
TS
CQ
XCN
CE
CE

OPT
R
R
R
R
O
O
R
R
R
R

Japan
R
R
R
R
N
N
R
R
R
R

RP/#

Y
Y
Y

ITEM#
00025
00026
00027
00028
00029
00030
00031
00032
00033
00034

11

20

CM

O

O

Y

00035

12

1

ID

O

O

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 照会結果レベル

00036

NOTE

QRDフィールド定義
QRD-1 Query Date/Time 問合せ日時（TS）00025
定義：このフィールドはアプリケーションプログラムが問合せを作成した日付を含んでいる。
QRD-2 Query Format Code 問合せフォーマットコード（ID）00026
定義：このフィールドでは、採りうるコードについては、HL7テーブル0106−問合せフォーマットコードを参照。
通常はR（診療記録用モード）を指定する。
テーブル0106− Query/Response Format Code
Value
D
R
Ｔ

問合せフォーマットコード

Description
応答が表示モードにある応答が診療記録用モードにある応答が表用フォーマットにある

QRD-3 Query Priority 問合せ優先度（ID）00027
定義：このフィールドは応答が期待される時間枠を含んでいる。採りうるコードについては、
HL7テーブル0091−問合せ優先度参照。テーブル値と以降のフィールドは、応答の時間枠を指定する。
D（遅延応答）はバッチ問合せ時に、ホスト側の処理の問題で即時応答が保証できない様な場合に使用する。応答日付／時間指定遅延応答は処理や運用が複雑になる可能性があり、通常は使用しない。
テーブル0091 - Query Priority 問合せ優先度
Value
D
I

QRD-4

Description
延引
即時Query ID 問合せID（ST）00028
定義：このフィールドはその問合せに対する一意な識別子を含んでいる。問合せアプリケー
ションが割り当てる。応答アプリケーションがそのまま返す。

Copyright©2002 JAHIS V2.0

129

JHLDEX20.DOC 2002/06/26

QRD-5 Deferred Response Type 遅延応答タイプ（ID）00029
定義：このフィールドでは採りうる値については、HL7テーブル0107−遅延応答タイプを参照。
QRD-3で記述した理由により通常は使用しない。
テーブル0107- Deferred Response Type 遅延応答タイプ
Value
B
L

Description指定された日付／時間の前に指定された日付／時間の後に

QRD-6 Deferred Response Date/Time 遅延応答日時（TS）00030
定義：このフィールドは遅延応答を送る前か後の日時を含んでいる。存在しない場合、応答は可能になった時点で送ることができる（上記QRD-5−遅延応答タイプを参照）。
QRD-3で記述した理由により通常は使用しない。
QRD-7 Quantity Limited Request 数量限定要求（CQ）00031
Components: <quantity (NM) ^ <units (CE)>

定義：このフィールドは要求システムが受諾できる応答の最大長を含んでいる。有効な応答は、第2成分内で指定した単位で与えられた数値である。採りうる値については、HL7テーブ
ル0126−数量限定要求を参照。デフォルトはLIである。
臨床検査システムにおいては通常RD（診療記録）を指定する。
テーブル0126- Quantity Limited Request 量限定要請
Value
CH
LI
PG
RD
ZO

QRD-8

Description
文字
行
ページ
診療記録
ローカルに定義される

Who Subject Filter 対象人物フィルタ（XCN）00032
Components: <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 the check digit scheme
employed(ID)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)>Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type(ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type(ID)>

定義：対象人物、つまりだれに関する問合せかを識別する。
通常の運用では次のフォーマットになる。
患者ID^姓^名
ここで、姓・名は半角カナ以外の文字とする。（２バイトコードも可）（注）このフィールドは繰り返し可であるが、複数の患者を指定した場合はQRD-10（対象部
門データコード）で指定する内容と各患者の対応が判別できなくなるため、このフィールドを用いて複数の患者を指定する場合はQRD-10を使用しないものとする。
QRD-9 What Subject Filter 対象主題フィルタ（CE）00033
Components: <identifier (ID)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier(ID)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>

定義：このフィールドは要求に応えるために必要な情報の種類を記述する。有効なコードはトランザクション問合せのタイプを定義し、実装時に施設で拡張することができる。
OSQメッセージ（オーダ照会）においてはORDを使用する。

Copyright©2002 JAHIS V2.0

130

JHLDEX20.DOC 2002/06/26

テーブル0048- What Subject Filter 対象主題フィルタ
Value
ADV
ANU
APN
APP
ARN
APM
APA
CAN
DEM
FIN
GOL
MRI
MRO
NCK
NSC
NST
ORD
OTH
PRB
PRO
RES
RAR
RER
RDR
RGR
ROR
SAL
SBK
SBL
SOP
SSA
SSR
STA
VXI

Description
助言／診断
看護ユニットルックアップ（ベッドにいる患者を返す。空きベッドは除く）
患者名ルックアップ
医師ルックアップ
看護ユニットルックアップ（ベッドの患者を返す。空きベッドも含む）
カルテ番号問合せ。そのカルテ番号の受付け番号を返す。
口座番号問合せ。一致した受付け番号を返す。
取り消し。問合せを取り消すために使用される。
デモグラフィックス
財務目標
最も最近の入院患者
最も最近の来院患者
ネットワーク時刻
ネットワーク状態変更
ネットワーク統計
オーダ
他
問題
手順
結果
処方管理情報
処方コード化オーダ情報
処方調剤情報
処方投与情報
処方箋情報
すべての予約関連情報。空いた予約枠、予約された予約枠、予約停止枠予約枠を含む識別された予定における予約された予約枠識別された予定における予約停止枠予約枠識別された予定における空いた予約枠
単一の予約に利用できる時間予約枠
再度の予約に利用できる時間予約枠
状態
予防接種情報QRD-10 What Department Data Code 対象部門データコード（CE）00034
Components: <identifier (ID)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ID)>^ <alternate text (ST)> ^ <name of alternate coding system (ST)>

定義：このフィールドは検査番号、手順番号、薬剤コード、項目番号、オーダ番号などが指定可能である。このフィールドの内容は、直前のフィールドの内容により決定される。このフィールドには、反復区切り文字で区切ることにより、複数の発生を含むことができる。
本フィールドには、原則としてORC-2（依頼者番号）を指定するものとする。
検体番号等でやり取りする必要がある場合には、HIS側−LIS側両者で話し合って内容を決めておくこと。
QRD-11 What Data Code Value Qual. 対象データ・コード値修飾子（CM）00035
Components: <first data code value (ST)> ^ <last data code value (ST)>

定義：このフィールドは対象データコード値修飾子を含んでいる。その問合せをさらに規定するウィンドウまたは範囲。このフィールドには、成分セパレーターによって区切られた開始／停止が含まれることがある。
QRD-10で指定する番号の範囲指定はこのフィールドで行う。
QRD-12 Query Results level 結果レベル（ID）00036
定義：このフィールドは結果の詳細レベルを制御するのに使用する。採りうるコードについては、HL7テーブル0108−問合せ結果レベルを参照。

Copyright©2002 JAHIS V2.0

131

JHLDEX20.DOC 2002/06/26

臨床検査依頼照会では通常はO（オーダとオーダ状態）を指定する。
臨床検査結果照会では通常はT（すべての結果）を指定する。
テーブル0108- Query Results level 問合せ結果レベル
Value
O
R
S
T

Description
オーダとオーダ状態
長文を除いた結果
状態のみ
すべての結果Copyright©2002 JAHIS V2.0

132

JHLDEX20.DOC 2002/06/26

問合せフィルタセグメント

7.13 QRF – Query Filter Segment

ＱＲＦセグメントはＱＲＤセグメントとともに使用し、問合せの内容をさらに細かくする。応答では問い合わせメッセージの QRF セグメントをエコーバックする。
QRF属性
SEQ
1
2
3
4
5
6
7

LEN
20
26
26
60
60
12
12

DT
ST
TS
TS
ST
ST
ID
ID

OPT
R
O
O
O
O
O
O

Japan
R
O
O
N
N
O
O

RP/#
Y

8
9

12
60

ID
TQ

O
O

O
O

Y

00044
00694

10

10

NM

O

Ｏ

Ｙ

01442

Y
Y
Y
Y

ITEM#
00037
00038
00039
00040
00041
00042
00043

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 Quantity/Timing Qualifier 数量/タイミング修
飾子
Search Confidence Threshold

NOTE

サーチ範囲

QRFフィールド定義
QRF-1 Where Subject Filter 対象場所フィルタ（ST）00037
定義：このフィールドはその問合せが関連する部門、システム、サブシステムを識別する。
このフィールドは、LAB~HEMOなどのように繰り返すことができる。
QRF-2 When Data Start Date/Time 対象データ開始日時（TS）00038
定義：このフィールドは対象となるデータの開始日時の情報を含んでいる。ここで指定した値も含む。
QRF-3 When Data End Date/Time 対象データ終了日時（TS）00039
定義：このフィールドは対象となるデータの終了日時の情報を含んでいる。ここで指定した値も含む。
QRF-4 What User Qualifier 対象ユーザ修飾子（ST）00040
定義：このフィールドは関心データの特性をさらに定義する識別子を含んでいる。
通常は本フィールドは使用しない。
QRF-5 Other QRY Subject Filter 他のQRY対象フィルター（ST）00041
定義：このフィールドは2つのシステム間で使用する施設定義のフィルターを含んでいる。このフィルターは、関係するアプリケーションや施設に対し特定の意味を持つコードとフィールド定義を使用する。
通常は本フィールドは使用しない。
QRF-6 Which Date/Time Qualifier 対象日時修飾子（ID）00042
定義：このフィールドはQRF-2−対象データ開始日時とQRF-3−対象データ終了日時で参照される日付のタイプを指定する。
臨床検査依頼照会では通常はSCHD（予定日時）を指定する。
テーブル0156- Which Date/Time Qualifier 対象日時修飾子
Value
ANY
COL
ORD
RCT
REP
SCHED

Description
範囲内の任意の日時
収集日時。フィルムまたはサンプル収集日時と同等
オーダ日時
取り消し日時。検体受領日時。臨床検査部門での検体の受領
結果報告日時。臨床検査部門での報告日時
予定日時

Copyright©2002 JAHIS V2.0

133

JHLDEX20.DOC 2002/06/26

QRF-7 Which Date/Time Status Qualifier 対象日時状況修飾子（ID）00043
定義：このフィールドはQRF-2−対象データ開始日時およびQRF-3対象データ終了日時により定義された日付範囲で選択した対象の状況のタイプを示す。
通常はANY（任意の状態）を指定する。
テーブル0157- Which Date/Time Status Qualifier 対象日時状況修飾子
Value
ANY
CFN
COR
FIN
PRE
REP

Description
任意の状態
現在の最終値。最終か修正かを問わない。
修正のみ（修正付きの最終なし）
最終のみ（修正なし）
予備報告完了日時QRF-8 Date/Time Selection Qualifier 日時選択修飾子（ID）00044
定義：このフィールドはその日時範囲で特定のタイプの値が指定できる。
通常はREV（範囲内の全ての値）を指定する。
テーブル0158- Date/Time Selection Qualifier 日時選択資格要素
Value
1ST
ALL
LST
REV

Description
範囲内の最初の値
範囲内のすべての値
範囲内の最終値
範囲内のすべての値であって、日時の逆順に返されたもの（別途指示がないかぎりこれがデフォルトである）

QRF-9 When Quantity/Timing Qualifier タイミング／量修飾のとき（TQ）00694
Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration> ^ <start date/time (TS)> ^ <end date/time (TS)>^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <order sequencing>

定義：このフィールドによって、間隔定義が使用され問合せに対する多重応答を指定することができる。この実施者を追加すると、新しい問合せ使用は、「QRF-2−データ開始日付／時
間の時」および「QRF-3−データ終了日付／時間の時」を将来の導入において使用できなくな
る。
QRF-10

Search confidence threshold サーチ範囲 (NM)01442

定義: このフィールドは、条件に合った敷値を確立した、数値を含んでいる。この値は応答システムの条件に合った患者のレコードを返すとき、利用される。
例: |0.50| or |8.25|
オプションフィールドの使い方として、検索システムが患者とのマッチ数を採用する数値アルゴ
リズムを潜在的に決定する。

Copyright©2002 JAHIS V2.0

134

JHLDEX20.DOC 2002/06/26

7.14

DSC - Continuation Pointer Segment 継続ポインタセグメント
DSCセグメントは継続プロトコルで使われる。
DSC属性

SEQ
1
2

LEN
180
１

DT
ST
ID

OPT
Ｏ
Ｏ

Japan
O
Ｏ

RP/#

ITEM#
00014
01354

ELEMENT NAME
Continuation Pointer 継続ポインタ
Continuation Style 継続形体

NOTE

DSCフィールド定義
DSC-1

Continuation Pointer 継続ポインタ （ST）

00014

定義：このフィールドは継続ポインタを含んでいる。最初の問合せではこのフィールドはnullである。その応答システムがnull値を返すか、または存在しない場合は、継続要求に応えるためのデータがそれ以上存在しないということである。継続プロトコルは表示用メッセージと診療記録用メッセージどちらでも働くということに注意。
DSC-2

Continuation style

継続形体 (ID) 01354

定義: メッセージがばらばらの状態か、会話の途中のメッセージかを示す。5.6.3 章の会話型
応答メッセージの継続を参照）。
参照： HL7 ﾃｰﾌﾞﾙ 0398 – Continuation style code .
テーブル 0398 - Continuation style code

Copyright©2002 JAHIS V2.0

Value

Description

F

Fragmentation

I

Interactive Continuation

135

ばらばら
会話継続

JHLDEX20.DOC 2002/06/26

7.15 QAK- query acknowledgment segment 問合せ応答セグメント
QAK セグメントは問合せの応答と共に送られる情報である。QAK は ehnanced query に対する応答の中で必要とされるセグメントであるが、original mode query に対するどんな応答メッセージの中でも ERR セグメント(optional)の後にオプショナルセグメントとして表れてもよい。
QAK 属性
SEQ

LEN

DT

OPT

Japan

1

32

ST

C

C

2

2

ID

O

O

3

250

CE

O

4

10

NM

5

10

NM

6

10

NM

RP/#

TBL#

ITEM#

ELEMENT NAME

00696

Query Tag 問合せタグ

00708

Query Response Status

問合せ応答ステータス

O

01375

Message Query Name

メッセージ問合せ名

O

O

01434

Hit Count

O

O

01622

This payload

O

O

01623

Hits remaining

0208

NOTE

合致データトータル数
この応答中の合致データ数
残りの合致データ数

QAKフィールド定義
QAK-1

Query tag 問合せタグ (ST)00696

定義： 問合せを識別するために、問合せ側システムがこのフィールドに値を設定する。このフィールドは問合せメッセージと応答メッセージの組合せ照合に用いられる。もしこの値が存在す
るならば、応答システムは問合せ応答セグメント(QAK)の最初のフィールドとしてこの値を返す必要がある。このフィールドは MSA-2-message control ID とは異なる。その値はある問合せに関係した各メッセージ(すなわち、すべての継続するメッセージ)に対して一定である。一方、MSA-2-message control ID は継続するメッセージで変化するかもしれない。なぜなら、それは問合せ全体としてではなく独立したメッセージに関係するためである。original mode query の時、
QAK-1-Query Tag は使用しない。
QAK-2

Query response status 問合せ応答ステータス (ID)00708

定義： このフィールドは応答システムが正確な応答ステータスを返すためのものである。このフィールドは、特に問合せパラメータに合致するデータが見つからなかったが、エラーは発生しなかった場合に有効である。値はHL7 ﾃｰﾌﾞﾙ 0208 - Query response statusにて定義される。
テーブル 0208 - Query response status 問合せ応答ステータス

QAK-3

Value

Description

OK

Data found, no errors (this is the default)

NF

No data found, no errors

AE

Application error

AR

Application reject

Message query name メッセージ問合せ名 (CE) 01375
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
定義： このフィールドは問合せの名称を含む。これらの名称は、各機能ごとの章にて割当てられる。サイト固有のイベントの場合、問合せ名は”Z”で始まる。 使用者定義テーブル 0471 - Queryname を参照のこと。

Copyright©2002 JAHIS V2.0

136

JHLDEX20.DOC 2002/06/26

QAK-4

Hit Count Total 合致データトータル数 (NM)01434

定義： このフィールドが用いられる場合、このフィールドはサーバが検出した問合せに対する合致データのトータル数を含む。表形式の応答(tabular response)では、これは検出した列の数に相当する。その他の応答タイプでは、Conformance Statement にて 合致”の意味を定義する。
QAK-5

This payload この応答中の合致データ数 (NM) 01622
定義： このフィールドが用いられる場合、このフィールドはサーバがカレントの応答の中で送る合致データの数を含む。継続プロトコルが応答伝達に用いられる場合、この数は QAK-4-Hit
count total で送られる値とは一致しない。

QAK-6

Hits remaining 残りの合致データ数 (NM) 01623
定義： このフィールドが用いられる場合、このフィールドはサーバがまだ送っていない合致データの数を含む。このフィールドは、サーバが応答を伝達するのに継続プロトコルを用いる場合にのみ意味がある。

Copyright©2002 JAHIS V2.0

137

JHLDEX20.DOC 2002/06/26

7.16 QPD−query parameter definition 問合せパラメータ定義
QPD セグメントは問合せのパラメータを定義する。
QPD 属性
SEQ

LEN

DT

OPT

Japan

1

250

CE

R

R

C

C

2

32

ST

3…

256

varies

RP/#

TBL#

ITEM#

ELEMENT NAME

NOTE

0471

01375

Message Query Name (for HL7 trigger)メッセージ
問合せ名

00696

Query Tag

01435

User Parameters (in successive fields) ユーザ定義
パラメータ

問合せタグ

QPDフィールド定義
QPD-1

Message query name メッセージ問合せ名 (CE) 01375
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>
定義： 問合せの名称を記載する。これらの名称は、各機能に固有の章によって割当てられる。
それはこの問合せ名称とその Conformance Statement で 1 対 1 である。Conformance Statement
サイト固有の問合せ名称は、”Z”で始まること。
特に、Laboratory Automation System における検査依頼の問合せ/取得、検査結果の問合せ/取得に関するメッセージ問合せ名は以下を用いることを推奨する。
使用者定義テーブル 0471 – Query name 問合せ名称

QPD-2

Value

Description

ZOS

Lab Order Specimen Query 検体とキャリア情報をキーにした検査依頼情報の問合せ

ZRS

Lab Result Specimen Query 検体とキャリア情報をキーにした検査結果情報の問合せ

ZRD

Lab Result Requested Date/Time Query

Query tag (ST)検査依頼日時をキーにした検査結果情報の問合せ

00696

定義： 問合せを識別するために、問合せ側システムがこのフィールドに値を設定する。このフィールドは問合せメッセージと応答メッセージの組合せ照合に用いられる。もしこの値が存在す
るならば、応答システムは問合せ応答セグメント(QAK)の最初のフィールドとしてこの値を返す必要がある。このフィールドは MSA-2-message control ID とは異なる。その値はある問合せに関係した各メッセージ(すなわち、すべての継続するメッセージ)に対して一定である。一方、MSA-2-message control ID は継続するメッセージで変化するかもしれない。なぜなら、それは問合せ全体としてではなく独立したメッセージに関係するためである。
［実装時の配慮：あるソケット上で単純に問合せとその応答が返されるだけの場合には、実装においてこのフィールドは必ずしも必要でない。反対にたくさんの問合せ、応答、その他のメッセージが同一ソケット上で双方向に飛び交うような”非同期”の実装では、サーバがどの問合せに対して応答しているかをクライアントが把握するために、このフィールドは必要不可欠である。
］

QPD-3

User parameters (Varies)

01435

定義： これらの継続的なパラメータフィールドは、クライアントがサーバに送る値である。

Copyright©2002 JAHIS V2.0

138

JHLDEX20.DOC 2002/06/26

クライアントデータは、HL7 フィールドのシーケンスとして表現される。最初は QRD-3 からその最後のフィールドまでがユーザパラメータデータとして伝達される。各 QPD ユーザ定義パラメータフィールドは、Conformance Statement で定義された１つのパラメータに相当する。
Conformance Statement には、各パラメータのデータタイプ、オプショナリティ、反復制限が記載される。これらのパラメータは通常”AND”で解釈されるが、一方ユーザはそれぞれのパラメー
タを正確に解釈するために、Conformance Statement を確認しなければならない。パラメータ名
は、問合せの中で明示する必要はない。すなわちそれらのパラメータは Conformance Statementで記述した順序に従って解釈される。
各パラメーターフィールドは、複雑な QIP および QSC タイプを含む場合、任意の単一のデータタイプであることを Conformance Statement で指定されるかもしれない。また、パラメータフィ
ールドはソート制御（SRT）フィールドあるいはセグメントグループ（ID）フィールドを含むかもしれない。
QPD のパラメータフィールドは、Conformance Statement の中で同じ順序で記載される。
Query by example variant のための QPD 使用法の注意
Note:Query By Example: Query by example は、Query By Parameter(QBP)の拡張である。QBP の
検索パラメータはそれらを運ぶセグメントのなかでそれらを送ることにより渡される。したがって Query by example を用いて”find_candidates”問合せを実行したいならば、問合せパラメータでないフィールドは空のままで PID かつ/または PD1 セグメントで検索するための情報を送るだろう。たとえば、もし 宗教 が問合せパラメータの１つでなかったら、PID が問合せで送られる
とき PID-17 は空のままであろう。HL7 メッセージのなかで自然に発生しないパラメータ―検索
アルゴリズム、信頼レベル、など―は QPD セグメントの中で送られ続けるだろう。問合せパラメータとして使用するために利用できるセグメントとフィールドは、問合せのための
Conformance Statement で宣言されるだろう。

Copyright©2002 JAHIS V2.0

139

JHLDEX20.DOC 2002/06/26

QPD-1 にて推奨したメッセージ問合せ名に対応するユーザ定義パラメータを以下に示す。

a) メッセージ問合せ名＝ZOS^Lab Order Specimen Query または ZRS^Lab Result Specimen
Query の場合
QPD Input Parameter Specification
Field Seq
(Query ID =ZOS/ZRS)
1

LEN

TYPE

Opt

250

CE

R

S

32
80

ST
EI

R
O

=

SAC.3

CarrierType
Carrier
Identifier

S

250

CE

O

=

SAC-9

S

80

EI

O

=

SAC.106

Position in
Carrier

S

80

NA

O

=

SAC.11

7

Tray Type

S

250

CE

O

=

SAC.128

Tray
Identifier

S

80

EI

O

=

SAC.139

Position in
Tray

S

80

NA

O

=

SAC.1410

Location

S

250

CE

O

=

SAC.15

11

Requested
Date.LL

S

26

TS

O

>=

OBR.6

12

Requested
Date.UL

S

26

TS

O

<=

OBR.6

2
3

4
5

Name

Message
Query
NameQuery Tag
Container
ID

Key/
Search

Sort

Rep

Match
Op

TBL

Segment
Field
Name

Service
Identifier
CodeElement
Name

SAC-3:
Container
IdentifierSAC-9:
Carrier Type
SAC-10:Carrier
IdentifierSAC-11:
Position in
Carrier
SAC-12:
Tray Type
SAC-13:
Tray
IdentifierSAC-14:
Position in
Tray
SAC-15:
Location
OBR-6:
Requested
Date/Time
OBR-6:
Requested
Date/Timeb)メッセージ問合せ名＝ZRD^Lab Result Requested Date/Time Query の場合
QPD Input Parameter Specification
Field Seq
(Query ID =
ZRD)
1

2
3

4

Name

Message
Query
NameQuery Tag
Requested
Date.LL
Requested
Date.UL

Copyright©2002 JAHIS V2.0

Key/
Search

Sort

LEN

TYPE

Opt

250

CE

R

S

32
26

ST
TS

R
O

>=

OBR.6

S

26

TS

O

<=

OBR.6

140

Rep

Match
Op

TBL

Segment
Field
Name

Service
Identifier
CodeElement
Name

OBR-6:
Requested
Date/Time
OBR-6:
Requested
Date/TimeJHLDEX20.DOC 2002/06/26

7.17 RCP - response control parameter segment
セグメント

応答制御パラメータ

RCP セグメントは、問合せの応答で返されるべきデータ量を制限するのに用いられる。
RCP 属性
SEQ

LEN

DT

OPT

Japan

RP/#

TBL#

ITEM#

ELEMENT NAME

NOTE

1

1

ID

O

O

0091

00027

Query Priority 問合せ優先度

2

10

CQ

O

O

0126

00031

Quantity Limited Request

3

250

CE

O

O

0394

01440

Response Modality 応答モダリティ

4

26

TS

C

C

01441

Execution and Delivery Time

5

1

ID

O

O

0395

01443

Modify Indicator

6

512

SRT

O

O

Y

01624

Sort-by Field

7

256

ID

O

O

Y

01594

Segment group inclusion
含量限定要求
実行伝達時間

修正フラグ

フィールドごとのソート制御
セグメントグループ包RCPフィールド定義
RCP-1

Query priority 問合せ優先度 (ID) 00027
定義： このフィールドは応答が期待される時間枠を含む。有効な値はHL7 ﾃｰﾌﾞﾙ 0091 - Querypriorityを参照のこと。テーブル値と以降のフィールドは、応答の時間枠を指定する。
テーブル 0091 – Query priority
Value

RCP-2

問合せ優先度Description

D

DeferredI

Immediate

Quantity limited request 数量限定要求 (ID) 00031
Conponents:<quantity (NM)> ^ <units (CE)>

定義： このフィールドは要求システムが受諾できる応答の最大長を含んでいる。有効な応答は、
第 2 成分内で指定した単位で与えられた数値(第 1 成分)である。デフォルトは LI である。
第 2 成分の採りうる値については、HL7 ﾃｰﾌﾞﾙ 0126 - Quantity limited requestを参照のこと。セグメントのパターン応答において、Line は単一セグメントとして定義される。
テーブル 0126−Quantity limited request 数量限定要求
Value

Description

Message Usage

Comment

CH

Characters

RSP/RTB/RDY

Used where size of
input buffer has
limitations

LI

Lines

RTB/RDY

PG

Pages

RDY

RD

Records

RSP/RTB/RDY

ZO

Locally defined

Copyright©2002 JAHIS V2.0

141

In RSP record = hit

JHLDEX20.DOC 2002/06/26

RCP-3

Response modality 応答モダリティ (CE) 01440
定義： このフィールドは応答メッセージのタイミングとグルーピングを指定する。採りうる値
はHL7 ﾃｰﾌﾞﾙ 0394 – Response modality参照のこと。
テーブル 0394 – Response modality 応答モダリティ

RCP-4

Value

Description

R

Real Time

T

Bolus (a series of responses sent at thesame time without use of batch formatting)

B

Batch

Execution and delivery time 実行伝達時間 (TS) 01441
応答が返されるべき時間を指定する。このフィールドは、RCP-1-Query priority が D (Deferred)である場合のみ使用される。

RCP-5

Modify indicator

修正識別 (ID) 01443

定義： このフィールドは、subscription が新規か修正されるかどうかを指定する。HL7 ﾃｰﾌﾞﾙ
0395 - Modify indicatorを参照のこと。
テーブル 0395−Modity indicator 修正識別
Value

RCP-6

DescriptionN

New Subscription

M

Modified Subscription

Sort-by field フィールドごとのソート制御 (SRT) 01624
Components: <sort-by field/parameter (varies)> ^ <sequencing (ID)>

定義： 表形式の応答(tabular response)を求める問合せに対し、このフィールドは、応答はどのフィールドによってソートされるべきか、あるいは、どの順序でオーダが実行されるべきかを指定する。QSC データタイプが使用されないとき、このフィールドの最初のコンポーネントに設定される値は、(Coformance Statement の)Output Specification and Commentary の ColName フィールドの順序に従う。QSC が使用されるとき、値は(Coformance Statement の)Input/Output
Specification and Commentary の ColName フィールドに従う。このフィールドの反復は、単一のソードフィールドを指定する。そして、このフィールドの最初の反復は、第１ソートフィール
ド要素を指定し、2 番目の反復は第２ソードフィールド要素を指定する。
RCP-7

Segment group inclusion セグメントグループ包含 (ID) 01594
定義： 応答に含まれるべきオプショナルのセグメントグループを指定する。セグメントを指定するための値はHL7 ﾃｰﾌﾞﾙ 0391—Segment groupを参照のこと。これは複数のセグメントグルー
プを含めて提供するために、反復可能フィールドである。このフィールドのデフォルト（つまりこのフィールドが存在しない場合）は、すべての関係グループが含まれることを意味する。
備考： セグメントグループのためのコードは HL7 ﾃｰﾌﾞﾙ 0391 から取得されるが、セグメント
グループ（例えば PIDG）の正確なセグメントレベル定義は Conformance Statement にてのみ与えられる。このセグメントレベルの定義は、Conformance Statement によって変化しても良い。

Copyright©2002 JAHIS V2.0

142

JHLDEX20.DOC 2002/06/26

例：
テーブル0391−Segment group セグメントグループ
Value

Description

PIDG

PID group

OBRG

OBR group

ORCG

ORC group

RXAG

RXA group

RXDG

RXD group

RXEG

RXE group

RXOG

RXO group

Etc

注意：HL7 ﾃｰﾌﾞﾙ 0391 – Segment group は現在 HL7 によって定義された値ではないものを含む。
その値が HL7 Technical Committee によって投票された Conformance Statement の中で賛同されるのであれば、その値はこの表の中に含まれるであろう。

Copyright©2002 JAHIS V2.0

143

JHLDEX20.DOC 2002/06/26