5. 関連情報詳細
5.1 HL7メッセージについてメッセージ(例えば検査依頼)は具体的な事象トリガーイベント(例えばオーダー)により発生し、メッセージヘッダーセグメント(MSH)で始まり、データ構成要素フィールド(例えば患者名)からなるデータをもったセグメント(例えば患者属性)の集合として構成される。 これらはコード化規則による区切文字
で区切られた可読的な可変長メッセージであり、下記のように構成される。

メッセージ：

MSH セグメント <CR>
xxx セグメント <CR>
yyy セグメント <CR>
zzz セグメント <CR>

セグメント： セグメントID ￨ フィールド1 ￨ フィールド2 ￨ フィールド3 ￨ … <CR>
フィールド：

エレメント1 ^ エレメント2 ^ エレメント3 ^ …

5.2 フィールドについてフィールドは文字列である。
システムが実際にアプリケーション内でどのようにデータを保管するかについて、HL7は関与しない。
特に注記しないかぎり、HL7データ・フィールドはnull値を採ることがある。 null値を送ること、つまり2個の二重引用符（）として送ることと、オプションのデータ・フィールドを省略することとは異なる。メッセージ内容が新規レコードを作成するためでなくデータベース内のレコードを更新するために使われるとき、その相違は出てくる。 値を送信しない（すなわち省略する）場合、古い値はそのままである。 null値を送る場合は、古い値はnull値に変更されるべきである。
本規格のさまざまな章にセグメント属性テーブルが含まれている。 これらのテーブルは、そのセグメ
ント内のデータ・フィールドとその使用上の特徴を一覧・記述している。 セグメントを定義する際、以下の情報が各フィールドについて述べられている。：

5.2.1(セグメント内の)位置

セグメント内のデータ・フィールドの順序位置。 セグメント属性テーブルでは、この情報はSEQというコラムにある。
この番号は、セグメント定義テーブルに続くテキストコメントで示されるデータフィールドの説明を参照するために使われる。

5.2.2 最大長１つのデータ・フィールドの１反復が占めることができる文字の最大数。 セグメント属性テーブルでは、この情報はLENというコラムにある。
フィールドの長さは標準であるが、施設独自の根拠で変更することができる。後に定義する成分セパ
レーターと副成分セパレーターは文字数として計算される。最大長は1つの発生の長さなので、反復セ
パレーターは、最大長を計算するときに含めない（章5.2.5 反復 を参照）。 複合データタイプは最も大きな成分データタイプの最大長より短い最大長を持ってはならない。
最大長が非常に大きな数の意向を伝える必要があるときは、ユーザに警告すべく値65536で表す。 この規定は64Kと略記したHL7 ﾊﾞｰｼﾞｮﾝ 2.4 以前の慣例に代わる。

Copyright©2002 JAHIS V2.0

10

JHLDEX20.DOC 2002/06/26

以下の最大フィールド長が指定されている。
Maximum Field Lengths
Field Type

Data Type

LengthCoded fields:

CE

250

CX

250

CNE

250

CWE

250

CK

250

CN

250

Phone number
field:

XTN

250

Name fields

XCN

250

XPN

250

Address fields:

XON

250

PPN

250

XAD

250

5.2.3 データタイプ（データ型）
データ・フィールドの内容に対する制限。 セグメント属性テーブルでは、この情報はDTというコラムにある。 もしフィールドのデータタイプが不定なときは、”varies”が注記される。
HL7によって定義された多くのデータタイプがある。 これらについては｢5.4 Data types データ型｣で説明する。
JAHIS仕様の本規約書では「データ型」とも呼んでいる。

5.2.4 オプション指定
セグメント内のデータフィールドが、必須なのか、オプションなのかまたは条件付きなのかを示す。 セ
グメント属性テーブルでは、この情報はOPTというコラムにある。
HL7での指定は以下のとおりである。
R −
O −
C −

X −
B −

必須。
オプション。
トリガーイベントおよびその他のフィールド条件による。
セグメント属性表に続くフィールド定義(説明)では、このフィールドの条件を定義
するアルゴリズムを指定すべきである。
対象のトリガーイベントでは使用されない。
HL7の前のバージョンへの後方互換性のために残した。 セグメント属性テーブルに続くフィールド定義(説明)では、先のバージョンのため選択フィールドであると表示すべきである。

注：バージョン2.3以上のために：各セグメント定義テーブルに続くセグメント・フィールド定義中でフィールドの選択性を明示的に文書化するのがよい；セグメント内のフィールドの選択性がトリガーイベ
ントに依存して変わる場合、その選択性も明示的に文書化するのがよい。
注：多数の成分あるいは副成分を含んでいる、HL7データタイプによって定義されたフィールドについては、正式のセグメント属性テーブルに続く詳細なフィールド定義(説明)中で与えられた成分あるいは副成分の選択性を指定しなければならない（さらに「5.3 Message Delimitersメッセージ区切り文字」、「5.4
Data types データ型」を参照すること）。

Copyright©2002 JAHIS V2.0

11

JHLDEX20.DOC 2002/06/26

JAHIS仕様(本規約書)での取り扱いは以下のとおりである。（R〜BはHL7に同じ。）
セグメント属性テーブルでは、この情報はJapanというコラムにある。
R −
O −
C −

X −
B −

Ｎ

−

必須。
オプション。
トリガーイベントおよびその他のフィールド条件による。
セグメント属性表に続くフィールド定義(説明)では、このフィールドの条件を定義
するアルゴリズムを指定すべきである。
対象のトリガーイベントでは使用されない。
HL7の前のバージョンへの後方互換性のために残した。 セグメント属性テーブルに続くフィールド定義(説明)では、先のバージョンのため選択フィールドであると表示すべきである。
通常、使用しない。 施設内でのみ使用する。

5.2.5 反復
そのフィールドが反復されるかどうかを示す。 セグメント属性テーブルでは、この情報はRP／#というコラムにある。
指定は以下のとおりである。
Nまたは空白 − 反復なし。
Y− 無限回または現場で決定した回数だけフィールドが繰り返される。
（整数）− フィールドは、整数で指定された最大回数まで繰り返す。
繰り返しのそれぞれが、そのフィールドの最大長で指定した文字数を含めることができる（｢5.2.2
大長｣を参照）。
使用上の注意：空白をそのフィールドが任意に反復してよいと解釈してはならない。

最5.2.6 テーブル
データフィールド定義で説明されているテーブルの表題中の番号(４桁)は、そのコード化値セットのHL7識別子を意味する。
HL7はテーブルを3つの方法、つまり、使用者、HL7、外部により定義している。
使用者定義テーブル(User-defined Tables)： ユーザまたは施設で定義された値を持つテーブルである。
これは PV1-3-Assigned patient location のように確実なフィールドを与え、施設ごとに異なる値を持つ。
このようなテーブルは規格では定義してないが、実現を容易にするために使用者定義テーブル番号が割り当てられる。 HL7はしばしば施設が皮切りとして使えそうな推奨値を発行している（例えばテーブ
ル0001 性別）。 ISデータタイプは、このようなテーブルで使う値をコード化するのによく使われる。
このようなテーブルのなかには、共通のマスターファイルを参照するテーブルもあるということに注意されたい（例えばテーブル0302 Point of cure）。
JAHIS仕様の本規約書では「使用者定義テーブルnnnn」と表現している。
HL7テーブル(HL7 Tables)： HL7テーブルはHL7によって定義/発行された値の集合である。 これらはそのテーブルを含むメッセージの解釈に影響を及ぼすのでHL7規格に含まれる。 これらの値は現場で再定義してはならないが、現場で定義した値を含めるためにテーブル自身を拡張することができる。 特にこのことは、HL7テーブル0003 – イベント型 のケースに適用されている。 IDデータタイプは、HL7テーブルで使う値をコード化するのに最もよく使われる。
JAHIS仕様の本規約書では「HL7テーブルnnnn」または「テーブルnnnn」と表現している。
外部テーブル(External Tables)：外部テーブルは他の標準または組織によって定義/発行されたものである。例えばLOINCコードを使って検査結果を符号化する。 CEデータタイプはこれらのフィールドの値を表すために使用される。
9000とそれ以上のテーブル番号はHL7が発行する外部定義テーブルのために予約している。 そのようなテーブルは、外部の機関が制定する概念やコードを、HL7と他の標準化機関との間で規格化要求し合Copyright©2002 JAHIS V2.0

12

JHLDEX20.DOC 2002/06/26

意を得た場合に発生する。 これらはHL7が他の機関に代わってHL7規約と共に発行される。 しかし、これらはHL7規約より頻繁に改訂されるかもしれない。
はい／いいえ標識テーブル（Yes/no indicator table）
はい／いいえ（Yes/No）の実際の使用は、説明内容に敏感である。 各々の章ではそれぞれの文脈での意味で詳述される。
テーブル 0136 – Yes/no indicator はい／いいえ標識
Value
Y

Yes

Description
はい

N

No

いいえ

5.2.7 ID番号
規格の全体にわたるデータ・フィールドを一意的に識別する小さな整数。 セグメント定義では、この情報はITEM#というコラムにある。

5.2.8 名称
フィールドの記述的な名前。 セグメント属性テーブルでは、この情報は ELEMENT NAME というコラムにある。
同じ名前が複数のセグメント中で使用される場合、それは同じデータタイプおよび意味を同じID番号と同様に各セグメントが持っていなければならない。 この慣行から発生する曖昧さを扱うため、フィールドがここで引用される場合は、セグメント名および位置が常に含まれなければならない。

Copyright©2002 JAHIS V2.0

13

JHLDEX20.DOC 2002/06/26

5.3 Message Delimitersメッセージ区切り文字
メッセージを構成するときに、セグメント・ターミネータ、フィールド・セパレーター、成分セパレーター、副成分セパレーター、反復セパレーター、エスケープ文字の特殊文字が使われる。 セグメン
ト・ターミネータは必ずキャリッジ・リターン(16進0D)である。その他の区切り文字はMSHセグメントで定義される。つまり、フィールド区切り文字は4番目の文字位置で定義され、それ以外の区切り文字
は、フィールド区切り文字に続くフィールドであるコード化文字フィールドで定義される。 MSHセグ
メントで定義される区切り文字は、メッセージ全体に適用される。 特に理由がなければ、図2-1の区切り文字を推奨する。
図 2-1. Delimiter values 区切り文字の値
文字位置

区切り文字

-

Segment Terminator
セグメントターミネータ-

Field Separator
フィールドセパレータ
またはフィールド区切り文字
Component Separator
成分セパレータ
Repetition Separator
反復セパレータ
Escape Character
エスケープ文字

1
2
3

4

Subcomponent Separator
副成分セパレータ

推奨
値
<cr>
hex
0D
|

^
~
\ (￥)

&

用法
セグメントレコードを終了する。
この値は、導入者によって変えることができない。
セグメント内で2個の隣接データフィールを分離する。
それはまたセグメント内の冒頭のデータフィールドとセグメントIDを分離する。

データフィールド内の隣接成分を分離する。
成分の使用法は、関連するデータフィールドの記述に述べられている。
反復の認められたデータフィールドにおいて、複数のデータを分離する。
テキストフィールド(ST,TX,FTタイプまたはEDタイプの第４成分)では、エスケープ
文字が使用できる。 これを表す単一の文字は、MSHセグメントのコード化文字フィールドで指定する。 このフィールドはオプションであり、エスケープ文字を使わないメッセージではこの文字は省略できる。 しかし、副成分セパレータがメッセー
ジの中で使われるならば、この指定は存在せねばならない。
データフィールド内の使用が認められた隣接副成分を分離する。
副成分が無いときは、省略できる。

文字位置１〜４は、各セパレータを表現するキャラクタを定義する(MSHセグメントの)コード化文字フィールド
内の指定位置である。

注：区切り文字で囲まれる文字列中でASCII以外の文字セットを使用した場合(escape,invoke)、区切り文
字に先立ちASCII文字セットにもどすこと。もし区切り文字が検出された場合は文字セットはASCIIへ
リセットしたものとみなす。

テキストフィールドでのエスケープシーケンスの使用
TX, FT, ST または CF 型等のフィールドを符号化する場合、エスケープ文字を使用してテキストフィ
ールドの特殊処理部を伝えることができる。エスケープ文字は、表示可能な任意の ASCII 文字で、MSH-2 符号化文字のエスケープ文字要素に指定する。本節の説明のためには、文字\を使用して、メッセージに指定するエスケープ文字とする。エスケープシーケンスは、エスケープ文字とそれに続く
1 文字のエスケープ・コード ID、0 個以上のデータ文字、それにもう 1 つのエスケープ文字から構成される。 エスケープシーケンスの中の入れ子エスケープシーケンスは禁止する。
詳細は、HL7 節 2.10、｢テキストフィールドでのエスケープシーケンスの使用｣を参照。
特殊文字： フィールド区切り、成分区切り、副成分区切り、反復区切り、およびエスケープ文字をテ
キストフィールド内に表現するために、以下のエスケープシーケンスが定義されている：\F\
フィールド区切り（フィールドセパレータ）
\S\
成分区切り
（成分セパレータ）\T\
副成分区切り（副成分セパレータ）
\R\
反復区切り
（反復セパレータ）\E\
エスケープ文字例：

ＭＳＨ−２で｜＾ ¥&｜の時、￥９，８００￥Ｅ￥９，８００

Copyright©2002 JAHIS V2.014は次の様に記述する。

JHLDEX20.DOC 2002/06/26

推奨しない/規格外のエスケープシーケンス： HL7では下記のエスケープシーケンスが定義されているが、本規約ではその使用を推奨しない。 利用する場合は、適用施設/アプリケーション間の取り決めが必要である。 尚、これらのエスケープシーケンスを受信したことで本来実行すべき処理を中断することがないように配慮すべきである。
FT、STおよびXTデータ型のためのマルチ文字セットをサポートするエスケープシーケンス\Cxxyy\\Mxxyyzz\
本規約では MSH-18で ˜ISO IR87 を指定するので、文字セットのエスケープシーケンスを必要と
しない。
強調表示
\H\
\N\
表示等の表現は受信側アプリケーションで扱うこととする。
16進法\Xdd...dd\
このデータの扱い/解釈はHL7規格の範囲外であり、本規約でも規定できない。
フォーマット化テキスト\.sp<数>\
\.br\
\.fi\
\.nf\
\.ti<数>\\.sk<数>\\.ce\\.in<数>\（報告書等の）書式制御は受信側アプリケーションで扱うこととする。
ローカル\Zdd...dd\
このデータの扱い/解釈はHL7規格の範囲外であり、本規約でも規定できない。

エスケープ文字の例外的解釈
エスケープ文字は他の表示可能な文字、区切り文字と違って、その一文字だけでは意味を成さない。
エスケープシーケンスは一対のエスケープ文字を使い、前項に示す記述以外の使い方をしない。
しかし、下記に示すケースが想定され、本節ではその場合の解釈を示す。 説明では、文字 \ を使用
して、メッセージに指定するエスケープ文字とする。
一対のエスケープ文字の間にエスケープ・コード ID、データ文字がない場合：
表示可能な文字 \ と見なす。 つまり、\E\ を記述したのと同じとする。
記述例\\\E\\\\\

解釈\ （エスケープ文字）\\\（エスケープ文字が３個）

エスケープ文字の後のエスケープ・コード ID が前項以外である場合：
一対のエスケープ文字の間を無視する。 つまり、そのエスケープシーケンスを無視する。
受信アプリケーションは警告を発するべきである。
記述例
\ABC\

解釈
省略またはnull（受信アプリケーションに害のない処理）

エスケープ文字が対を成さない場合：
フィールドの終わりでそのエスケープシーケンスが完結したと見なす。
但し、受信アプリケーションは警告を発するべきである。
記述例|…\X0506XY|

解釈…16進数の05,06 （最後のXYは16進数のデータの筈だが誤り

|…\S|
|…\|

…^ （\S\ と見なされる。）… （最後の \ のみは無視する。）

である。その処置は本規約では規定外。）

Copyright©2002 JAHIS V2.0

15

JHLDEX20.DOC 2002/06/26

5.4 Data types データ型
図 2-2. HL7 data types (HL7テーブル0440)
Data Type
Category / Data
type
Alphanumeric
ST
TX
FT
SRT
Numerical
CQ
MO
NM
SI
SN
Identifier
ID
IS

Data Type Name
データ型名
StringText data
Formatted text
Sort order

Notes/Format
注意・フォーマット

199
65536
65536
<sort-by field/parameter (varies)> ^ <sequencing (ID)>Composite quantity with units
Money
Numeric
Sequence ID
Structured numeric<quantity (NM)> ^ <units (CE)><quantity (NM)> ^ <denomination (ID)><comparator (ST)> ^ <num1 (NM)> ^ <separator/suffix (ST)> ^ <num2(NM)>

Coded values for HL7 tables
Coded value for user-definedtables

VID

Version indentifierHD

Hierarchic designator

EI

Entity identifier

RP

Reference pointerPL

Person locationPT
Date/Time
DT
TM
TS
Code Values
CE

LEN
長さ

Processing type<version ID (ID)> ^ <internationalization code (CE)> ^ <international version
ID(CE)><namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>Note: Used only as part of EI and other data types.
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^<universal ID type (ID)><pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype(ID)><point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^<floor (IS )> ^ <location description (ST)><processing ID (ID)> ^ <processing mode (ID)>

Date
Time
Time stamp

YYYY[MM[DD]]
HH[MM[SS[.S[S[S[S]]]]]][+/-ZZZZ]YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ] ^ <degree of precision>

Coded element

250

CNE

Coded with no exceptions

250

CWE

Coded with exceptions

250

CF

Coded element with formatted
valuesCK

Composite ID with check digit

250

CN

Composite ID number and
name

250

CX

Extended composite ID withcheck digit

250

Copyright©2002 JAHIS V2.0

<identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system(IS)><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 system version
ID (ST)> ^ <original text (ST)><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 system version
ID (ST)> ^ <original text (ST)><identifier (ID)> ^ <formatted text (FT)> ^ <name of coding system (IS)> ^<alternate identifier (ID)> ^ <alternate formatted text (FT)> ^ <name ofalternate coding system (IS)><ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit
scheme employed (ID)> ^ < assigning authority (HD)><ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <secondand further given names or initials thereof (ST)> ^ <suffix (e.g.,JR or III)(ST)> ^ <prefix (e.g.,DR) (ST)> ^ <degree (e.g.,MD) (IS)> ^ <source table(IS)> ^ <assigning authority (HD)><ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme
employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (ID)> ^<assigning facility (HD)> ^ <effective date (DT)> ^ <expiration date (DT)>16

JHLDEX20.DOC 2002/06/26

Data Type
Category / Data
type
XCN

Data Type Name
データ型名

LEN
長さ

Notes/Format
注意・フォーマット

Extended composite ID
number and name

250

In Version 2.3 and later, use instead of the CN data type. <ID number (ST)>^ <family name (FN)> ^ <given name (ST)> ^ < second and further given
names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g.,DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table (IS)> ^ <assigningauthority (HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^<code identifying the check digit scheme employed (ID)> ^ <identifier typecode (IS)> ^ <assigning facility (HD)> ^ <name representation code (ID)> ^<name context (CE)> ^ <name validity range (DR)> ^ <name assembly order(ID)>

Generic
CM

Composite

No new CM’s are allowed after HL7 Version 2.2. The CM data type ismaintained strictly for backward compatibility and may not be used for thedefinition of new fields.

Demographics
AD

Address<street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state orprovince (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ <address type(ID)> ^ <other geographic designation (ST)><surname (ST)> ^ <own surname prefix (ST)> ^ <own surname (ST)> ^<surname prefix from partner/spouse (ST)> ^ <surname from patner/spouse(ST)>
Note: Appears ONLY in the PN and other PN-containing data types(PPN,XCN,XPN).
<family name (FN)> ^ <given name (ST)> ^ <second and further given
names or initials thereof (ST)> ^ <suffix (e.g.,JR or III) (ST)> ^ <prefix(e.g.,DR) (ST)> ^ <degree (e.g.,MD) (IS)><street or mailing address (ST)> ^ <street name (ST)> ^ <dwelling number(ST)>
Note: Appears ONLY in the XAD data type.
[NN][(999)]999-9999[X99999][B99999][C any text]
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)>In Version 2.3, replaces the PN data type. <family name (FN)> ^ <given
name (ST)> ^ <second and further given names or initials thereof (ST)> ^<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD)(IS)> ^ <name type code (ID) > ^ <name representation code (ID)> ^ <namecontext (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)><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)>In Version 2.3 and later, replaces the TN data type. [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)>FN

Family name

PN

Person name

SAD

Street Address

TN
XAD

Telephone number
Extended address

250

XPN

Extended person name

250

XON

Extended composite nameand ID number fororganizations

250

XTN

Extended telecommunications
number250

Specialty/Chapter
Specific
Waveform
CD

Channel definition

MA

Multiplexed array

NA

Numeric array

ED

Encapsulated data

Price Data
CP

Composite price

Copyright©2002 JAHIS V2.0

For waveform data only, see HL7- Chapter 7, Section 7.16.2. <channel
identifier (*CM)> ^ <waveform source (CM)> ^ <channel sensitivity/units(*CM) > ^ <calibration parameters (*CM)> ^ <sampling frequency (NM)> ^<minimum/maximum data values (*CM)>For waveform data only, see HL7- Chapter 7, Section 7.15.2. <sample 1
from channel 1 (NM)> ^ <sample 1 from channel 2 (NM)> ^ <sample 1 fromchannel 3 (NM)> ... ~ <sample 2 from channel 1 (NM)> ^ <sample 2 fromchannel 2 (NM)> ^ <sample 2 from channel 3 (NM)> ... ~For waveform data only, see HL7- Chapter 7, Section 7.15.1. <value1(NM)> ^ <value2 (NM)> ^ <value3 (NM)> ^ <value4 (NM)> ^ ...
Supports ASCII MIME-encoding of binary data. <source application (HD) >^ <type of data (ID)> ^ <data subtype (ID)> ^ <encoding (ID)> ^ <data (ST)>In Version 2.3,replaces the MO data type. <price (MO)> ^ <price type (ID)> ^<from value (NM)> ^ <to value (NM)> ^ <range units (CE)> ^ <range type
(ID)>

17

JHLDEX20.DOC 2002/06/26

Data Type
Category / Data
type
Patient
Administration/Fin
ancial Information
FC
Extended Queries
QSC
QIP
RCD
Master Files
DLN

Data Type Name
データ型名

LEN
長さ

Notes/Format
注意・フォーマット

Financial class<financial class (IS)> ^ <effective date (TS)>Query selection criteria<segment field name (ST)> ^ <relational operator (ID)> ^ <value (ST)> ^<relational conjunction (ID)><segment field name (ST)> ^ <value1 (ST) & value2 (ST) & value3 (ST) …><segment field name (ST)> ^ <HL7 data type (ID)> ^ <maximum column
width (NM)>Query input parameter list
Row column definition

Driver’s license number

JCC

Job code/class

VH

Visiting hours

Medical Records /Information
Management
PPN

Performing person time stamp

Time Series:
DR
RI

Date/time range
Repeat interval

SCV

Scheduling class value pair

TQ

Timing/quantity<license number (ST)> ^ <issuing state, province, country (IS)> ^ <expiration
date (DT)><job code (IS)> ^ <job class (IS)><start day range (ID)> ^ <end day range (ID)> ^ <start hour range (TM)> ^<end hour range (TM)>250<ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ < secondand further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III)(ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <source table(IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifiercheck digit (ST)> ^ <code identifying the check digit scheme employed (ID )>^ <identifier type code (IS)> ^ <assigning facility (HD)> ^ < date/time action
performed (TS)> ^ <name representation code (ID)> ^ <name context (CE)>^ <name validity range (DR)> ^ <name assembly order (ID)><range start date/time (TS)> ^ <range end date/time (TS)>Scheduling Chapter Only: <repeat pattern (IS)> ^ <explicit time interval(ST)>
Scheduling Chapter Only: <parameter class (IS)> ^ <parameter value(ST)>
For timing/quantity specifications for orders, see HL7- Chapter 4, Section
4.3. <quantity (CQ)> ^ <interval (*)> ^ <duration (*)> ^ <start date/time (TS)>^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^<conjunction (ID)> ^ <order sequencing (*)> ^ <occurrence duration (CE)> ^<total occurrences (NM)>* for subcomponents of these elements please refer to the definition in the text.

Data types データ型解説
ST 文字列データ
文字列データは、左詰めにされこれに空白がうしろに続いてもよい。任意の表示可能な(印刷可能な)ASCII文字(20から7Eまでの16進値)である。例：|almost any data at all|TX テキスト・データ
文字列データは、使用者に対しターミナルまたはプリンターによって表示するためにある。
文字列に先行空白を挿入した方が使用者が見やすいということもあるので、文字列は必ずしも左詰めにするわけではない。この種のデータは表示することが目的なので、表示装置を制御するためのエスケープ文字シーケンスを含むことがある。先行空白文字を挿入し、後書き空白を取り除くとよい。 例：| leading spaces are allowed.|
TXデータは表示するためにあるので、反復区切文字をTXデータ・フィールドで使うと、それは一連の反復行がプリンターまたはターミナル上に表示されることを意味する。したがって反復区切文字は、パラグラフ・ターミネータまたはハード・キャリッジ・リターンとみなされる。(そのテキスト内にCR/LFが挿入されたように表示される)。
受信システムでは、任意の大きさの表示ウィンドウに合わせるためテキストを繰り返し区
切り文字間でワードラップするが、反復区切文字で始まる行はすべて新たな行になる。

Copyright©2002 JAHIS V2.0

18

JHLDEX20.DOC 2002/06/26

FT 書式付テキスト・データ
このデータ型は、書式を埋め込み追加することで文字列データ型を拡張したものである。
これらの書式は固有であり、フィールドの使用環境から独立している。 文字列データ(ST)フィールドとFTフィールドとの違いは、長さが任意(64kまで)であることと、エスケープ文
字で囲まれた書式を含むことである。 例：|\.sp\(skip one vertical line)|
SRT ソート依頼
Components:<sort-by field ソートフィールド(ST)> ^ <sequencing 配列(ID)>

ソートされるレスポンスとソート方法をこのパラメータで指定する。
第１成分はソートされるレスポンスのフィールドを識別する。 よいレスポンスでは、これはソートされるべきカラム名になる。 セグメント・パターンや表示応答ではソートされるべきセグメント・フィールド名になる。 (セグメント・フィールド名定義についてはQIPデータタイプの「セグメント・フィールド名(ST)」を参照。)。
第２成分はフィールドかパラメーターにより識別しソートする。 HL7テーブル0397を参照
する。
テーブル0397−汎用IDタイプ
Value
A
AN
D
DN
N

Description
Asending
Asending,case Insensitive
DesendingDesending, case Insensitive
None

昇順
大小文字区別無し昇順
降順
大小文字区別無し降順

CQ 単位付き合成量
Components: <数量(NM)>^<単位(CE)>
第1成分は数量である。第2成分はその数量の単位である。デフォルトの単位で検査を測定した場合、その単位は送信する必要ない。その単位がISO+単位であるなら小文字の省略形を使用するとよい 。その単位がANSIまたはローカル定義のものならその単位と出典を記録しなければならない。
例：|123.7^kg| kilograms is an ISO unit
|150^lb&&ANSI+| weight in pounds is a customary US unit defined within ANSI+.
MO

金額
Components:<quantity (NM)> ^ <denomination (ID)>

第1成分は数量で金額を表わし、第2成分はその数量を表す際の貨幣単位である。貨幣単位
成分の値はISO-4217に指定されている。貨幣単位を指定しない場合、MSH-17国コードを使用しデフォルトを決定する。例：|99.50^USD|ここでUSDは、米国ドルを表すISO 4217コー
ドである。
NM 数字
ASCII数字列として表記される数字は、オプションの先行符号(＋または−)、数字、そしてオプションの小数点から構成される。符号がない場合、その数値は正数であると仮定され|-123.792|
る。小数点がない場合、その数値は整数であると仮定される。 例：|999|
先行ゼロまたは小数点の後の後書きゼロは無意味である。01.20と1.2という2つの数値は同一である。オプションの先行符号(＋または−)およびオプションの小数点(．)を除いては、数字以外のASCII文字は許されない。したがって、値 <12 は、文字列データ型としてコード化しなければならない。
SI シーケンスID
NMフィールド形式の正整数。このフィールドの使用方法は、それが現れるセグメントとメッセージを定義している章で定義する。

Copyright©2002 JAHIS V2.0

19

JHLDEX20.DOC 2002/06/26

構造化数値SN

Components: <comparator比較演算子 (ST)> ^ <num1 (NM)> ^ <separator/suffixセパレータ/サフィック
ス (ST)> ^ <num2 (NM)>構造化した数値データ・タイプは、条件を伴った数値の臨床検査結果を表現するため使用される。これによって受信システムは成分を別々に格納することができ、数値のデータベース照会の使用が容易になる。
比較演算子は、超｢ > ｣、未満｢ < ｣、以上｢ >= ｣、以下｢ <= ｣、等しい｢ = ｣、等しくない｢ <> ｣、
デフォルトは等しい｢ = ｣である。
<num1>および<num2>が値を持つ場合、セパレータ/サフィックスは必須である。セパレータが｢ - ｣である場合、その範囲は両端を含む。例えば、<num1> - <num2>は、<num1> <= x <= <num2>であるような一連の数値Xを示す。
num1は数値。num2は数値またはヌルであり測定によって異なる。
セパレータ/サフィックスは、｢ - ｣、｢ + ｣、｢ / ｣、｢ . ｣、｢ : ｣。
例： |>^100| (greater than 100)、 |^100^-^200| (equal to range of 100 through 200)|^1^:^228| (ratio of 1 to 128, e.g., the results of a serological test)|^2^+|(categorical response, e.g., occult blood positivity)
ID

HL7定義コード化値
この種のフィールドで使う値は、正当な表の値から引用される以外はSTフィールドで使う書式規則に従う。IDフィールドの例として性別などがある。

IS 使用者定義コード化値
このフィールドの値は、使用者定義テーブルから引用され、STフィールドの書式規則に従う。ISデータ型に関連したHL7テーブル番号があるものとする。例えば事象理由コードである。
VID

バージョン識別子
Components:<version ID (ID)> ^ <internationalization code(CE)> ^ <international version ID (CE)>第1要素はHL7バージョンを表記するために使用。 取りうる値はHL7テーブル0104を参照。
第2要素はISO3166国コードで国際支部の国を表記する。 ISO3166テーブルに従い、3文字のコードを国コードと扱う。
第3要素に各国支部がUSのバージョンに対し支部バージョンを持つ場合そのバージョン番
号を表記する。
HD 階層的デジグネータ
Components:<namespace ID (IS)> ^ <universal ID(ST)> ^ <universal ID type (ID)>

HDデータタイプは他のデータタイプ構成要素の一部として用いられる。それは、ローカルで定義されたアプリケーション識別子や公に割当てられたUIDのいずれかとして使用される。
HDは、HL7の初期の版でISデータ型を使用したフィールドの中で使用される。その場合、第一成分のみである。HDデータ型の第1の成分が存在する場合、第2と第3の成分はオプションである。第3成分が存在する場合、第2成分も存在せねばならない。
HDの第2の成分、汎用ID(UID)は、第3の成分、汎用IDタイプ(UIDタイプ)によって定義される書式の文字列である。UIDはUIDタイプ内で時間が経過しても一意的になるよう定義されている。UIDタイプによって定義された各UIDは、UIDを構築する特に列挙された計画のうちの1つに属さなければならない。UID(第2の成分)は、第3の成分によって定義された汎用
ID構文規則に従わなければならない。
テーブル0301−汎用IDタイプ
Value
DNS
GUID
HCD

Description
インターネットで指定された名前。ASCII文字あるいは整数値のいずれか。
UUIDと同じ。
CENヘルスケアコード体系デジグネータ(DICOMで使用される識別子はこの割当計画に従う)。

Copyright©2002 JAHIS V2.0

20

JHLDEX20.DOC 2002/06/26

Value
HL7
ISO
L、M、N
ランダム

UUID
x400
x500

Description
将来のHL7登録計画のためにリザーブ。
国際標準化機構オブジェクト識別子
ローカルで定義されたコード体系のためにリザーブ。
一般的にランダムビットのbase64コード化文字列。一意性は、ビットの長さに依存する。メール・システ
ムは、ランダムビットおよびシステム名の組合せから、ASCII文字列の｢一意的な名｣を生成することが多い。明らかに、そのような識別子はbase64文字集合によって束縛されない。
DCE 汎用一意性ID
X400 MHS書式ID
X500 ディレクトリ名

例：
1.2.34.4.1.5.1.5.1,1.13143143.131.3131.1^ISO
14344.14144321.4122344.14434.654^GUID
falcon.iupui.edu^DNS
40C983F09183B0295822009258A3290582^RANDOM
LAB1

Local use only: an HD that looks like an IS data type.

PathLab^UCF.UC^L

A locally defined HD in which the middle component isitself structured. This can be considered the
combination of 'PathLab' with the locally defined
UID system "L".

LAB1^1.2.3.3.4.6.7^ISO

An HD with an ISO "Object Identifier" as a suffix,
and a locally defined system name.

^1.2.344.24.1.1.3^ISO

An HD consisting only of an ISO UID.

EI エンティティ識別名
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ < universal ID type(ID)>

エンティティ識別名は、識別子の指定されたシリーズ内の与えられたエンティティを定義する。
指定されたシリーズ、すなわち割り当て権限は、成分2〜4によって定義される。割り当て
権限は階層的指名者データ型(HD)である。 しかし、それは3つの個別の成分としてEIデータ
型の中で定義され、これは通常単一の成分として定義されるのと異なる。 これはいくつかの既存のデータ分野の成分としてのEIの使用と下位互換性を維持するためである。そうでなければ、成分2〜4は｢HD 階層的デジグネータ｣の中で定義される。 階層的指名者は、与えられたHL7導入を通じて一意的である。
第1成分、エンティティ識別名は、識別子のシリーズ内で一意的であるよう定義され、割当て権限によって作成され、これは階層的指名者によって定義され成分2〜4で表わされる。
RP 参照ポインタ
Components: <pointerポインタ (ST) > ^ < application IDアプリケーションID (HD)> ^ <type of dataデー
タの型 (ID)> ^ <subtypeサブタイプ (ID)>

このデータ型は、別のシステムに保存されているデータの情報を伝送する。このデータ型には、そのシステムに保存されているデータを一意に識別する参照ポインタ、そのシステ
ムの識別、およびデータの型が含まれる。
ポインタ： データを保存するシステムが割り当てる一意なキー。そのキーはSTデータ型であり、データを識別しそのデータにアクセスするのに使う。
アプリケーションID： HDデータ型でありデータを保存するシステムの一意な名前。依頼者(または実施者)アプリケーションIDに同じ。 アプリケーションIDは扱うHL7メッセー
ジシステムを通じて一意でなければならない。
参照されるデータのタイプはHL7テーブル0191に示される。

Copyright©2002 JAHIS V2.0

21

JHLDEX20.DOC 2002/06/26

テーブル 0191 – 参照されるデータのタイプ
Value
AP
AU
FT
IM
Multipart
NS
SD
SI
TEXT
TX

Description
Other application data, typically uninterpreted binary data
Audio data (HL7 V2.3 and later)
Formatted text (HL7 V2.2 only)
Image data (HL7 V2.3 and later)
MIME multipart package
Non-scanned image (HL7 V2.2 only)
Scanned document (HL7 V2.2 only)
Scanned image (HL7 V2.2 only)
Machine readable text document (HL7 V2.3.1 and later)
Machine readable text document (HL7 V2.2 only)(HL7 V2.3 and later)

サブタイプは、参照されるデータのタイプのための書式を宣言するので、HL7テーブル
0291−参照されるデータのサブタイプを参照すること。
テーブル 0291 - Subtype of referenced data
Value
BASIC
DICOM
FAX
GIF
HTML
JOT
JPEG
Octet-stream
PICT
PostScript
RTF
SGML
TIFF
x-hl7-cda-level-one
XML

PL

Description
ISDN PCM audio data
Digital Imaging and Communications in Medicine
Facsimile data
Graphics Interchange Format
Hypertext Markup Language
Electronic ink data (Jot 1.0 standard)
Joint Photographic Experts Group
Uninterpreted binary data
PICT format image data
PostScript program
Rich Text Format
Standard Generalized Markup Language (HL7 V2.3.1 and later)
TIFF image data
HL7 Clinical Document Architecture Level One document
Extensible Markup Language (HL7 V2.3.1 and later)

患者所在
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)>

このデータ型は医療施設内の個人の所在場所を特定するため使用される。どのコンポーネントに値を付けるかはサイトの必要性によって異なる。それは患者の所在場所を特定するため使用されることが最も多いが、しかし医療施設内の患者以外の個人を指すことやその場所の状態を表現する場合もある。
看護単位とは診療室や病棟など部門をいう。場所の状態でベッドのあき状況などを表示する。所在場所のタイプをコードで表現する。
注：成分の順序によって、以前のバージョンのHL7と互換性がある。下位互換性の制約がない場合、成分の階層構造オーダーは次のようになる：<所在場所タイプ(IS)> ^ <施設(HD)>^ <階(IS)> ^ <看護単位(IS)> ^ <病室(IS)> ^ <ベッド(IS)> ^ <場所の詳細(ST)> ^ <場所の状態(IS)>。
PT 処理タイプ
Components:<processing ID (ID)> ^ <processing mode (ID)>

このデータ型は、HL7アプリケーションがHL7メッセージの処理をするべきか否か示す。
処理IDで、メッセージが生成、訓練あるいはシステムデバッギングかどうか定義する値。
有効な値については｢HL7テーブル0103−処理ID｣を参照すること。処理モ−ドで、メッセージが文書累積の処理あるいはイニシャルロ−ドの一部かどうか定義する。有効な値については｢HL7テーブル0207−処理モ−ド｣を参照すること。
DT 日付
常に書式YYYY[MM[DD]]で表記、桁数により精度が規定される。 例：|19880704|

Copyright©2002 JAHIS V2.0

22

JHLDEX20.DOC 2002/06/26

TM 時間Format:HH[MM[SS[.S[S[S[S]]]]]] [+/-ZZZZ]

以前のHL7バージョンでは、24時間表記法による書式HHMM[SS[.SSSS]][+/-ZZZZ]を常に使用していた。表記する桁数で精度が規定される。秒指定(SS)はオプションである。存在しない場合、分までの精度と解釈される。小数の秒指定は同様にオプションである。小数の秒は、秒より高い精度の時間を必要とする場合に送信される。分、時間、またはそれ以上の時間単位を小数で表記することはできない。発信者の時間帯は、万国標準時(以前はグリ
ニッジ標準時として知られていた)からのオフセットとしてオプションで送られることがある。発信者の時間帯が特定のTMフィールドに存在しないが、MSHセグメントの日時フィールドの一部として含まれる場合は、MSH値がデフォルトの時間帯として使われる。それ以外の場合、その時間は発信者の現地時間を参照するものと解釈される。真夜中は0000と表記する。
例：|235959+1130| 1 second before midnight in a time zone eleven and half hours ahead of Universal
Coordinated Time (i.e., east of Greenwich).
|0800| Eight AM, local time of the sender.
|093544.2312| 44.2312 seconds after Nine thirty-five AM, local time of sender.
TS タイム・スタンプ
Format: YYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]] [+/-ZZZZ] ^ <精度>
日付と時間を含む、イベントの正確な時間から成る。書式はつぎのようである。
YYYYLLDD[HHMM[SS[.SSSS]]][+/-ZZZZ]^<精度>
タイム・スタンプの日付部は日付フィールドの規則に従う。時間部は時間フィールドの規則に従う。表記する桁数により精度が規定される。すなわち、誕生日として使われるとき、
HHMM部が省略されれば日付であり、HHMM部を0000とすると、まさに明けようとしているその日の真夜中(0時0分)になる。HL7コード化規則の中で使われる特定のデータ表記は
ISO 8824-1987(E)との互換性がある。オプションの精度は下位互換性のためにあり、その日時の精度を示す(Y = 年、L = 月、D = 日、H = 時間、M = 分、S = 秒)。例:|17760704010159-0600| 1:01:59 on July 4, 1776 in the Eastern Standard Time zone.
|17760704010159-0500| 1:01:59 on July 4, 1776 in the Eastern Daylight Saving Time zone.
|198807050000| Midnight of the night extending from July 4 to July 5, 1988 in the local time zoneof the sender.
|198807050000^D| Same as prior example, but precision extends only to the day. Could be used fora birthdate.(＝|19880705|)
HL7規格では、すべてのシステムが日常的に時間帯オフセットを送るよう強く推奨するが、強制はしない。HL7システムではすべて時間帯オフセット受け入れる必要があるが、その実装はアプリケーションに任される。多くのアプリケーションの場合、関心ある時間はその発信者の現地時間である。たとえば、東部標準時間帯にあるアプリケーションが12月11
日午後11:00にサンフランシスコで入院が発生したという通知を受けた場合、その入院を12月12日ではなくて(現地時間の)12月11日に発生したものとして扱うのがよい。
この規則における例外は、臨床システムが、互いに近くに存在しながら時間帯の異なる複数の病院で収集された患者データを処理する場合である。そのようなアプリケーションは、
そのデータを共通の表記に変換することがある。同じような問題は、サマータイムとの切り替え時にも発生する。HL7は、情報の送信時に時間帯情報を含めるようにすることで対応する。しかし、ここで検討した処理のどちらを受信システムが採用するかは指定しない。
CE コード化値
Components: <identifier識別子 (ST)> ^ <textテキスト (ST)> ^ <name of coding systemコーディング方式
名 (IS)> ^ <alternate identifier代替識別子 (ST)> ^ <alternate text代替テキスト (ST)> ^ <name of alternate
coding system代替コーディング方式名 (ST)>例：|54.21^Laparoscopy^I9^42112^^AS4||F-11380^CREATININE^I9^2148-5^CREATININE^LN|
このデータ型は、コード、およびそのコードと関連するテキストを送る。この型は、次にCopyright©2002 JAHIS V2.0

23

JHLDEX20.DOC 2002/06/26

述べる通り、代替成分を含め6個の成分を持つ：
識別子： 後ろの<text>によって参照される項目を一意に識別する文字列(コード)。異なるコーディング方式では、異なる要素を持つ。
テキスト： 問題としている項目の名前または記述。たとえば、心筋梗塞とかX線撮影所
見など。そのデータ型は文字列(ST)である。
コーディング方式名： コーディング方式には一意な識別子が割り当てられる。この成分は、識別子成分内で使われているコーディング方式を識別するのに役立つ。識別子成分とコーディング方式名成分の組合せは、データに対して一意なコードである。ここに指定されるコーディング方式の例は、ICD-9、ICD-10、SNOMEDなどである。各方式には一意な識別文字列が与えられる。ここにHL7テーブルを使用する場合、HL7テーブル番号をnnnnとしHL7nnnnとして定義する。
代替成分： 3つの代替成分は、上記と同様、代替方式または現地コーディング方式を定義するためにある。代替テキスト成分が存在せず、代替識別子が存在すると、代替テキス
トはテキスト成分と同じであると解釈される。代替コーディング方式成分が存在しない場
合、それはローカル定義の方式であると解釈される。
注記： このデータ型では2組の等価コードを表現しているが、それはCE型フィールドの反復とは意味が違っている。反復を用いる場合は、いくつかの明瞭なコード(明瞭な意味を持つコード)を送信するのが普通である。
CNE 例外なしコード化値
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 コーディング方式バージョン
ID(ST)> ^ < alternate coding system version ID 代替コーディング方式バージョンID(ST)> ^ <original text
オリジナルテキスト(ST)>

第1成分はユニークな文字のつながり（コード）である <テキスト>を参照するための識別項目である。異なるコード化の要素を持つ。
第2成分は問題の項目の名前を記述。例えば心筋梗塞あるいはX線の印象。そのデータ・タ
イプは文字列である。これは識別子にコーディング方式によって割り当てられるテキストである。
第3成分のそれぞれのコーディング方式には一意な識別子を割り当てられる。 この成分は識別子成分で使われて符号体系を識別するのに役立つ。
識別子成分とコーディング方式名成分の組合せはデータ項目に一意なコードである。 それぞれの方式は一意な識別文字列を持っている。
使用者定義テーブル0396−コーディング方式(HL7-節7.18.1参照)−が許されている値を含んでいる。このテーブルは｢ASTM E1238 –94、診断、処置、検査、薬剤ID、健康結果｣コー
ディング方式を含み、HL7-節7.2.5のテーブルで識別される。 必要に応じて、他の方式が追加される。
コード集合を発行するいくつかの機関が１つ以上を著作する。
それから、ユニークであるコーディング方式はコーディング権限機関の名前とそのコードセットあるいはテーブルの名前の結合である。
HL7 テーブルが CE データタイプのために使われるとき、コーディング方式名成分は nnnn
が HL7 テーブル番号である HL7nnnn と定義される。 同様に、ISO テーブルが ISOnnnnと命名される。そこでは nnnn は ISO テーブル番号である。
第4成分は上の｢識別子｣に類似している。データタイプCNEの｢使用上の注意｣を参考。
第5成分は上記の｢テキスト｣に類似している。データタイプCNEの｢使用上の注意｣を参考。
第6成分は上記の｢コーディング方式の名前｣に類似している。データタイプCNEの｢使用上の注意｣を参考。
第7成分は第1成分-第3成分によって識別されるコーディング方式のためのバージョンＩＤである。それは概念的に第1成分-第3成分に属して、そして逆方向互換性の理由だけのためにここで現われる。
第8成分は第4成分-第6成分によって識別されるコーディング方式のためのバージョンＩＤである。それは（データタイプCEの第6成分を参照）概念的に代わりのコンポーネントのグループに帰属して、そして逆方向互換性の理由だけのためにここで現われる。

Copyright©2002 JAHIS V2.0

24

JHLDEX20.DOC 2002/06/26

第9成分は特定のコードの前に自動化されたプロセスあるいは人に利用可能であったオリ
ジナルのテキストは割り当てられた。この部品はオプションである。
使用上の注意：第1成分-第3成分と第7成分：識別子は必要とされて、そして正当なコードであるに違いない。コーディング方式はあるいは存在していて、そして許されたコーディング方式のセット
から値を持っていなくてはならない、あるいはもし存在していないなら、それはコードが「 HL7 コーディング方式」を意味するという状態で、もしそれが高く評価されたならと比べて同じ意味を持つと解釈されるであろう。
使用者定義テーブル0396−コーディング方式(HL7-節7.18.1参照)−が許されている値を含んでいる。もしコーディング方式が「 HL7 コーディング方式」以外のどんな方式でもあるな
ら、バージョンＩＤが実際のバージョンＩＤで高く評価されなくてはならない。
もしコーディング方式が「 HL7 コーディング方式」であるなら、バージョンＩＤは実効値を持っているかもしれない、あるいは存在しないかもしれない。 もしバージョンＩＤが存在しないなら、それはメッセージヘッダで HL7 バージョン番号と比べて同じ値を持っていると解釈されるであろう。
コードのテキスト記載は任意である、しかし、それがメッセージを正確度のために、特にインタフェース検査とデバッギングの間に再検討することがより容易であるようにするので、その使用は奨励されるべきである。
第9成分：これは、特定の規約が割り当てられる前に、自動化されたプロセスあるいは人に利用可能であったオリジナルのテキストである。この部品はオプションである。
第4成分-第6成分と第8成分：これらの成分はオプションである。
記述されるように、それらはローカルであるか、あるいはユーザによって見られるコードを表すために使われる。
もし存在しているなら、第4成分-第6成分と第8成分は第1成分-第3成分と第7成分の記述と同じ使用規則と翻訳に従う。
もし両方ともが存在しているなら、第4成分と第1成分のアイデンティファイアは正確に同じ意味を持つべきである、すなわち、それらは正確な同義語であるべきである。
CNE 使用法ノート：必要とされるか、あるいは義務的なコードされたフィールドが必要とされるとき、CNE データタイプは使われるべきである。
使用者定義テーブル0396−コーディング方式−が許されている値を含んでいる。
このテーブルは｢ASTM E1238 –94、診断、処置、検査、薬剤、健康結果｣コーディング方式を含む。
HL7 テーブルが CE データタイプのために使われるとき、コーディング方式名成分は nnnn
が HL7 テーブル番号である HL7nnnn と定義される。
それらの使用法のガイドラインがHL7-チャプタ−7、節7.1「序論と概要」で説明される。
例:1. もしOBXセグメントの値タイプ(Value Type)フィールド(2を順番に並べる)が型CNEであると定義され、deに生ませられた値型が数だったならば、値型フィールドの最短の表現
は現在のIDフィールド・シンタックスと同一でしょう:
OBX|1|NM|718-7＾Hemoglobin＾LN||13.4|GM/DL|14-18|N||S|F<cr>
テキストを含んでいたのと同じOBXセグメントのより冗長な表現は、次のとおりでしょう:
OBX|1|NM＾Numeric|718-7＾Hemoglobin＾LN||13.4|GM/DL|14-18|N||S|F<cr>
テキストとコーディング方式を含む同じOBXセグメントのさらに冗長な表現は、次のとおり
でしょう:
OBX|1|NM＾Numeric＾HL70125|718-7＾Hemoglobin＾LN||13.4|GM/DL|14-18|N||S|F<cr>
データを作成したオリジナルのシステムの中で使用されるコードに関する情報を保持するために、スキーム・データをコード化する選択肢を含んでいることができるかもしれません:
OBX|1|NM＾Numeric＾HL70125＾NUM＾Number＾99LAB|718-7＾Hemoglobin＾
LN||13.4|GM/DL|14-18|N||S|F<cr>
上記のものに加えて、人が使用されている語いのバージョンを捕らえ、HL7バージョンが2.3.1”およびスキーム・バージョンをコード化する99LABだった場合 1.1”だった、フィール?hは次のように現われるでしょう。

Copyright©2002 JAHIS V2.0

25

JHLDEX20.DOC 2002/06/26

OBX|1|NM＾Numeric＾HL70125＾NUM＾Number＾99LAB＾2.3.1＾1.1|718-7＾
Hemoglobin＾LN||13.4|GM/DL|14-18|N||S|F<cr>
更に、もし人が値フォーマットの user seen”テキストを含みたく、ユーザがデータ・エン
トリー・スクリーン上のフィールド・タイプとして Decimal”を見たならば、フィールドは次のように現われるでしょう:
OBX|1|NM＾Numeric＾HL70125＾NUM＾Number＾99LAB＾2.3.1＾1.1＾Decimal|718-7＾
Hemoglobin＾LN||13.4|GM/DL|14-18|N||S|F<cr>
最終的に、ユーザは本来のIDの代わりに略記号を使用し、別名のIDとして長い書式を使用することができた。
OBX|1|NM＾＾＾NUM＾Number＾99LAB＾＾1.1＾Decimal|718-7＾Hemoglobin＾
LN||13.4|GM/DL|14-18|N||S|F<cr>
2. もし値タイプ･フィールドがCNEフィールドとして定義されていたならば、および希望の値タイプが値セットの中になかった場合、有効なOBXインスタンスを作成することができない。 例えば、もし検査システムが内部値タイプの Decimal Range”を持っていれば、HL7テーブル0125に利用可能な対応する値タイプがないので、有効なOBXインスタンスを作成することができない。 次の事例は正しくない。 CNEフィールドのすべての有効なインスタンス中で、IDフィールドは、指定されたテーブルからの有効な値を持っていなければならない。
正しくない(有効なIDがない)
OBX|1|＾＾＾DR＾Decimal Range＾99LAB＾＾1.1＾Decimal Range|718-7＾Hemoglobin＾
LN||13.4|GM/DL|14-18|N||S|F<cr>
3. コーディング･スキームがHL7テーブルのID以外である場合、コーディング･スキームは
HL7-チャプタ−7の中で指定されたコーディング･スキームから得られる有効なスキームでなければならない。 例えば、もしOBXセグメントの検査項目フィールド(OBX-3)がCNEフィールドとしてタイプされ、LOINCバージョン1.0kが検査項目に対するソースとして使用されていたならば、次のOBX事例は有効でしょう:
OBX|1|NM|718-7＾Hemoglobin＾LN＾＾＾＾1.0k||13.4|GM/DL|14-18|N||S|F<cr>
しかしながら、コーディング･スキーム指示 LOCAL”が、有効なコーディング･スキームのIDリストに載っておらず、また、それも有効で local”なコーディング･スキームのIDを作成のためにHL7-チャプタ−7に記述された規則に順応しないので、次のOBX事例は正し
くないであろう。
正しくない(無効なコーディング･スキーム)
OBX|1|NM|9587-2＾Hemoglobin＾LOCAL＾＾＾＾1.0k||13.4|GM/DL|14-18|N||S|F<cr>
ローカルのコーディング･スキーム 99LAB”を使用する有効なOBXインスタンスは、99LAB”がHL7-チャプタ−7に記述されるいるようにローカルのコーディング･スキームを指定するための規則に適合しているので、許可される。 有効なOBX事例は以下のように表わされる：
OBX|1|NM|9587-2＾Hemoglobin＾99LAB＾＾＾＾6.5||13.4|GM/DL|14-18|N||S|F<cr>コーディング･スキームがHL7テーブルのID以外である場合、最終的には、バージョン番号は存在しなければならない。 たとえコーディング･スキームLN(LOINC)が有効でも、有効なバージョン番号が抜けているので、次のOBX事例は正しくない：
正しくない(見当たらないバージョン番号)
OBX|1|NM|718-7＾Hemoglobin＾LN||13.4|GM/DL|14-18|N||S|F<cr>
CWE 例外を含むコード化値
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 コーディング方式バージョン
ID(ST)> ^ < alternate coding system version ID 代替コーディング方式バージョンID(ST)> ^ <original text
オリジナルテキスト(ST)>

第1成分：文字のつながり（コード）それはユニークに < テキスト>によって参照されて項Copyright©2002 JAHIS V2.0

26

JHLDEX20.DOC 2002/06/26

目を識別する。異なったコード化方式がここで異なった要素を持つであろう。
第2成分：問題の項目の名前あるいは記載。例えば、 myocardial 梗塞あるいはレントゲン
写真印象。
第3成分：それぞれのコーディング方式がユニークな識別子を割り当てられる。
このコンポーネントは識別子コンポーネントで使われて符号体系を識別するのに役立つであろう。
識別子成分とコーディング方式名成分の組合せはデータ項目に一意なコードである。 それぞれの方式は一意な識別文字列を持っている。
使用者定義テーブル0396(HL7-節7.18.1参照)-コーディング方式-が許されている値を含んでいる。テーブルは｢ASTM E1238 –94、診断、処置、検査、薬剤ID、健康結果｣と、ASTM-7.1.4
でテーブルで識別されるように、コードしている「コード化方式」を含む。必要に応じて、他の方式が追加される。
コード集合を発行するいくつかの機関が１つ以上を著作する。
それから、ユニークであるコーディング方式はコーディング権限機関の名前とそのコードセットあるいはテーブルの名前の結合ある。
HL7 テーブルが CE データタイプのために使われるとき、コーディング方式名成分はnnnn が HL7 テーブル番号である HL7nnnn と定義される。
同様に、 ISO テーブルが ISOnnnn と命名されるであろう、そしてそこで nnnn は ISO テ
ーブル番号である。
第4成分：上の｢識別子｣に類似している。データタイプCWEの｢使用上の注意｣を参照。
第5成分：上記の｢テキスト｣に類似している。データタイプCWEの｢使用上の注意｣を参照。
第6成分：上記の｢コーディング方式の名前｣に類似している。データタイプCWEの｢使用上の注意｣を参照。
第7成分：これは第1成分-第3成分によって識別されるコーディング方式のためのバージョンＩＤである。それは概念的に構成する第1成分-第3成分のグループに帰属して、そして逆
方向互換性の理由だけのためにここで現われる。
第8成分：これは第4成分-第6成分によって識別されるコーディング方式のためのバージョン
ＩＤである。それは概念的に代わりの成分のグループに帰属する（見なさい、と０が指摘する、上記の「テキスト」に類似している。データタイプCWEの「使用上の注意」を参照。
第9成分：特定の規約が割り当てられる前に、自動化されたプロセスあるいは人に利用可能であったオリジナルのテキスト
使用上の注意：こちらは一般に送られるフィールドがコード、しかしどこにコードが卓越したインスタンスであるいはサイト契約によって除かれるかもしれないか使っている。
使われているコーディング方式がテキストでコンセプトを記述するためにコードを持っていないとき、卓越した事例が起こる。
1) Coded ：識別子はコーディング方式から正当なコードを含んでいる。
コーディング方式はあるいは存在していて、そして許されたコーディング方式のセットから、あるいはもし存在していないなら値を持っていなくてはならない、それはコードが「 HL7 コーディング方式」を意味するという状態で、もしそれが高く評価されたならと比べて同じ意味を持つと解釈されるであろう。
使用者定義テーブル0396-コーディング方式が許されている値を含んでいる。
テーブルは｢ASTM E1238 –94、診断、処置、検査、薬剤ID、健康結果｣と、ASTM-7.1.4でテーブルで識別されるように、コードしている「コード化方式」を含む。
もしコーディング方式が「 HL7 コーディング方式」以外のどんな方式でもあるなら、バージョンＩＤが実際のバージョンＩＤで高く評価されなくてはならない。
もしコーディング方式が「 HL7 コーディング方式」であるなら、バージョンＩＤは実効値を持っているかもしれない、あるいは存在しないかもしれない。 もしバージョンＩＤが存在しないなら、それはメッセージヘッダで HL7 バージョン番号と比べて同じ値を持っていると解釈されるであろう。
テキスト記述は任意である、しかしその使用はテストの間のそしてデバッグするメッセー
ジの判読性で支援に奨励されるべきである。

Copyright©2002 JAHIS V2.0

27

JHLDEX20.DOC 2002/06/26

例 1a ： CWE 値と値が SNOMED ・インターナショナルから取られる（とき・から・につれて・ように）、観測識別子が LOINC コードと観測値である OBX 部分が送られている。
OBX￨1￨CWE￨883‑9^ABOGroup^LN￨1￨F‑D1250^TypeO^SNM3^^^^3.4￨￨￨N￨￨F<cr>
例 1b ：観測識別子が LOINC コードと観測値である OBX 部分が CWE 値として送られている、そして値は（現在仮説の） HL7 テーブルから取り出される。
OBX￨1￨CWE￨883‑9^ABOGroup^LN￨1￨O^Type O^HL74875^^^^2.3.1￨￨￨N￨￨F<cr>2) Uncoded ：テキストが高く評価される、識別子は値を持っていない、そしてコーディン
グ方式とバージョンＩＤがオプション１のために論じられると比べて同じ規則に従う。
例２：検査結果IDをLOINCコードとする OBXセグメントと検査結果が CWE値として送られており、そして、正しい臨床結果「Wesnerian」が許容値の中に見いだされなかったことのテキストとして送られる。
OBX￨1￨CWE￨883‑9^ABO Group^LN￨1￨^Wesnerian^SNM3^^^^3.4￨￨￨A￨￨F<cr>3) データ消失：コーディング方式の名前は「 HL7 CE 状態」である、バージョンＩＤが１
レアルいずれかであるバージョン、あるいはもし存在していないなら、それはメッセージ
ヘッダでバージョンと比べて同じ意味を持っている、そして識別子は許された CE フィー
ルド statuses の１人からその値を取る。
許された CE フィールド statuses のコードは下に示されて、そして HL7 用語の一部としてテーブルで維持されるであろう。
コードのテキスト記載は任意である。
例３：検査結果IDをLOINCコードとするOBXセグメントと検査結果が LCE値として送られており、この検査がされなかったことから送られることができる値がない。
OBX￨1￨CWE￨883‑9^ABOGroup^LN￨1￨NAV^NotAvailable^
HL70353^^^^2.3.1￨￨￨N￨￨F<cr>
第9成分：これは、特定の規約が割り当てられる前に、自動化されたプロセスあるいは人に利用可能であったオリジナルのテキストである。このフィールドは任意である。
第4 - 6成分＆第8成分：成分4-6＆8は任意である。
それらはローカルまたはユーザによって見られたコードを表すために使われる。
もし存在しているなら、第4 - 6成分と第8成分は（CWE データタイプの）第1 - 3成分と第7成分の記述と同じ使用規則と翻訳に従う。
もし両方ともが存在しているなら、第４成分と第１成分でのアイデンティファイアは正確に同じ意味を持つべきである；すなわち、それらは正確な同義語であるべきである。
例４：検査結果IDをLOINCコードとするOBXセグメントと検査結果が CWE値として送られており、結果は SNOMED インターナショナルから得られる。
ユーザによって見られたフィールドは（ 99LAB ）が送信しているシステムで使ったローカ
ルなコーディング方式を表すために使われている。
OBX￨1￨CWE￨883‑9^ABOGroup^LN￨1￨F‑D1250^TypeO^SNM3^O^Otype
Blood^99LAB^3.4^￨￨￨￨￨F<cr>
CWE 使用法のサマリーが値がない種々の国家のために状態値のテーブルで指摘する：データ
タイプが（そのために）使われるべきである CWE は任意である、あるいはもうではなく公認の値セットの一部である項目のためのテキストを送ることは許されるフィールドをコードした。
標準的な状況で、識別子は値セットからコードで高く評価される。
もしフィールドの値が知られているが、値セットの一部ではないなら、テキストと識別子が値を持っていない（とき・から・につれて・ように）、値は送られる。
もしフィールドが未知の状態を持っているなら、フィールドの３番目のフォームが（上にデータ消失を見なさい）使われる、そしてフィールドのための適切な状態は許された statuses のテーブルから選択される。
コードが存在しないとき、 HL7テーブル0353を利用する。

Copyright©2002 JAHIS V2.0

28

JHLDEX20.DOC 2002/06/26

テーブル 0353 – CWEステータス
Value
U
UASK
NAV
NA
NASK

Description
Unknown
無し
Asked but Unknown 返答無し
Not available 利用可能でない
Not applicable 適用可能でない
Not asked
問い合わせなし

テキスト変更子がコードに伴うかもしれないところに、 HL7 メッセージの「フィールド」はデータタイプ CWE のことであるであろう、そして繰り返すことを許されるであろう。
フィールドの最初のインスタンスは、オプション１に従って、使われるであろう；すなわち識別子は正当なコードを持っているであろう。
繰り返すフィールドの２番目のインスタンスは使われるであろう、オプション２に従って、
すなわち、テキスト記載は自由なテキスト変更子の値をとるであろう。
CF 書式付コード化値
Components: <identifier識別子 (ID)> ^ <formatted text書式付テキスト (FT)> ^ <name of coding system
コーディング方式名 (IS)> ^ <alternate identifier代替識別子 (ID)> ^ <alternate formatted text代替書式付テキスト (FT)> ^ <name of alternate coding system代替方式名 (IS)>

このデータ型は、コード、およびそのコードと関連する書式付テキストを送る。このデー
タ型は、レポートの詰め込みテキスト部に使用する書式付テキスト(たとえば、単純胸部X線について標準的に記述された放射線所見など)を初めて送る場合に使用する。受信システ
ムは、この情報を保存し、次のメッセージではその識別子だけを送信すればよい。このデータ型のもう一つの考えられる使用法は、書式付テキストを含むマスターファイル・レコードを送ることである。主要成分、代替成分とも、第2成分および第5成分が書式付テキス
ト・データ型であるという点を除いて、CEデータ型の場合と全く同様に定義される。
例：
OBX||CF|71020^CXR^CPMC||79989^\H\Description:\N\\.sp\\ti+4\Heart is not enlarged. There isno evidence of pneumonia, effusion, pneumothorax or any masses.
\.sp+3\\H\Impression:\N\\.sp\\.ti+4\Negative chest.^CPMC
CK チェック・ディジット付き複合ID
Components: <ID number ID番号 (NM)> ^ <check digitチェックデジット (NM)> ^ <code identifying thecheck digit scheme employedチェックデジット方式 (ID)> ^ < assigning authority割当権限者(HD)>

このデータ型は、たとえばPID-3-患者ID(内部ID)など、通常チェック・ディジットを含むフィールドで使われる。 現場で、あるCKフィールドにチェック・ディジットを使っていな
い場合、第2、第3成分はNullである。
例： |128952^6^M11^ADT01|
このデータ型のチェックデジットは、メッセージ処理システムが追加生成するわけではない。 それは、送信アプリケーション内で使われる識別番号に含まれる。 送信アプリケーシ
ョンが識別番号内にチェックデジットを含まない場合、この成分はnullとすべきである。
チェックディジット方式は、HL7テーブル0061 − チェックディジット方式で定義する。
テーブル0061−チェックディジット方式
値
NPI
ISO
M10
M11

記述
Check digit algorithm in the US National Provider ldentifier
ISO 7064: 1983
Mod 10 アルゴリズム
Mod 11 アルゴリズム

Mod10チェック・ディジットを計算するためのアルゴリズムは以下の通り
あなたが識別子=12345を持つと仮定する。右側から数えて奇数桁、つまり531を考える。この数を2倍して1062を得る。右から数えて偶数桁、すなわち42を取り、これに1062を付けた
して421062を得る。この数字の6桁すべてを加算して15を得る。15の次に大きい10の倍数か
らこの数を減ずる、つまり20-15により5を得る。これがMod10である。401の場合のMod10
チェック・ディジットは0である；9999の場合は4である；99999999の場合は8である。
Mod11チェック・ディジットを計算するためのアルゴリズムは以下の通り。

Copyright©2002 JAHIS V2.0

29

JHLDEX20.DOC 2002/06/26

用語
d = 1の位から始まり、以降10の位、100の位、．．．と続く各位の数字
w = 1の位から始まり、以降10の位、100の位、．．．と続く各位の重み。Wの値は2、3、4、5、6、7、2、3、4、5、6、7、．．．と続く(6桁単位で繰り返す)
c = チェック・ディジット
計算(ステップ1) m = 1の位から開始し、それぞれの位について計算した(d * w)の合計
d = 1の位から最高桁の位までの各桁の数字
w = 1の位から始まり、6桁単位で繰り返す2から7までの各桁の重み(ステップ2) c1 = m mod 11(ステップ3) c1 =0の場合はc1 =1に置き換える。
(ステップ4) c =(11−c1) mod 10
例: if the number is 1234567, then the mod 11 check digit = 4
計算は以下の通り
m =(7*2)+(6*3)+(5*4)+(4*5)+(3*6)+(2*7)+(1*2)= 14 + 18 + 20 + 20 + 18 + 14 + 2= 106
c1 = 106 mod 11=7
c = (11-c1) mod 10= 4 mod 10= 4
上記以外のチェック・ディジットは、現場双方の取り決めにより使うことができる。
CN 複合ID番号および名前
Components: <ID number ID番号(ST)> ^ <family name 姓(FN)> ^ <given name洗礼名 (ST)> ^ < secondand further given names or initials thereof 中間名のイニシャルあるいは名前(ST)> ^ <suffix (e.g., JR or
III) サフィクス (ST)> ^ <prefix (e.g.,DR) プレフィックス(ST)> ^ <degree (e.g., MD) 学位 (IS)> ^<source tableソーステーブル (IS)> ^ <assigning authority割当権限者(HD)>Subcomponents of family name: <surname (ST)> ^ <own surname prefix (ST)> ^ <own surname (ST)>^<surname prefix from partner/spouse (ST)> ^ <surname from partner/spouse (ST)>

コード値およびテキスト名により人物を識別するフィールド。 特定のフィールドでは、それぞれの現場でIDまたは名前を省略することができる。
例： |12372^RIGGINS^JOHN^""^""^""^MD^ADT1||12372^^^^^^^ADT1||^RIGGINS^JOHN^""^""^""^MD|
第1成分は第8の成分によって定義された使用者定義テーブルによりコード化されたID。 第1の成分が存在する場合、ソーステーブルあるいは割当権限者が評価されねばならない。
第2成分は姓を表す。
第3成分は洗礼名を表す。
第4成分は中間名のイニシャルあるいは名前を表す。
第5成分は名前のサフィクスを指定するため使用される（例えばジュニアあるいは3世）。
第6成分は名前のプレフィックス指定するため使用される（例えばDr）。
第7成分は学位を指定するため使用される（例えばMD）。 推奨値については「使用者定義
テーブル 0360 - 学位」を参照すること。
第8成分の推奨値については「使用者定義テーブル0297−CN・IDソース」を参照すること。
第1の成分を描写するため使用される。
使用者定義テーブル0297−CN ･IDソース
Value

Description
No suggested values defined

推奨できる値はない

第9成分：このバージョンでは、オプションの9番めの成分、割当権限者を加えた。 それはHDデータタイプである。

Copyright©2002 JAHIS V2.030

JHLDEX20.DOC 2002/06/26

CX チェックデジット付拡張複合ID
Components: <ID (ST)> ^ <check digitチェックデジット (ST)> ^ <code identifying the check digit
scheme employedチェックデジット方式 (ID)> ^ < assigning authority割当権限者 (HD) )> ^ <identifier
type code IDタイプコード (IS)> ^ < assigning facility割当施設 (HD) > ^ <effective date 有効日付(DT)> ^<expiration date満了日付 (DT)>例：|1234567＾4＾M11＾ADT01＾MR＾University Hospital|
ID：CKデータ型と同様、ただしSTデータ型がNM・データ型の代わりに許可される。
チェックデジット：CKデータ型と同様、ただしSTデータ型がNM・データ型の代わりに許可される。このチェックデジットはメッセージ処理で追加されるものではなく、送信アプリ
ケーションの中で使用される識別番号の一部である。送信アプリケーションが識別番号中にチェックデジットを含んでいない場合、この値はヌルであるのがよい。
識別子タイプコード：IDのタイプに対応するコード。ある場合には、｢割当権限｣成分への修飾語としてこのコードを使用してもよい。
使用者定義テーブル0203−識別子タイプ
Value
AM
AN
BA
BR
BRN

Description
アメリカン・エキスプレス
勘定番号
銀行勘定番号
出生登録番号
品種登録番号

Value
MS
NE
NH
NI
NNxxx

DI
DL
DN
DR
DS
EI
EN
FI
GI
GN
HC
JHN
LN
LR
MA
MC
MCN
MR

ダイナーズクラブ・カード
運転免許証番号
医師番号
ドナー登録番号ディスカバー・カード
従業員番号
雇用者番号
設備ID
保証人内部ID
保証人外部ID
保健証番号
管轄区域の保健番号(カナダ)
免許番号
地方登録ID
メディケイド番号
メディケア番号
マイクロチップ番号
医療記録番号

NPI
PEN
PI
PN
PRN
PT
RR
RRI
SL
SR
SS
U
UPIN
VN
VS
WC
WCN
XX

Description
マスターカード
米国雇用者ID
米国保健計画ID
米国個別ID
米国個人ID XXX=ISOテーブル3166の3文字(アルファベット)の国コード
米国プロバイダーID
年金番号
患者内部ID
個人番号
プロパイダー番号
患者外部ID
鉄道退職番号
地方登録ID
滞在許可
滞在登録ID
社会保障番号
無指定
メディケア/HCFAの汎用医師ID
訪問回数
ビザ
WIC ID
労働者番号
組織ID

XCN 拡張複合IDと名前
Components: <ID number ID番号 (ST)> ^ <family name姓 (FN)> ^ <given name 洗礼名 (ST)> ^<second and further given names or initials thereof セカンドネームまたはイニシャルの頭文字(ST)> ^<suffix接尾辞 (e.g., JR or III) (ST)> ^ <prefix接頭辞 (e.g., DR) (ST)> ^ <degree学位 (e.g., MD) (ST)> ^<source tableソーステーブル (IS)> ^ <assigning authority割当て権限者 (HD)> ^ <name type code名前タ
イプコード(ID)> ^ <identifier check digitチェックデジット (ST)> ^ <code identifying the check digit
scheme employedチェックデジット方式 (ID )> ^ <identifier type code識別タイプコード (IS)> ^<assigning facility割当て施設 (HD)> ^ <name representation code名前表示コード(ID)> ^ <name context
名前コンテキスト(CE)> ^ <name validity range名前有効範囲(DR)> ^ <name assembly order 名前の組み立て指示(ID)>

コード値およびテキスト名により人物を識別するフィールド。 第1成分は、第8の成分で示されるテーブルに従ったIDである。 第2成分から第7成分は人物名を表すPNフィールドである。 第8成分は、第1成分で使われるソース・テーブルを指定する。 特定の現場では、それぞれの現場でIDまたは名前を省略することができる。名前タイプコードについては、
XPN−拡張人名を参照。 識別タイプコードは｢使用者定義テーブル0203−識別子タイプ｣を参照すること。

Copyright©2002 JAHIS V2.0

31

JHLDEX20.DOC 2002/06/26

例: |12372^RIGGINS^JOHN^""^""^""^MD^ADT1||12372||^RIGGINS^JOHN^""^""^""^MD||1234567＾Smith＾John＾J＾III＾DR＾PHD＾ADT01＾＾L＾4＾M11＾MR|
CM 複合フィールド
他の有意データ・フィールドと組合せるフィールド。それぞれの部分は成分と呼ばれる。
CMフィールドの特定成分は、そのフィールド記述の範囲内で定義される。その他個別に識別される複合フィールドもあり、それについては以下に記述する。このデータ型の使用は発展的に解消し、独自のデータ型を新たに作成する予定である。
HL7フィールドの成分そのものが成分を含むHL7データ型である場合、その区切り文字は一
ランク下位に落とされる。したがって、CEデータ型として示された成分は、<識別子&テキスト&コーディング方式名>としてコード化すべきである。HL7区切り文字は再帰的でない
ので、成分を含むHL7データ型は副成分となりえないことに注意。このレベルの詳細情報が必要な場合、HL7データ型の各成分は、別々の副成分としてコード化することができる。
この例に関しては、タイミング/数量データ型のオーダーシーケンス化成分にある実施者オーダー番号のコード化方式を参照のこと。
AD

address 住所
Components: <street address 行アドレス(ST)> ^ < other designationその他の表示 (ST)> ^ <city
都市 (ST)> ^ <state or province州あるいはプロビンス(ST)> ^ <zip or postal code ZIPまたは郵便番号(ST)> ^ <country国 (ID)> ^ <address type アドレス・タイプ(ID)> ^ <other geographic
designation 他の地理的な表示(ST)>例： ￨10 ASH LN^#3^LIMA^OH^48132￨
第1成分は個人あるいは施設の道路あるいはメーリングアドレス。施設を参照するとき、この最初のコンポーネントは施設名を指定するために使われる。 個人に関連して使われるとき、このコンポーネントはアドレスの最初の行を指定する。
第2成分はアドレスの2行目。一般に、それはアドレスを修飾する。 例：555号室、あるいは4階。 施設を参照するとき、このコンポーネントは番地を指定する。
第3成分は都市名
第4成分は州あるいはプロビンスはその国の公式の郵便コードによって表わすのがよい。
第5成分はZIPまたは郵便番号はその国の公式のコードによって表わすのがよい。
米国のZIPの形式は99999[−9999]の形式であり、カナダの郵便番号の形式はA9A9A9である。
日本の形式は999-9999である。
第6成分はアドレスの国を定義する。ISOの3166は、使用できる国コードの一覧表を提供し、３個のパートに分かれている。 HL7は３文字の（アルファベット順の）書式が国コードのために使われることを明示する。
第7成分のタイプはオプションであり、HL7テーブル0190−アドレスタイプによって定義される。
テーブル0190−アドレスタイプ
Value
BA
N
BDL
F
C
B
H
L
M
O
P
RH

BR

Copyright©2002 JAHIS V2.0

Description
Bad address 良くないアドレス
Birth (nee) (birth address, not otherwise specified) 出生地（旧姓地）
Birth delivery location (address where birth occurred) 出身地
Country Of Origin 出生国
Country Of Temporary 臨時国
Firm/Business 会社 / ビジネス（勤務地）
Home 自宅
Legal Address
Mailing 郵便宛先
Office 職場（事業所）
Permanent
Registry home. Refers to the information system, typically managed by a public healthagency, that stores patient information such as immunization histories or cancer data,
regardless of where the patient obtains services.
Residence at birth (home address at time of birth) 出生時の住宅（出生の時間においてのホームアドレス）

32

JHLDEX20.DOC 2002/06/26

第8成分は他の地理的な表示は郡、自然生態地域、標準大都市統計圏などを含んでいる。
FN

family name 姓
Components: <surname (ST)> ^ <own surname prefix (ST)> ^ <own surname (ST)> ^ <surname prefixfrom partner/spouse (ST)> ^ <surname from partner/spouse (ST)>

このデータタイプは人の姓のフルの仕様書を許す。
適切である場合は、それはその人のパートナーあるいは配偶者のそれから、その人の名前がいずれかの名前から要素を含むかもしれないケースでその人自身の姓を区別する。
更にメッセージでは姓接頭辞(例えば バン あるいは ドゥ )と性ルートを区別することができる。
注意：PN と他の PN を含んでいるデータ型（PPN、XCN、XPN）にだけ現われる。
第1成分はその人の姓の原子の要素。最も西洋の使用法で、これはその人の姓である。
第2成分はゲルマン語のための国際化使用法。この部品はオプションである。
第3成分は旧姓を現す。
第4成分はゲルマン語のための国際化使用法。この部品はオプションである。
第5成分はその人のパートナーあるいは部分から同じぐらい著名な配偶者の姓から得られる
その人の姓（たいていの西洋の使用法、姓で）の部分がその人の自身の姓から生じた。この部品はオプションである。もしその人の姓の部分がその人のパートナーあるいは配偶者の姓から得られないなら、このコンポーネントは高く評価されない。さもなければ、もしパート
ナーあるいは配偶者の姓が合法的にその人の姓に似合って、（あるいは含む）ために変化したなら、これはこのような変更の前にすぐにパートナーあるいは配偶者の姓である。
PN

person name 人名
Components: <family name姓 (FN) > ^ <given name 洗礼名(ST)> ^ < second and further given names
or initials thereof 中間名のイニシャルあるいは名前 (ST) > ^ <suffix (e.g., JR or III) サフ
ィクス (ST)> ^ <prefix (e.g., DR) プレフィックス (ST)> ^ <degree (e.g., MD) 学位 (IS)>
Subcomponents of family name: <surname (ST)> & <own surname prefix (ST)> & <own surname (ST)>& <surname prefix from partner/spouse (ST)> & <surname from partner/spouse (ST)>

名前は複数のフリーテキスト成分から成る。PNフィールドの最大長は、成分セパレーターを含めて48文字である。送信システムは大文字と小文字の混合、またはすべて大文字を送ることができる。必要なら、受信システム側ですべて大文字に変換してもよい。
例： ￨SMITH^JOHN^J^III^DR^PHD￨
第1成分は姓について記す。
第2成分は洗礼名を表す。
第3成分は中間名のイニシャルあるいは名前を表す。
第4成分はサフィクス(名前接尾語)を指定するため使用される（例えばジュニアあるいは3世）。
第5成分はプレフィックス(名前接頭辞)を指定するため使用される（例えば、Dr.）。
第6成分は学位（例えば、Md.）を指定するため使用される。 推奨値については「使用者定義
テーブル 0360 - 学位」を参照すること。
国際化の注：一部の国々では、表意文字あるいは表音（音声の）文字セットを使用しているので、アルファベットフォーマットの他にこれらのフォーマットの片方または両方で名前を送信することが、ときどき必要である。異なる文字セット間を切り替えるには、JIS X0202−
ISO 2022のような文字セットを使用するが、これは異なる文字セット間および単一バイトとマ
ルチ・バイトの文字表現の間を切り替える。名前フィールドを繰り返す場合、名前の異なる反復はこれらの異なる文字セットによって表わされてもよい。詳細は以下のとおりである。
（さらにHL7節2.10.2、｢FT、STおよびXTデータ型のためのマルチ文字セットをサポートする
エスケープ｣を参照。）「HL7は、日本の文字のための下記基準をサポートする：
JIS X0201

Copyright©2002 JAHIS V2.0

対象ISO−IR13（日本の片仮名）

33

JHLDEX20.DOC 2002/06/26

対象ISO−IR14（日本のローマ字）JIS X0208

対象ISO−IR87（日本の漢字、平仮名および片仮名）

JIS X0212

対象ISO−IR159（補足的な日本の漢字）

HL7は欧州 の文字のための下記基準をサポートする：
ISO−8859（1−9）

対象ISO−IR100、101、109、110、144、127、126、138および148。

文字セッ トは、HL7の中でASCII、8859／1..8859／2、JAS2020およびJIS X0202として引用されている。DICOMは、形式「ISO−IRxxx」の、ISO 2375の中にレイアウトされたコードを使用する。HL7はこの命名法をサポートするが、それは相互操作性を促進するためである。
HL7は、ISO 646：1990（ISO IR−6）の国際参照バージョンの基本のG0セットを、文字列に対するデフォルト文字レパ−トリ−として使用する。これは単一のバイト文字セットであり、ASCIIと同一である。
PNあるいはXPNフィールドの各反復はデフォルト文字セットから始まると仮定される。別の文字セットを使用することになっている場合、HL7に定義されたエスケープであって文字セッ
トを宣言するため使用されるものが、反復の初めになければならない。また、HL7に定義されたエスケープであってデフォルト文字セットを始めるため使用されるものが、反復の終わりになければならない。さらに注意すべきことは、いくつかの文字セットを単一の反復内に混ぜ合わせてもよいが、反復がデフォルト文字セットへの復帰で終わることが条件であるということである。
アプリケーションは、その適合文およびフィールド・MSH-18文字セットの中でどの文字セッ
トをアプリケーションがサポートするか明示しなければならない。送信および受信アプリケーションは、をエスケープするために文字セット名（すなわちISO-IRxxx）をマップするか知っていると仮定されている。
例えば、多くの日本語のメッセージでは、ローマ字（すなわちローマ文字）、片仮名（外国の単語の発音表現）、平仮名（日本語の単語の発音表現）および漢字（絵文字）の混合がある。そのようなメッセージは、4つの文字セットがMSHの中で指定されることを要求する。
名前の国際化のための参考文献
1.
“Understanding Japanese Information Processing” by Ken Lunde, O’Reilly Press2.
“DICOM Supplement 9 : Multi-Byte Character Set Support”, ACR-NEMA
3.
ANSI X3.4:1986
ASCII character set
4.
ISO 646:1990
Information Processing - ISO 7-bit coded character set for
information interchange
5.
ISO/IEC 2022:1994
Information Technology - Character code structure and extension
techniques
6.
ISO 2375:1986
Data Processing - Procedure for the registration of escape sequences
7.
ISO 6429:1990
Information Processing - Control functions for 7-bit and 8-bit codedcharacter sets8.
ISO 8859 (1-9)
Information Processing - 8-bit single-byte coded graphic character
sets - parts 1-9
9.
ENV 41 503:1990
Information systems interconnection - European graphic character
repertoires and their coding
10.
ENV 41 508:1990
Information systems interconnection - East European graphic
character repertoires and their coding
11.
JIS X 0201-1976
Code for Information Exchange
12.
JIS X 0212-1990
Code of the supplementary Japanese Graphic Character set for
information interchange
13.
JIS X 0208-1990
Code for the Japanese Graphic Character set for informationinterchange
14.
RFC 1468
Japanese Character Encoding for Internet Messages
この方法はDICOMと整合している。

Copyright©2002 JAHIS V2.0

34

JHLDEX20.DOC 2002/06/26

DICOMによってサポートされた文字レパ−トリ−は、補遺9の第5部、節62E1の中で定義されている。それによれば、「テキストまたは文字列である値は、図形および制御文字から構成されることができる。図形文字セットは、そのコード化と無関係に、文字レパ−トリ−と呼ばれる。アプリケーションエンティティがDICOM規格を使用してデータを交換したい元来の文脈に依存して、異なる文字レパ−トリガー使用されている。DICOMによってサポートされた文字レパ−トリ−はISO 8859の中で定義されている。」
さらに、DICOMは、日本語のための次の文字レパ−トリ−をサポートする：
JIS X0201−1976−情報交換のためのコード
JIS X0208−1990−情報交換のための日本の図形文字セットのコード
JIS X0212−1990−情報交換のための補足の日本の図形文字セットのコード
SAD

street address 番地
Components: <street or mailing address (ST)> ^ <street name (ST)> ^ <dwelling number(ST)>
注意: XAD データタイプにだけ現われる。
第1成分は個人あるいは施設の道路あるいはメーリングアドレス。 施設を参照するとき、この最初のコンポーネントは施設名を指定するために使われる。 個人に関連して使われるとき、このコンポーネントはアドレスの最初の行を指定する。

TN 電話番号
米国とそれに準ずる国で使用する場合、電話番号は常に以下の形式で表す。
Format: [NN] [(999)]999-9999[X99999][B99999][C any text]
オプションの最初の2桁は国コードである。オプションのX部は内線番号である。オプションのB部は呼出番号コードである。オプションのC部は、After 6:00などのようにコメントとして使うことができる。テキスト・フィールドにはなんの制限もないが、10文字を越える
値は受信システムにより切り捨てられることがある。施設の電話システムが変わることを想定して、内線番号と呼出番号の長さは、ローカルの取り決めにより拡張することができる。
例 |(415)925-0121X305||234-4532CWEEKENDS|
XAD

拡張住所
Components: <street address町名 (SAD)> ^ <other designation他の表示 (ST)> ^ <city都市(ST)> ^ <state or province州あるいはプロビンス (ST)> ^ <zip or postal code ZIPあるいは郵便番号(ST)> ^ <country国 (ID)> ^ < address type (ID)> ^ <other geographic designation他の地理的な表示 (ST)> ^ <county/parish code郡/教区コード (IS)> ^ <census tract国勢調査標準地域(IS)>^ <address representation code住所表示コード (ID)> ^ <address validity range 住所有効範囲(DR)>
例： |1234、Easy St.＾Ste. 123＾San Francisco＾CA＾95123＾USA＾B＾＾SF＾|
他の表示では町名を修飾する。例：Suite 555あるいは4階など。 住所・タイプはオプションであり、HL7テーブル0190−アドレスタイプによって定義される。 他の地理的な表示は国、バイオリージョン、SMSAなどを含んでいる。 Name/address representation codeはHL7
テーブル0465の値を使用。

XPN

拡張人名
Components: <family name姓 (FN)> ^ <given name 洗礼名 (ST)> ^ < second and further
given names or initials thereof 中間名のイニシャルあるいは名前 (ST)> ^ <suffix (e.g., JR or III)
接尾辞 (ST)> ^ <prefix (e.g., DR) 接頭辞 (ST)> ^ <degree (e.g., MD) 学位 (ST)> ^ <name type
code名前タイプコード (ID) > ^ <name representation code名前表示コード (ID)> ^ <nameCopyright©2002 JAHIS V2.0

35

JHLDEX20.DOC 2002/06/26

context名前コンテキスト (CE)> ^ <name validity range 名前有効範囲(DR)> ^ <name assemblyorder 名前の組み立て指示(ID)>
例： |Smith^John^J^III^DR^PHD^L||日本^太郎^^^^^D^I~にほん^たろう^^^^^D^P~ NIHON^Tarou^^^^^D^A|
上にリストしたように、名前は複数のフリーテキスト成分から成る。 送信システムは大文
字と小文字の混合、またはすべて大文字を送ることができる。 必要なら、受信システム側
ですべて大文字に変換してもよい。 名前タイプコードで法律上の名前や現地名などを示す。
取りうる値はHL7テーブル0200 - 名前タイプを参照。 一般的に法的な名前は現在の既婚の名前と同じである。
テーブル 0200 - Name type 名前タイプ
Value
A
B
C
D
I
L
M
N
P
R
S
T
U

Description
Alias Name 別名
Name at Birth 出生時の名前
Adopted Name 養子名
Display Name 表示名称
Licensing Name 許可された名前
Legal Name 法律名前
Maiden Name 旧姓
Nickname /”Call me” Name/Street Name
Name of Partner/Spouse (retained for backward compatibility only)
Registered Name (animals only) 動物の登録名
Coded Pseudo-Name to ensure anonymity
匿名性を確保するためのコード化された偽名
Indigenous/Tribal/Community Name 現地での/部族での/社会での名前
Unspecified 不明

学位は使用者定義テーブル0360の値を使用。
使用者定義テーブル 0360 - 学位
Value
AAS
AA
ABA
AE
AS
BA
BBA
BE
BFA
BN
BS
BSL
BT
CER
DIP
DBA
DED
PharmD
PHE
PHD
PHS
MD
DO
HS
JD
MA
MBA
MCE
MDI
MED
MEE

Copyright©2002 JAHIS V2.0

Description
Associate of Applied Science 応用科学系準学士
Associate of Arts 文系準学士
Associate of Business Administration 経営管理学準学士
Associate of Engineering エンジニアリング準学士
Associate of Science 理系準学士
Bachelor of Arts 文学士
Bachelor of Business Administration 経営管理学士
Bachelor of Engineering エンジニアリング士
Bachelor of Fine Arts 美術士
Bachelor of Nursing 看護士
Bachelor of Science 理学士
Bachelor of Science – Law 理学士−法則
Bachelor of Theology 神学士
Certificate 証明書
Diploma 卒業証書
Doctor of Business Administration 経営管理学博士
Doctor of Education 教育博士
Doctor of Pharmacy 薬学の医者
Doctor of Engineering エンジニアリング博士
Doctor of Philosophy 哲学博士
Doctor of Science 科学博士
Doctor of Medicine 医学博士
Doctor of Osteopathy 骨学博士
High School Graduate 高校卒業者
Juris Doctor 法学博士
Master of Arts 文学修士
Master of Business Administration 経営学修士
Master of Civil Engineering 土木工学修士
Master of Divinity 神学修士
Master of Education 教育修士
Master of Electrical Engineering 電気工学修士

36

JHLDEX20.DOC 2002/06/26

Master of Engineering エンジニアリング修士
Master of Fine Arts
美術学修士
Master of Mechanical Engineering 機械工学修士
Master of Science 理学修士
Master of Science – Law 理学修士−法則
Master of Theology 神学のマスター
Non-Graduate 非卒業生
Secretarial Certificate
Trade School Graduate 専門学校卒業生

ME
MFA
MME
MS
MSL
MT
NG
SEC
TS

名前表示コードでは、データ項目によって提供される名前の表現を指示する。この成分は受信者にヒントを提供する。 それにより、なにが送られており、なにを表示できるかに関する選択を行うことができる。
テーブル0465 - Name representation 名前表示コード
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,仮名)XON 拡張複合組織IDと名称
Components: <organization name組織名 (ST)> ^ <organization name type code組織の名前タイプ (IS)> ^ <ID number ID番号 (NM)> ^ <check digitチェックデジット (NM)> ^ <code
identifying the check digit scheme employedチェックデジット方式 (ID)> ^ <assigning authority
割当て権限者 (HD)> ^ <identifier type code識別子タイプ (IS)> ^ <assigning facility ID 割当て施設ID (HD)> ^ <name representation code 名前表示コード(ID)>
例：|HL7 Health Center＾L＾6＾M11＾HCFA|
組織の名前タイプでは、法的な名前、表示する名前などを表わす。
使用者定義テーブル0204−組織の名前タイプ
Value
A
L
D
SL

XTN

Description
別名
法的な名前
表示する名前
株式取引所に登録する名前

拡張電話番号
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)> ^ <anytext (ST)>
例： (415) 555-3210＾ORN＾FX＾
テーブル0201−通信使用コード
Value
PRN
ORN
WPN
VHN
ASN
EMR
NET
BPN

Description
主要な自宅番号
他の自宅番号
勤務先番号
別荘番号
留守電話応答サービス番号
緊急番号
ネットワーク(電子メール)アドレス
ポケットベルの番号

テーブル0202−遠隔通信機器タイプ
Value
PH
FX
MD
CP

Copyright©2002 JAHIS V2.0

Description
電話
ファックス
モデム
携帯電話

37

JHLDEX20.DOC 2002/06/26

ValueBP
INTERNET
X.400

Description
ポケットベル
インターネットアドレス：通信使用コードがNETである場合のみ使用
X.400電子メールアドレス：通信使用コードがNETである場合のみ使用

注：成分5〜9は、定形の形式で第1の成分の基本機能を反復する。そしてローカルおよび世界の電話番号の両方が表現できる。電話番号のための形式は、定形形式を使用することを推奨し、第1の成分は下位互換性のために残される。
CD チャネル定義
Components: <channel identifier (CM)> ^ <waveform source (CM)> ^ <channel
sensitivity/units (CM)> ^ <channel calibration parameters (CM)> ^ <sampling frequency (NM)> ^<minimum/maximum data values (CM)>ディジタル波形データを標識付けするために、このデータ型を使用する。
MA 多重化された配列
Components: <sample 1 from channel 1 (NM)> ^ <sample 1 from channel 2 (NM)> ^ <sample 1
from channel 3 (NM)> ... ~ <sample 2 from channel 1 (NM)> ^ <sample 2 from channel 2 (NM)> ^<sample 2 from channel 3 (NM)> … ~このデータ型はチャンネルマルチプレックスの波形データ(例えばアナログディジタル変換器または他のデジタル信号源からのデジタル化された値)を表現する。
NA 数値の配列
このデータ型は一連(配列)の数値を表わすために使用され、各々はNMデータ型をである。
ED

カプセル化データ
Components: <source application (HD) > ^ <type of data (ID)> ^ <data subtype (ID)> ^<encoding (ID)> ^ <data (ST)>
このデータ型は、カプセル化されたデータをソース・システムから目的地システムへ送信する。それは、ソース・システムの識別、データのタイプ、データのコーディング方式およびデータ自身を含んでいる。このデータ型は、RP−参照ポインタデータ型に似ているが、このデータ型は一方のシステム上のデータを指すべき代わりに、そのシステムへ送られるべきデータを含んでいる。
ソースアプリケーションはデータのソースであったシステムを識別する一意的な名前である。
データのタイプならびにサブタイプはテーブル0191−参照されるデータのタイプ、HL7テ
ーブル0291−参照されるデータのサブタイプを参照。
コーディング方式は、それが存在する場合、表示可能なASCII文字として二進法データの連
続のオクテットを常に表わす。とりうる値はHL7テーブル0299−コーディング方式を参照。
テーブル0299−コーディング方式
Value
A
Hex
Base64

Description
コーディングはない。データは表示可能なASCII文字である。
16進法のコーディング。連続するペアの16進数字は連続する単一オクテットを表わす。
MIME(多目的インターネットメール拡張)標準のRFC1521によって定義されるコーディング。4つの連続するASCII文字が、二進法データの連続する3つのオクテットを表わす。Base64は、米国ASCIIの65文字サブセットを利用し、これを構成するのは大文字および小文字の英字、数字｢0｣から｢9｣まで、｢+｣、｢/｣および｢=｣である。

MIMEインターネット標準のRFC1521により、Base64を以下のように定義する。24ビットの入力グループ(3つのオクテット)を横切って左から右に進むので、各6ビットのグループは印刷可能な64文字の配列としてを使用する。指標によって参照された文字が、コード化された文字列に置かれる。これらの文字は、HL7テーブル0290−MIME base64コード化文字に示され、普遍的に表現可能なように選択される。
24ビット未満がデータの終わりで入力グループにおいて利用可能な場合、特別の処理を実行する。十分なコーディング量はデータの終わりで常に完成される。24入力ビット未満が入力
グループにおいて利用可能な場合、6ビット・グループの整数を形成するために、右側にゼロビットを付け加える。
入力データのない出力フィールド文字は文字｢=｣に設定される。コード化された出力はすべ

Copyright©2002 JAHIS V2.0

38

JHLDEX20.DOC 2002/06/26

てオクテットの整数であるので、次の場合だけが発生する：(1)入力の最終量は24ビットの不可欠な倍数である；ここで、コード化された出力の最終単
位は｢=｣のパディングなしの4文字の不可欠な倍数になる、(2)入力の最終量はちょうど8ビットである；ここで、コード化された出力の最終単位は2つの｢=｣パッド文字が後続する2文字になる。あるいは、(3)入力の最終量はちょうど16ビットである；ここで、コード化された出力の最終単位は1つの｢=｣パッド文字が後続する3文字になる。
テーブル 0290 - MIME base64 コード化文字
Value/Code
0
A
1
B
2
C
3
D
4
E
5
F
6
G
7
H
8
I
9
J
10 K
11 L
12 M
13 N
14 O
15 P
16 Q

Value/Code
17 R
18 S
19 T
20 U
21 V
22 W
23 X
24 Y
25 Z
26 a
27 b
28 c
29 d
30 e
31 f
32 g
33 h

Value/Code
34 I
35 j
36 k
37 l
38 m
39 n
40 o
41 p
42 q
43 r
44 s
45 t
46 u
47 v
48 w
49 x
50 y

Value/Code
51 z
52 0
53 1
54 2
55 3
56 4
57 5
58 6
59 7
60 8
61 9
62 +
63 /
(pad) =

コード化されたオクテットが、なんらかのコーディング方法によって解釈され、それが暗黙のものかまたは表わされたデータ型で指定されるものを超えるとき(例えば目的地アプリ
ケーション上の、16ビットあるいは32ビット・二進法の語の中のそれらのオーダリング)、
それは目的地アプリケーションによって決定され、この規格の範囲外である。
ソースアプリケーションから目的地アプリケーションまで送信されるべきデータを構成する表示可能なASCII文字。もしコード化された二進数であれば、セクション2.8.14.2｢データのタイプ｣によってコード化される。
CP − composite price 複合価格
Components: <price 価格(MO)> ^ <price type価格タイプ (ID)> ^ <from value 始点の値(NM)> ^ <tovalue 終点の値(NM)> ^ <range units範囲単位(CE)> ^ <range type 範囲タイプ(ID)>
Subcomponents of price: <quantity (NM)> & <denomination (ID)>

注意：このデータタイプは、与えられたセグメント内の反復フィールドを定義するために頻繁に使用される。
例： |100.00&USD^UP^0^9^min^P~50.00&USD^UP^10^59^min^P~10.00&USD^UP^60^999^P~50.00&USD^AP~
200.00&USD^PF~80.00&USD^DC|

第1成分は唯一必須成分；小数点を通常含んでいる。MO・データタイプの各成分がここでは副成分であることに注意すること。
第2成分はコード化された値、データタイプID。有効な値については、「HL7テーブル0205−
価格タイプ」を参照すること。
テーブル0205−価格タイプ
Value
AP
DC
IC
PF
TF
TP
UP

Description
administrative price or handling fee
管理上の価格あるいは取り扱い料金
direct unit cost
直接の単位原価
indirect unit cost
間接の単位原価
professional fee for performing provider
実行提供者に対する専門の料金
technology fee for use of equipment
機器の使用に対する技術料金
total price
価格の合計
unit price, may be based on length of procedure or service 単価、手続きまたはサービスの長さに基づいてもよい。

各々はNM・データタイプである；一緒になって「範囲」を指定する。範囲を時間あるいは量のいずれかとして定義することができる。例えば、範囲は、手続きの最初の10分が1つの価格を持つことを示すことができる。データタイプの別の反復は、別の価格で手続きの次の10〜60

Copyright©2002 JAHIS V2.0

39

JHLDEX20.DOC 2002/06/26

分の料金を課すことを明示するために、範囲を使用することができる；手続きの最後の反復は60分からN分までを第3の値に指定することができる。
もし<価格タイプ>成分がTPである場合、両方<始点の値>および<終点の値>の両方がヌル（null）であることに注意すること。
第3成分は上記の始点の値を参照すること。
第4成分は上記の始点の値を参照すること。
第5成分はコード化された値、データタイプCE。時あるいは量のいずれかの単位の標準のテーブルによって定義されたもの。（例えば、HL7-節7.1.4「コード体系」のテーブルを参照する
こと）。これは、範囲、例えば秒、分、時間、日、量（例えばカウント）に関連した単位について記述する；それは、<始点の値>および<終点の値>が存在するとき、必要とされる。
Subcomponents of range units: <identifier (ST)> & <text (ST)> & <name of coding system (IS)>& <alternate identifier (ST)> & <alternate text (ST)> & <name of alternate coding sys‑tem(IS)>

第6成分は有効な値については、「HL7テーブル0298−CP範囲タイプ」を参照すること。
テーブル0298−CP範囲タイプ
Value
P

Description
Pro-rate. Apply this price to this interval, pro-rated by whatever portion of
the interval has occurred/been consumed
比例配分。この間隔にこの価格を適用する。発生／消費した間隔の部分によって比例配分される。
Flat-rate. Apply the entire price to this interval, do not pro-rate the price if
the full interval has not occurred/been consumed
定額。この間隔に価格全体を適用する。価格全体が発生／消費しない場合価格の比例配分をしない。

F

FC −

financial class 会計クラス
Components:<financial class会計のクラス (IS)> ^ <effective date発効期日 (TS)>

この成分は、人に割り当てられた会計のクラスを含んでいる。
推奨値については「使用者定義テーブル0064−会計クラス」を参照すること。
使用者定義テーブル0064−会計クラス
Value

Description
No suggested values defined

推奨できる値はない

この成分は、第1の成分中で指定された会計のクラスへの、人の割当の発効期日／時間を含ん
でいる。
QSC −

query selection criteria 問い合わせセレクト条件
Components: <segment field name セグメントフィールド名 (ST)> ^ <relational operator 比較演
算子 (ID)> ^ <value 値 (ST)> ^ <relational.conjunction 比較論理積 (ID)>例:|@PID.5.1^EQ^EVANS|

定義：このフィールドは、問合せ応答で返されるべき行に資格を与える条件を示す。
（このフィールドは問合せの対応するSQL表現中の「WHERE」句と同じ情報を伝えるが、フォーマットのされ方は異なっている。）
第1成分は修飾語として参加しているフィールドの名前（通常「キー」）。フィールドに名前を付ける方法については、データタイプQIPの第1成分の「セグメントフィールド名(ST)」を参照すること。
第2成分:有効な値については「HL7テーブル0209−比較演算子」を参照すること。
テーブル0209−比較演算子
Relational operator
EQ
NE
LT
GT
LE
GE
CT

Copyright©2002 JAHIS V2.0

Value
Equal
等しい
Not Equal
等しくない
Less thanより小さいGreater thanより大きい
Less than or equal
以下Greater than or equal 以上
Contains
含む

40

JHLDEX20.DOC 2002/06/26

Relational operator
GN

Value
Generic

一般

第3成分はフィールドがそれに対して比較される値。
第4成分は「HL7テーブル0210−比較論理積」を参照すること。 比較論理積は以下のように定義される：資格を得る行を選択するために複数の比較がされる場合、結合子はこれらの比較文を連結する。
テーブル0210−比較論理積
Relational conjunction
AND
OR

Note
Default

・文字列に適用されたとき、関係オペレータLT、GT、LEおよびGEはアルファベットの比較を意味する。
・「総括的な」比較は、指定された文字列の初めが選択文字列と一致するレコードを選び応答に含める。
・反復フィールドがオペランドとして指定される場合、そのいずれかのフィールド条件が一致すれば、応答メッセージ中に含めるための行に資格を与える。
・ANDはORに優先する。より高度で複雑な条件は、埋め込みの問合せ言語メッセージあるいはストアプロシジャ問合せメッセージとして問合せが表現されることを要求する。
QIP −query input parameter list 問い合わせ入力パラメータリスト
Components: <segment field name セグメントフィールド名(ST) > ^ <value1 (ST) & value2 (ST) &value3 値1&値2&値3 (ST) ... >例:|@PID.5.1^EVANS|

定義：このフィールドは、ストアードプロシジャーへ渡されるパラメタである名前と値の一覧表を含んでいる。
第1成分はセグメントフィールド名を含んでいる。
フィールド名の命名ルール：フィールドのためのHL7セグメントIDと連結された「@」記号によって、フィールドが指定される。フィールドが成分に分割される場合、名前の後に「.nn」
を付けてもよいが、これは特定の成分を識別するためである（「.3」のサフィクスはフィールドの第3の成分を示す）；そうでなければ、全体のフィールドが仮定される。 フィールドがさらに副成分に分割される場合、名前の後に「.nn.mm」を付けるが、それは相対的な位置によって要求された成分および副成分を識別するためである。
施設特定のフィールドを使用してもよいが、それらが文字「Z」から始まることが条件である。
この場合、既存のHL7セグメントIDとセグメント番号に矛盾しない施設特定のセグメントIDとセグ
メント番号が定義されねばならない。
このフィールドに対する値は、この仕様の機能特定の章に定義されている。
注：「@」が、「MSH−2コード化文字」の中で定義された区切記号文字のうちの1つとして使用されている場合、それはエスケープされねばならない。（HL7-節2.10.1「フォーマットコ
ード」を参照）
第2成分はフィールド値を含んでいるか、あるいは「値1&値2&値3...」の形式の値を含んでいる。
単一値パラメータは、第2の成分に単一の副成分だけを含んでいる：したがって副成分の区切記号は必要ではない（例えば<フィールド名>＾<値>）。値の単純な一覧表（すなわち一次元の配列）を、単一値の代わりに渡してもよいが、各値は区切記号で分離する：「<フィールド名>＾<値1&値2&...>」RCD − row column definition 行・列定義
Components: <segment field name HL7セグメントフィールド名(ST)> ^ <HL7 data type HLデー
タタイプ (ID)> ^ <maximum column width 最大コラム幅(NM)>

例：PID-5の「姓」コンポーネントの値を含んでいる。データが最大幅の20桁|@PID.5.1^ST^20|

Copyright©2002 JAHIS V2.0

41

JHLDEX20.DOC 2002/06/26

定義：このフィールドの各反復は3つの成分から成る：
第１成分はHL7セグメントフィールド名であって、これはコラムを占めるフィールドを識別す
る（セグメントフィールド名の付け方については、（データタイプQIP−第1成分を参照）。
第2成分は３文字のHL7データタイプ。HL7テーブル0440に従う有効な値のためのデータ型。
第3成分は最大コラム幅であって、返信システムによって決まるもの（これはHL7定義の最大フィールド長さと異なるかもしれない）。
DLN− driver’s licence number 運転免許証番号
Components: <license number (ST)> ^ <issuing srate,province, country (IS)> ^ <expiration date(DT)>
運転免許証番号、発行地、有効期限を表す。

JCC −job code/class 職種コード／種類
Components: <job code (IS)> ^ <job class (IS)>
職種と雇用種別を表す。

VH− visiting hours

来院時間

Components: <start day range開始曜日 (ID)> ^ <end day range 終了曜日 (ID)> ^ <start hour range
開始時刻 (TM)> ^ <end hour range終了時刻 (TM)>

定義：このデータタイプは患者の居場所に来院できる時間を含んでいる。 最初の2つの成分に対する有効な値については、「HL7テーブル0267−曜日」を参照すること。
第1成分は来院時間範囲の開始の曜日。値については、「HL7テーブル0267−曜日」を参照すること。
第2成分は来院時間範囲の最後の曜日。来院時間範囲の開始の曜日。 値については、「HL7
テーブル0267−曜日」を参照すること。
テーブル0267−曜日
Value
SAT
SUN
MON
TUE
WED
THU
FRI

Description
Saturday
土曜日
Sunday日曜日
Monday月曜日
Tuesday
火曜日
Wednesday 水曜日
Thursday
木曜日
Friday金曜日

第3成分は来院時間範囲の最初の曜日の開始時間（第1の成分の「開始曜日」を参照）。
第4成分は来院時間範囲の最後の曜日の終了時間（第2の成分の「終了曜日」を参照）。
PPN− 実行者およびタイムスタンプ
Components: <ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^ <second and further given
name or initials thereof (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)> ^ <identifier check digit(ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigningfacility (HD)> ^ < date/time action performed (TS)> ^ <name representation code (ID)> ^ <name context (CE)>^ <name validity range (DR)> ^ <name assembly order (ID)>

このデータ型はTSデータ型につながれたXCNデータ型と等価なものであり、誰がいつアクションを実行したかを記録するために使用する。ヌルでない場合、実行者およびタイムス
タンプの両方の値が設定されねばならない。
DR 日付／時間の範囲
Components:
刻(TS)><range start date/time 開始日付／時刻(TS)> ^ <range end date/time 終了日付／時YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/‑ZZZZ] ＆ < 精度 >第１成分は指定された範囲内での最も早い日付／時間（時刻スタンプ）を含んでいる。
第2成分は指定された範囲内での最新の日付／時間を含んでいる。
TS（時刻スタンプ）データタイプによって精度の指定ができることに注意すること。

Copyright©2002 JAHIS V2.0

42

JHLDEX20.DOC 2002/06/26

RI 繰り返し間隔
Components:(ST)><repeat pattern 繰り返しパターン(IS)> ^ <explicit time interval明確な時間間隔

定義：このフィールドは、繰り返す予約の間隔を含んでいる。デフォルト設定は、成分の値がない場合、予約がただ一度のみ生じることを示す。 このフィールドの定義は、HL7 4章の節
4.4.2「時間間隔成分（CM）」の中で与えられた量／タイミング・フィールドの間隔成分の定義と等価である。
第１成分は使用者定義テーブル0335-繰り返しパターン − によって定義される。
それ以上の詳細については、5.5節内「Repeat pattern繰り返しパターン」を参照。
第2成分は第1の副成分中でコードによって参照される実時間を明示的に列挙し、そのフォー
マットはHHMM、HHMM、HHMM、....である。実際の管理時間が組織内で変わる場合、第2の副成分が第1の副成分を明確にするために使用される。詳細は、5.5節内「 Explicit time interval
subcomponent明確な時間間隔の副成分」を参照すること。
SCV scheduling class value pair 予約クラスと値
Components:<parameter class パラメータクラス(IS)> ^ <parameter value パラメタ値(ST)>HL7予約の章に関してのみ使用される。
定義：このフィールドが使用されるのは、パラメタと優先権を実施者（予約管理）アプリケ
ーションに伝えるためであり、内容は適切な時間予約枠、資源、場所あるいは実施者（予約管理）上書き基準を選択して予約することである。
第１成分は実施者（予約管理）アプリケーションに渡されつつあるパラメタあるいは優先権を識別するコードである。 推奨値については「使用者定義テーブル0294‑時間選択基準パラ
メータ・クラス・コード」を参照のこと。
使用者定義テーブル0294−時間選択基準パラメーター・クラス・コード
Parameter
好ましい開始
好ましい終了
月曜

Class Description: Valid Values
予約要求、サービスあるいは資源のための好ましい開始時間。24時間時計表記法を使用するフォーマットHHMMの中の任意の法的な時間仕様
予約要求、サービスあるいは資源のための好ましい終了期間。24時間時計表記法を使用するフォーマットHHMMの中の任意の法的な時間仕様
月曜が予約するのに好ましい日かそうでないかを示すもの。OK=好ましい予約日、NO=この曜日は好ましくない。

火曜

火曜が予約するのに好ましい日かそうでないかを示すもの。OK=
好ましい予約日、NO=この曜日は好ましくない。

水曜

水曜が予約するのに好ましい日かそうでないかを示すもの。OK=好ましい予約日、NO=この曜日は好ましくない。
木曜が予約するのに好ましい日かそうでないかを示すもの。OK=好ましい予約日、NO=この曜日は好ましくない。
金曜が予約するのに好ましい日かそうでないかを示すもの。OK=好ましい予約日、NO=この曜日は好ましくない。
土曜が予約するのに好ましい日かそうでないかを示すもの。OK=好ましい予約日、NO=この曜日は好ましくない。
日曜が予約するのに好ましい日かそうでないかを示すもの。OK=好ましい予約日、NO=この曜日は好ましくない。

木曜
金曜i
土曜
日曜

第2成分はそのパラメタに対する実際のデータ値である。
例えば、実施者（予約管理）アプリケーションが優先権パラメタが渡され、好ましい開始
時間、好ましい終了期間、および週の好ましい日を指定して予約することを可能にする場
合、それは次のパラメタ・クラス・コードおよび有効なデータセットを定義する。
TQ

タイミング数量サービスの実施時期とその頻度を指定する。 「5.5 QUANTITY/TIMING (TQ) DEFINITION
数量/タイミング定義」を参照のこと。

Copyright©2002 JAHIS V2.0

43

JHLDEX20.DOC 2002/06/26

5.5 QUANTITY/TIMING (TQ) DEFINITION

数量/タイミング定義

Components: <quantity数量 (CQ)> ^ <interval時間間隔 (CM)> ^ <duration継続時間 (ST)> ^<start date/time開始日時 (TS)> ^ <end date/time終了日時 (TS)> ^ <priority優先度 (ST)> ^<condition条件 (ST)> ^ <textテキスト (TX)> ^ <conjunction連結 (ID)> ^ <order sequencingオーダーシーケンス化(CM)> ^ <occurrence duration発生持続(CE)> ^ <total occurrences発生からの合計 (NM)>
定義： 数量/タイミング(ORC-7,OBR-27)は、オーダーセグメントによって述べられたサー
ビスがいつ，どのような頻度で行なわれるかを規定する手段を与える。それは、繰り返しを持つことができる複合多重成分フィールドである。すなわち複数回の数量/タイミング指定が、反復区切文字で分離されて表現される。数量/タイミング指定の成分を、以下に述べる。
Quantity component 数量成分 (CQ)
Subcomponents：<数量>&<単位>

定義： 各々のサービス間隔で供給される必要があるサービスの量。たとえば2つの血液培
養が4時間毎に得られるとすれば、数量が2である。もし3ユニットの血液が血液型を調べク
ロスマッチされるならば、数量は3である。デフォルト値は1である。単位が要求される時、後ろの成分で限定するものによって明示され加えられる。
Interval component 時間間隔成分 (CM)
Subcomponents：<繰り返しパターン>&<明確な時間間隔>

定義：繰り返されるサービスの時間間隔を決める。デフォルトは1回のみである。第1副成分は繰り返しパターンである。第2副成分はパターンが実行される明確な時間である。
Repeat pattern繰り返しパターン
使用者定義テーブル 0335- Repeat pattern 繰り返しパターン
Every <integer> seconds 秒毎
Every <integer> minutes 分毎
Every <integer> hours 時間毎
Every <integer> days
日毎
Every <integer> weeks 週毎
Every <integer> months (Lunar cycle) 月毎
特定の曜日に繰り返す。Jはフランス語のjour(day)から。もし<整数>がないならば、繰
り返しレートは1と仮定する。日付の番号は、1=月曜日から7=日曜日までカウントする。それゆえQ2J2は第2火曜日毎、Q1J6は、土曜日毎を意味する。
BID
1日2回、施設が決めた時刻(たとえば、9AM-4PM)
TID
1日3回、施設が決めた時刻(たとえば、9AM-4PM-9PM)
QID
1日4回、施設が決めた時刻(たとえば、9AM-11AM-4PM-9PM)
XID
1日“x” 回、施設が決めた時刻、Xは数字5より大。(例えば5ID=一日5回、8ID=一日8回)
注：上記の4つの指定はいずれもそのQ<整数>H対応と同等ではない。たとえばQIDは、Q6Hではない。前者は不等間隔に置かれる；後者は等間隔に置かれる。
QAM
朝に、施設が決めた時刻に。
QSHIFT
3回の8時間シフトの各々の間で、施設が決めた時刻に。
QOD
隔日(Q2Dと同じ)
QHS
毎日就寝前に。
QPM
夕方、施設が決めた時刻に。
C
サービスの提供は連続的に初めの時刻から終わりの時刻まで
U <spec>スペック) 将来使用のため。<スペック>がUNIXのクローンで定義された時間隔仕様で
ある場合。
PRN
必要に応じて与えられる。
PRNxxx
xxxがなんらかの頻度コード(たとえば、(PRNQ6H))；必要に応じて頻度期間にわたって与えられる。
Once
一度だけ。これは、この成分がnullである時、デフォルトである。
<timing>C (“cum”)<meal>
食事に関連したタイミング
A
Ante (before) 前P
Post (after) 後
I
Inter 間（例、食間）M
Cibus Matutinus (breakfast) 朝食
D
Cibus Diurnus (lunch) 昼食
VCibus Vespertinus (dinner) 夕食
例：朝食前一回ACM、夕食後一回PCV
Q<integer>SQ<integer>MQ<integer>HQ<integer>DQ<integer>W
Q<integer>LQ<integer>J<day#>Copyright©2002 JAHIS V2.0

44

JHLDEX20.DOC 2002/06/26

Explicit time interval subcomponent明確な時間間隔の副成分
定義： 次の書式において、第1副成分のコードによって参照された実際の時刻を明確にリストする：HHMM,HHMM,HHMM,...。この第2副成分は、実際の投薬時刻が施設内で変化する場合等、第1副成分を明らかにするために使用される。オーダーの期間が1日を超えるな
らば、この新しい副成分が実際に役立つのは次の場合に限る。すなわち同じ投薬時刻がオーダーの各々の日に対して発生する場合である。オーダーの実際の開始時刻(数量/タイミン
グフィールドの第4副成分によって与えられる)が、リストの最初の明確な時刻の後である
ならば、最初の投薬は、開始時刻の後の最初の明確な時刻とする。患者が明確な時間の異なったセットを持っている場所へ移動する場合、現在のオーダーは、変更された明確な時間を示している新しい数量/タイミングフィールドで更新される。
時刻は hhmm、就寝時は HS、食事に関係したタイミングは xCy で記述される。
x：A 前、P 後、I 間、 y：M 朝食、D 昼食、V 夕食
Ex: 数量/タイミングフィールドの第2成分：...^QID&0230,0830,1430,2030^...
1日3回食後 ^TID&PC
Duration component継続時間成分 (ST)
定義： サービスが開始された後で、サービスがどのくらい長く続くかを示す。デフォルト
は、INDEF(不定)である。この成分は、以下の通りにコード化される：
S<integer>
M<integer>
H<integer>
D<integer>
W<integer>
L<integer>
X<integer>

=
=
=
=
=
=
=

T<integer>

=

INDEF

=

<integer> seconds 秒<integer> minutes 分<integer> hours 時間<integer> days 日<integer> weeks 週<integer> months 月
オーダーで指定された時間間隔成分の繰り返し回数。2つの血液培養に対する要求
Q2H X3、2つの血液培養を3つの異なった時刻に2時間おきに入手して合計6つの血液培養を入手するという意味である。
明記されている時間間隔と量で、合計の<整数>『DOSAGE』が蓄積されるまで。単位は、｢数量｣フィールドにおけると同じであると仮定される。
期間を特に定めない(不定)-同様にデフォルト

Start date/time component 開始日時成分 (TS)
定義：依頼者によって規定される。その場合それはサービスを開始する必要がある最も初めの日時を示す。多くの場合、しかしながら、開始日時は、オーダーレコード(たとえば、(緊急)-STAT)の他のフィールドによって示唆されるか、あるいは定義される。そのような場合、このフィールドは空となる。
実施者サービスは、オーダーを受領後このフィールドの値をしばしば記録する。一方実施
サービスの内部使用のために、開始日時を基礎にして終了時刻を計算する。
End date/time component 終了日時成分 (TS)
定義：サービスを要求する人によってこの値が指定された時は、このフィールドはサービスが行なわれるべき最後日時である必要がある。ここで明示された時間までに行なわれな
かったならば、それは行うべきではない。要求する人がこの値を満たすとは限らない。しかし実施者サービスは、それが受け取る指示および実際の開始時間を基礎として、満たしてもよい。
終了日時の値に関係なく、サービスは、継続時間または終了日時によって指定された最も早い日時に終了すべきである。
Priority component 優先度成分 (ST)
定義： 要求の緊急度を述べる。次の値が提案される(優先度のデフォルトはRである)：
S
A
R
P
C
T
PRN

Copyright©2002 JAHIS V2.0

緊急できるだけ早く
ルーチン
術前
返信
タイミングがクリティカル= As Needed

=
=
=
=
=
=

最も高い優先度でSオーダーの後
デフォルト

要求は、要求された時間に最も近いことが重要であるという意味である。
たとえば、抗生物質血中濃度である

45

JHLDEX20.DOC 2002/06/26

値『T』(タイミングクリティカル)の程度は次のように明示できる：
Format:TS<integer>
TM<integer>
TH<integer>
TD<integer>
TW<integer>
TL<integer>

=
=
=
=
=
=

秒以内で
分以内で
時間以内で
日以内で
週以内で
月以内で

オーダーの連続指定の場合、これらの値は、先行オーダーから後に続くオーダー全部に対してタイミングの重要性を規定する。優先度成分を反復する場合はスペースで区切る。
Condition component 条件成分 (ST)
定義： これは、投薬条件を記述するフリー・テキストフィールドである。たとえば、｢PRNpain｣、｢血圧を110以下に保て｣など。このフィールドにテキストが存在する場合、投薬方法
または投薬時期(あるいはその両方)を決定するため人間が見直す必要がある。
Text component テキスト成分 (TX)
定義： 指示(オプショナル)の完全なテキストバージョン。
Conjunction component 連結成分 (ID)
定義： この成分がnullでなければ、反復区切り文字を使用して、2番目のタイミング指定を後に続ける。このフィールドは3つの値を採ることができる：
a) S = Synchronous 同期
今回の指定の後に次の指定を行う(ORC−4＾4−開始日時、およびORC−4＾5−終了日時成分により制限を受けなければ)。
S 指定は、最初のタイミング・シーケンスの後に2番目のタイミング・シーケンスが続くことを示す。たとえば、最初の1時間はQ15分ごとに血圧を測定し、次の日には2時間ごとに血圧を測定するよう依頼する。
b) A = Asynchronous 非同期
今回の指定と並行して次の指定を行う(ORC−4＾4−開始日時、およびORC−4＾5−終了日
時成分により制限を受けなければ)。連結 A により、投薬時などに散見される、2つの指
示の並行指定が可能になる。たとえば、月曜、水曜、金曜にプレドニゾン1錠、火曜、木曜、
土曜、日曜には1/2錠。
c) C = This is an actuation timeこれは開始時間である
このコードの後にはサービスの終了時間が続く。このコードにより、サービスを起動すべ
き(採血など)時間・優先度から、サービスを終了すべき(結果報告など)時間・優先度が区別できるようになる。
連続サービスあるいは循環サービスの場合、サービスを実際に停止するポイントは、成分
ORC−4＾5−終了日時またはORC−4＾3−継続時間の、どちらかより早い停止時間を示す
成分により決定される。通常、この2つの成分のうち1つだけが存在する。しかし以下のよ
うな指定によりEKGを要求した場合は、反復数(3)のほうがより早い停止時間を定義しているので、EKGは3日間だけ実施されることになる。
^1^QAM^X3^D10

Order sequencing component オーダーシーケンス化成分 (CM)
定義： 実際の現場ではさまざまな状態が想定される。たとえば、あるまとまった点滴(IV)
溶剤を要求するオーダーを作成した場合は、個々の点滴溶剤(各々それ自体が1個のオーダー)のシーケンスを指定する必要がある。
また、 PRN pain などある種の結果条件がオーダー指示に含まれる、というような状態も考えられる。現在は、ORC−4−数量/タイミングのフリー・テキスト 条件 成分により任意の条件を指定することができる。しかし、完全にコード化したオーダー・シーケン
スあるいは結果条件をサポートするために、次のパラグラフでORC−4−数量/タイミングの第10番成分を定義した。
この第10成分のサポートするシーケンス化条件は、あるオーダーの終了に基づく。
第11成分以降は将来に備えた予約であり、オーダーの実行前に複数の条件を評価するよう指定するのに使用する。将来をにらんだこのような指定により、現在の数量/タイミング定義との上位互換性が保たれる。

Copyright©2002 JAHIS V2.0

46

JHLDEX20.DOC 2002/06/26

注記：第10成分が存在する場合、第7成分(条件成分)は、依頼のさいに表示されるテキスト

注記

とみなされ

る。すなわちシステムは、このテキストをシーケンス化指定の一部として解釈することはない。

シーケンスの副成分
シーケンス条件を定義するために、数量/タイミング・フィールド成分の第10成分は、図4−1に示す副成分に分割される
図 4-1. オーダー・シーケンスの副成分
Subcomponent
1

Contains
シーケンス/結果フラグ

Notes
Sはシーケンス状態; Cは循環, R は将来の使用のためリザーブしてある。

2, 3

依頼者オーダー番号4, 5

実施者オーダー番号6

シーケンス状態値

7

最大繰り返し数

8,9

依頼者オーダー番号､最後の2つの成分10,11

実施者オーダー番号､最後の2つの成分

必須/オプション: 2つの副成分を使用する；何故なら依頼者オーダー番号は2つの副成分を持つためである。HL7では副成分の副成分は定義していない。
必須/オプション: 2つの副成分を使用する；何故なら実施者オーダー番号は2つの副成分を持つためである。HL7では副成分の副成分は定義していない。
許容状態値は、プロジェクト計画法で通常使用される形を持つ:<one of "SS", "EE", "SE", or "ES"> +/- <time>
1文字目は先行オーダーの開始時間(S)又は終了時間(E)を意味する。先行オ
ーダーは、副成分1、2又は3、4の依頼者又は実施者オーダー番号によって定義される。
2文字目は後続オーダーの開始時間(S)又は終了時間(E)を意味する。この後続オーダーは、ここの数量/タイミング仕様を含むオーダーである。時間として、先行および後続の始まり又は終わりの間隔を指定する(下記に例を示す)。
<時間>の定義:
S<integer><integer> 秒M<integer><integer> 分
H<integer><integer> 時間
D<integer><integer> 日W<integer><integer> 週
L<integer><integer> 月
最大繰り返し数が使用されるのは循環グループだけである。繰り返し総数
は、最後の繰り返しの終わりの日付/時間又は親の終わりの日付/時間のうち、最初に来る方によって制約される。
要求/オプション:依頼者オーダー番号の最後の2つの成分を含んでいる:普遍的なID(ST)および普遍的なID･タイプ(ID)(それぞれ)｡依頼者オーダー番号がEI
データ型であるので､2つの副成分を使用する｡我々はHL7では副成分を定義していない｡
要求/オプション:依頼者オーダー番号の最後の2つの成分を含んでいる:普遍的なID(ST)および普遍的なID･タイプ(ID)(それぞれ)｡依頼者オーダー番号がEI
データ型であるので､2つの副成分を使用する｡我々はHL7では副成分を定義していない｡

使用上の注意：以下を仮定する。
先行オーダーは、｢ORC−4−数量/タイミング｣の第10成分の副成分2と3において、依頼者
オーダー番号としてOE1000&OrdEntにより定義される。
後続オーダー、つまり今回のオーダーは、ORCセグメントに依頼者オーダー番号
OE1001^OrdEntを持つ。
次のシーケンス条件値の意味を説明する。
｢OE1000&OrdEnt(先行オーダー)の終了時間 ＋ 10分｣により、後続オーダー、OE1001^OrdEnt(今回のオーダー)の開始時間を定義する；つまり、先行オーダーが終了してから10分後に、このオーダーを開始せよ、ということ。
｢先行オーダーの開始時間−10分｣によりこのオーダーの開始時間を定義する。つまり、先行オーダ
ーの10分前にこのオーダーを開始、ということ。

ES + 10M

SS - 10M

循環依頼者グループ
反復すべき循環オーダーがある場合、実行される最初のオーダーは、アスタリスク(＊)で始まる シーケンス条件値 を持つ。
Example:第10成分に指定された条件を評価せずに、このオーダーを1回実行する。指定された外部オーダーの開始・終了日時がこの条件に合致したときのみその実行を繰り返す。このように指定すると、各サイクルでオーダーが1回反復される。

*FS+10M

注記： オーダーを繰り返すには、依頼アプリケーションは、最初のオーダーの数量/タイミングを指定する際に、サイクル内の最終オーダーの依頼者オーダー番号を指定できなければならない。

Copyright©2002 JAHIS V2.0

47

JHLDEX20.DOC 2002/06/26

親子パラダイムを使用して、4つのIVオーダーから成る循環グループを指定するには、親はIVのカスタム・グループを指定する。すると、以下のように処理が実行される。
2番目の子オーダーのORC−4−数量/タイミングは、それが1番目の子オーダーに続くことを示す。
3番目の子オーダーのORC−4−数量/タイミングは、それが2番目の子オーダーに続くことを示す。
4番目の子オーダーのORC−4−数量/タイミングは、それが3番目のオーダーに続くことを示す。

4つの子オーダーから成るグループを循環的に繰り返すには次のように処理が実行される。:
1番目の子オーダーのORC−4−数量/タイミングは、この子オーダーが、他のオーダーが終了したかどうかとは無関係に、1度実行されることを示す。
この子オーダーが2回目に実行されるのは、4番目のオーダーが終了してからである。
このスキームにより、下記情報を追跡することができる：
親オーダーのレベルで返答すべきオーダー・グループ全体の状態。
対応する子オーダーの状態をフォローすることによって、IVオーダーそれぞれの状態。
個別のオーダー例：同じグループのオーダーは、その数量/タイミング・フィールド内のデータによってのみ連携させることで、4つのオーダー(共通の親のない)を1グループとして送ることができる。この場合HL7では、グループ全体のオーダー状態をまとめて伝送する便利な手段がないので、4つのオーダーの個々の状態を別々に伝送するしかない。
オーダー状態の継承
キャンセル/中断/保留オーダー制御イベント：
ここでは、指定された先行オーダーが通常通り実行されることを想定している。したがって、先行オーダーのキャンセル(あるいは中断、保留)は、後続の関連オーダーすべてを取り消す(あるいは中断する、保留する)ことを意味する。
参照されているオーダーが取り消された(あるいは中止、保留された)場合、今回のオーダー
はそれと同じ状態を継承する。
保留の場合、先行オーダーの保留を解除することは、その該当オーダーも解除するという意味である。(したがって、そのオーダーは第10成分内の指定にしたがって実行することができる。)
Occurrence duration 発生持続成分 (CE)
Subcomponents：<識別子> & <テキスト> & <コーディング方式名> & <代替識別子> & <代替テキスト>& <代替コーディング方式名>

Total occurrences 発生からの合計 (NM)

Examples of quantity/timing usage数量/タイミングの使用例
3^once

指定時刻にサービスを実行する。たとえば、3単位の輸血を1回実行せよというオーダー。
1^QHS^X2

就寝時にサービスを2回実行する。たとえば、2夜連続、就寝時に1単位の輸血。
1^C^3D

3日間サービスを継続する。
1^Q1H^X4^^^^PVCs>10/min

患者のPVCが毎分10を越える場合は、最大4回、1時間ごとにEKGを実行する。
1^Q2J^^1432

毎週火曜日、午後2：32にサービスを実行する。
1^^^^198911210800

11/21/89 0800前に検査を実行する。たとえば手術前の臨床検査。
1^Q3600S^X5^198911051030

11/5/89の午前10:30より、5時間に渡って、1時間ごとにサービスを実行する。血糖採取など。
1^QAM^X3^^^^^^S~1^QOD^4D^^^^if K+>5.5.

3日間毎朝サービスを実行し、血清カリウムが5.5を越える場合、4日間(つまり最大2回)1日
おきにサービスを朝に実行する。
^^^198812120800^^T^^Trough specimen for MIC^C~^^^^^R

12/12/1988午前8:00きっかりに採血し、ルーチンにしたがい結果を報告する。

Copyright©2002 JAHIS V2.0

48

JHLDEX20.DOC 2002/06/26

5.6 検査項目コードについて
OBR-4,OBX-3には下記で定義された検査項目コードを使用するものとする。
日本臨床病理学会 臨床検査項目分類コード
最新版は第10回改訂第1版(JLAC10)1999.11である。 詳細は日本臨床検査医学会(旧 日本臨床病理学会)のホームページ http://www.jscp.org/ を参照。
基本コード体系｢臨床検査項目分類コード(以下、｢項目コード｣という)｣は５つの要素区分よりなり、それぞれ(1)分析物コード、(2)識別コード、(3)材料コード、(4)測定法コード、(5)結果識別コードと称する。
｢項目コード｣は、基本的に 分析物コード により整理分類され、検査材料あるいは測定法等の別を所定の付加コードとの組み合わせにおいて認識する。
(１)分析物コード：検査対象物質を所定の細則に基づき、５桁の文字列により分類する。なお、
一部例外として 反応名 を 物質名 に代えて適用する場合がある。
[例] 潜血反応、TTT、ZTT(２)識別コード：分析物コードを検査内容に沿って細分する必要がある場合に４桁の数列により分類する。
[例] ウイルスの分類、ウィルス抗体価の分類、アレルゲンの分類、リンパ球のCD分類(３)材料コード：同一項目における検査材料の別を３桁の数列により分類する。
5.7 節はこのコードを転記している。
(４)測定法コード：同一の項目における測定法の別を３桁の数列により分類する。
[例]ラジオイムノアッセイ二抗体法、紫外吸光度法、嫌気性培養(５)結果識別コード：一つの検査項目において、結果が単独あるいは複数を問わず、結果表現の別を２桁の数列により分類する。
｢項目コード｣の運用例[例] 髄液単純ヘルペスCF抗体価(CF法)
血清単純ヘルペス中和抗体価(中和法)
分析物
識別
材料
測定法
結果識別

単純ヘルペス
ウイルス抗体血清
髄液
CF法
ウイルス中和法
希釈倍率(共通)
HSV−1抗原(固有)HSV−2抗原(固有)

5F190
1430
023
041
141
151
05
51
52

検査依頼時のコード
髄液単純ヘルペスCF抗体価： 5F190−1430−041−141
血清単純ヘルペス中和抗体価：5F190−1430−023−151
結果報告時のコード
髄液単純ヘルペスCF抗体価： 5F190−1430−041−141−05(希釈倍率)
血清単純ヘルペス中和抗体価：5F190−1430−023−151−51(HSV‑1抗原)
5F190−1430−023−151−52(HSV‑2抗原)

臨床検査項目分類コードの利用
臨床検査項目分類コードは5つの基本コードを組合せ、実際の検査項目コードとして使用する。 検査依頼時では結果識別コードを除く15桁で表現され、結果報告時ではさらに結果
識別コードが追加され17桁で表現される。
検査項目コードと検査材料の関連
検査項目コード中に材料が設定されているが、これはあくまで一つの検査項目測定系を示すものである。 したがって、検査データを扱うシステムでは検査項目フィールドと検査
材料フィールドを別に持つべきである。 OBR/OBXで用いる場合、検査項目フィールドCopyright©2002 JAHIS V2.0

49

JHLDEX20.DOC 2002/06/26

(OBR-4,OBX-3)にはオーダーする検査項目を示すコード(すなわち商品コードのような性格)を、検査材料フィールド(OBR-15)には実際に提出する材料コードを設定する。
検査項目コード事例集
臨床検査項目分類コードを実際に組み合わせ検査項目コードを付番するのは様々な解釈もあり容易ではない。前述のホームページ内、臨床検査項目分類コードのコンテンツには、運用コード表と称して、これらのコード表と短縮したコードの参考例が示されている。

Copyright©2002 JAHIS V2.0

50

JHLDEX20.DOC 2002/06/26

5.7 検査材料・採取部位コードについて
OBR-15では下記で定められた材料コードを使用するものとする。
日本臨床病理学会 臨床検査項目分類コード 材料コード
最新版および詳細については 5.6節を参照。
［材料コード適用細則］
1. 材料コードの選択は，一般の生体成分分析等においては 材料コードⅠ によるものとし，細胞診・生理機能検査等に使用される 組織の詳細および生体部位 については 材料コードⅡに，その他の非生体材料については 材料コードⅢ による。
2. ｢尿｣および｢血液｣について特別な場合を除き，尿は｢尿(含むその他の尿)｣(001)および｢蓄尿｣(004)を，血液は｢全血｣(018)，｢血漿｣(022)および｢血清｣(023)に分類することが望ましい。
3. ｢全血(添加物入り(019)｣について
抗凝固剤，抗血小板剤等の添加物により検査材料の安定化を必要とする検査項目に適用する。
4. ｢ペア材料｣(098)について
複数の異なる検査材料を必要とする検査項目に適用する。
[適用例]各種クリアランス試験
材料コードⅠ一覧
コード
001
002
003
004
005
006
007
008
009
010
011
012
015
017
018
019
020
021
022
023
024
025
026
027
028
029
030
031
032
033
034
036
037
038
039

材料名
○尿・便
尿(含むその他)
自然排尿
新鮮尿
蓄尿
時間尿
早朝尿
負荷後尿
分杯尿
カテーテル採取尿
尿ろ紙
膀胱穿刺
動物尿
便
○血液
血液(含むその他)
全血
全血(添加物入り)
動脈血
毛細管血
血漿
血清
血球浮遊液
赤血球
リンパ球
血小板
白血球
臍帯血
溶血液
除タンパク液
血液抽出液
血液ろ紙
血液塗抹標本
動物血
動物全血
動物血漿
動物血清

Copyright©2002 JAHIS V2.0

コード
040
041
042
043
044
045
046
047
048
049
050
051
052
053
054
055
056
059
060
061
062
063
064
065
066
067
068
069

材料名
○穿刺液
穿刺液(含むその他)
髄液
胸水
腹水
関節液
心嚢液
骨髄液
羊水
腰椎
骨髄塗抹標本○分泌液
分泌液(含むその他)
消化器系からの分泌液
胃液
十二指腸液
胆汁
膵液
唾液
前立腺液
精液
喀痰
乳汁
鼻汁
咽喉からの分泌液
耳からの分泌液
目からの分泌液
膣からの分泌液
皮膚からの分泌液(汗)
気管からの分泌液

51

コード
070
071
072
073
074
075
077
078
081
082
083
085
086
087
088
089
090
091
092
093
094
095
096
097
098
099

材料名
○組織
組織*(含むその他)
生検組織*試験切除組織*手術切除組織*剖検切除組織*
固定組織*
○その他
毛髪
爪
結石(含むその他)
尿路系結石
胆石
擦過物
膿(含むその他)
開放性の膿
非開放性の膿
水泡内容物
嘔吐物
洗浄液
血液以外の抽出液
浸出液
塗抹標本(血液，骨髄以外)
透析液
かん流液
培養液
ペア材料
その他の材料JHLDEX20.DOC 2002/06/26

材料コードⅡ(組織及び生体部位)使用上の注意
組織及び生体部位は200〜990の3桁で定義し，生検，及びそれぞれの切除組織は，下記のように定義する。
生検組織
試験切除組織
手術切除組織剖検切除組織

皮膚
胃
骨
膀胱
膣
虫垂
肺
小脳

⇒ ○○1or○○6⇒ ○○2or○○7⇒ ○○3or○○8⇒ ○○4or○○9

例
生検組織
⇒201
生検組織
⇒456
試験切除組織⇒252
試験切除組織⇒667
手術切除組織⇒553
手術切除組織⇒478
剖検切除組織⇒334
剖検切除組織⇒719

材料コードⅡ(組織及び生体部位)
コード
200
205
210
220
225
230
250
255
260
265
270
275
280
300
305
310
315
330
335
340
345
350
355
365
370
375
380
385
390
395

材料名
○皮膚・乳腺
皮膚
乳房
乳腺○造血・ リンパ・細網
リンパ節
脾臓
骨髄
○運動器・軟部
骨
関節
骨格筋、筋膜
軟骨
靭帯
腱、腱鞘
軟部組織
○呼吸器(上部呼吸器)
鼻
鼻腔
上顎洞，他の副鼻腔
喉頭蓋、喉頭○呼吸器(肺・気管支)
肺
気管
気管支
肋膜
縦隔
胸膜
その他の呼吸器○心臓・血管
心臓
心臓弁膜
心嚢
血管
動脈
頚動脈

コード

400
405
410
415
420
425
430
435

450
455

460
465
470
480
485

500
510
515

530
535
545
550
555
560
565
570
575
580
585
590
595

材料名
○消化管・付属消化器(口腔および喉頭)
口腔
口唇
舌
歯
歯肉
唾液腺
咽頭
扁桃
○消化管・付属消化器(上部消化管)
食道
胃○消化管・付属消化器(下部消化管)小腸，十二指腸膨大部
空腸および回腸
大腸
直腸
肛門○消化管・付属消化器(肝・胆・膵)肝，肝内胆管胆道(外胆管，外胆道)膵○消化管・付属消化器(腹膜・後腹膜)
腹膜
後腹膜、尾仙部
その他の消化器○泌尿生殖器(女性器)
膣
子宮
子宮頚部
子宮膣部
子宮内膜
卵管
卵巣
胎盤，臍帯
絨毛その他
外陰およびその他の女性器

コード
600
605
610
615
620
650
655
660
665
670
695
700
705
710
715
720
725
730
735
740
795
800
805
810
815
820
825
830
895
900
910
920
930
990

材料名
○泌尿生殖器(男性器)
全立腺、精嚢睾丸
陰茎その他の男性性器
男女不明性器○泌尿生殖器(泌尿器)
腎臓
腎盂
尿管
膀胱
尿道
その他の泌尿器○神経感覚器眼および眼付属器
大脳(大脳半球，脳梁)
中脳、橋
小脳
延髄、脊髄
脳膜、脊髄膜内耳
脳神経
脊髄神経
その他の神経系○内分泌
下垂体、頭咽管
松果体
副腎
旁神経節
甲状腺
副甲状腺
胸腺
その他の内分泌
○その他
頭頚部
胸郭
腹部
上下肢
その他部位

材料コードⅢ(その他の非生体材料)
コード
材料名
991
X線フィルムCopyright©2002 JAHIS V2.0

コード

材料名

52

コード

材料名

JHLDEX20.DOC 2002/06/26

5.8 検査結果コメントの扱い
検査結果コメントを必要とする場合、必要とするOBXに続いてNTEでコメントするか、検査項目IDを接尾辞で修飾することによりOBXを追加する方法がある。コメントの性格が明確になる後者の方法を推奨する。以下にその方法について解説する。
OBXに伴う叙述的報告について
放射線科などの部門から送信される読影レポートは通常、多くの副成分から構成される(たとえば胸部X線レポートは、記述、診断、指導から構成することができる)。心電図などのその他の検査には、そのような類似の成分だけでなく数値検査(左心室拡張期の直径など)も含まれる。外科病理学レポートには、採取部位、概略記述、詳細記述および各検体の仮診断など複数の検体・レポート関連情報を含むことができる。
HL7は、叙述的報告共通成分に使う検査IDを構築するためのコード接尾辞を定義した(図7．
1を参照)。そのような成分に使う検査項目は、適切な接尾辞を検査群ID(どのようなコーデ
ィング方式の場合でも先行OBRの｢OBR−4−検査群ID｣内のID)に連結することで得られる。
たとえば、胸部X線診断用の検査IDは、胸部X線検査ID(CPT4の場合、71020)、副成分区切
り文字、それに接尾辞 IMP から構成される(つまり71020&IMPになる)。
送り手と受け手が合意した場合、結果セグメントの 検査ID 成分は、先行OBRの検査IDと同じならば、オプションで省略することができるだろう。この場合、結果セグメントのOBX−3−検査項目内には&IMP、&RECなどと記述して、&と接尾辞だけを送信すればよい。
図 7-1. Observation ID suffices

検査項目接尾辞

Coded Results
Diagnostic Impression 所見
Recommendation 指導
Confirming Procedures 処置確認
Procedure Medication 投薬治療
Anatomic Site 部位
Device/Instrument 機器/器具
Serial # Device/Instrument 機器/器具の連番

Suffix
IMP
REC
CNP
MED
ANT
DEV
SER

Type
CE
CE
CE
CE
CE
CE
ST

Bulk Text Reports テキスト・レポート
Gross Or General Description Of The Study 検査の概略記述または概要
Microscopic Or Secondary Description 詳細または2次的記述
Technician's Comment 医療技術者のコメント
Addendum Note 追加メモ

GDT
MDT
TCM
ADT

TX or FTTX or FTTX or FTTX or FT

Other その他
Diagnosis Onset Date/Time 診断開始日時
Diagnosis Resolution Date/Time 診断終了日時
Comparison Study 比較検査
Comparison Date/Time 比較日時
Comparison Results 比較結果
Comparison Change 比較変化
Predicted Value 推定値
Percent Predicted 推定率
After Drug Observed 投薬後観察
Predicted Value After Drug 投薬後推定値
Percent Predicted After Drug 投薬後推定率
Timing Information タイミング
Channel Definition Data チャンネル定義
Waveform Digital Data 波形デジタルデータ
Waveform Annotation 波形注釈

ITM
RTM
CMS
CMT
CMR
CMC
PRD
PPR
AFD
ADP
APP
TIM
CHN
WAS
ANO

TS
TS
CE
TS
CE
CE
ST
ST
ST
ST
ST
TS
CD
NA or MA
CE

叙述的報告の共通成分に使う検査IDを定義するための接尾辞の解説
Diagnostic impressions 所見(IMP)接尾辞がIMPの場合結果は診断か所見でありCEデータ型として保管される。僧帽弁脱出症と大動脈弁狭窄症などの複数の別個の診断が報告されている場合、それぞれの診断は個別のOBXセグメントで送るべきである。1個のコード化結果セグメントに複数のコードが含まれているのは、そのようなコードが主要診断の修飾子である場合に限られる。つまり主要診断に関する追加詳細情報を報告するためであり、全く異なる診断を報告するためではな

Copyright©2002 JAHIS V2.0

53

JHLDEX20.DOC 2002/06/26

い。
所見用コード化データ型が存在するからといって、報告部門でそのような所見をすべて実際にコード化しなければならないということではない。所見は書き取りテキストとして送信できるが、テキストは、CEデータ型の第2成分で送信することにより、コードを区別すべきである、つまり、テキストの前には成分区切り文字を記述すべきである(たとえば＾う
っ血性心不全のように)。複数のテキスト所見が報告されている場合、個別のOBXセグメン
トで報告し、それらのテキスト所見が別個の所見であることを示すべきである。
Recommendations 指導(REC)接尾辞がRECの場合、その値はCE結果であり、反復テスト、フォローアップ、あるいは治療に関する読影医師の指導を表わしている。たとえば、疑わしい病変結果がマンモグラフ
ィ上で見られたら、読影医師は、6か月以内にマンモグラフィを再実施するかあるいは直ちに穿刺生検を実施するよう指導することができる。指導手順は、コードとして、および(もしくは)コード化識別子構造のテキスト記述として記録する。複数のフォローアップ検査が推奨されている場合、そのような指導はそれぞれ個別のRECで送られる。
Confirming procedure 処置確認(CNP)
処置確認OBX接尾辞は、IMP OBXに報告された診断を確定するのに使用される追加検査を識別する。たとえば、電子顕微鏡を使って外科病理学診断を確定する場合、電子顕微鏡｢OBX−3−検査項目｣用識別子は、処置確認を表す接尾辞の付いた検査IDの値フィールドとして保管されるだろう。処置確認は、外科病理学レポートにおいて最も重要である。しかし処置確認は内視鏡検査などのサービスでも使用され、処置確認として生検や培養などを実施したと記録することもできる。
Procedure medication 処置投薬治療(MED)
接尾辞MEDの付いたOBX−3−検査項目は、造影剤の投薬、生理反応を引き起こすことを目的とした投薬(ストレス試験などを実施するために)、あるいは事前投薬など、手順の一部
として投薬を実施した場合その薬剤に関する情報が含まれていることを示す。患者が複数の投薬を受ける場合、それぞれの薬剤は個別のOBX投薬セグメントで報告すべきである。
伝送システムで投薬にコードを利用できる場合、そのようなコードはOBX−3−検査項目の第1成分として記録する。薬剤名と(または)投薬量は、OBX−5−検査結果値の第2成分に含むことができる。
Anatomic site 解剖部位(ANT)
単一レポートに複数部位についての検査を含むような診断観察がある。たとえば患者が胆嚢手術に伴い虫垂切除術を受けた場合、両検体に対する病理学者の病理診断は通常、1つのレポートの単一検体番号に含まれるだろう。それぞれ個別の部位は、接尾辞ANT(OBX−3−検査項目)を持つ個別のOBXセグメントとして報告されることになる。
Devices 装置(DEV)
要求があれば、検査の実施に使用した器具あるいは装置を検査の追加 結果 として転送することができる。この場合、OBX−3−検査項目の接尾辞はDEVである。たとえば、臨床検査室の自動化装置、放射線科の画像装置とそのモデル番号、病棟の自動血圧測定器など。
装置の識別子はいずれコードとして指定されることが予想されるので、コード化された入力値として装置を指定する。とりあえず当初は、装置関連情報のほとんどをCE識別子の第2成分のテキストとして転送すると期待される。
Serial# Device / Instrument 機器/器具の連番(SER)
必要に応じ、検査に使用した機器や器具の製造番号などの連番を表記する場合に用いる。
Gross or general description 概略記述もしくは一般記述(GDT)
一般記述を表す接尾辞により、診断検査の記述成分が識別される。解剖病理学の場合には、
一般記述は検体についての概略記述に適用される。記述が複数のパラグラフから成る場合、受信コンピューター側でパラグラフをパラグラフとして表示できるようにするため、パラグラフは反復区切り文字により分離すべきである。レポートが簡潔に表現できる通常検査
やEKG検査などの場合は、診断セグメントですべての情報を表現し尽くしていれば、レポート用記述セグメントを含むる必要はないだろう。

Copyright©2002 JAHIS V2.0

54

JHLDEX20.DOC 2002/06/26

Secondary or microscopic description 2次的記述もしくは詳細記述(MDT)
ほとんどの検査では2次的記述は必要ないだろう。しかし、外科病理学の場合には、詳細記
述はレポートの独立箇所として存在する。それは顕微鏡を通して見られるような顕微鏡組
織検査について記述する。詳細記述は、OBX−3−検査項目の接尾辞にMDTを指定したセグメントで送られるだろう。
Technician comment 医療技術者コメント(TCM)
医療技術者がコメントを記述するのに使用するフリーテキストであり、OBX−3−検査識別子の接尾辞がTCMである結果セグメントに保管される。このコメントの内容は通常、処置を実施する際の技術情報である。
Addendum note 追加情報メモ(ADT)
オリジナルの叙述の後に追加情報として加えられ、レポートの個別のラベル付きセクションとして送られる情報を報告するのに使用する。
Diagnosis (problem) onset date-time 診断(プロブレム)開始日時(ITM)
プロブレムが存在するとはじめて認識された日時を記録するのに使用。
Diagnosis (problem) resolution date-time 診断(プロブレム)終了日時(RTM)
プロブレムが治療されたか軽減した日時を記録するのに使用。
Comparison study 比較検査(CMS)
診断レポートの読み手が現在の検査結果を以前の検査結果と比較する場合、この接尾辞により、比較検査の性質を個別の結果として報告することができる(つまり検査IDの接尾辞がCMSであるセグメントを持つOBXセグメント)。他の任意の比較値が転送さていれば、他の比較OBXセグメント内の検査IDによりテストが識別されるので、通常これは必要とされない。
Comparison date-time 比較日時(CMT)
診断処置の読み手が以前の検査結果と現在の検査結果を比較する場合、この接尾辞により、以前の検査の日時を個別の結果として現行レポートで報告することができる。
Comparison results 比較結果(CMR)
診断処置の読み手が、現在の結果を同じ患者に関する以前の結果と比較する場合、この接尾辞により、以前の結果(診断)を個別の結果として現行レポートで報告することができる。
Comparison change 比較変化(CMC)
診断部門が現在の検査と以前の検査の比較を報告する場合、この接尾辞を使って変化の程
度を個別の結果としてレポートに報告する。(たとえば、大幅に悪化、悪化、最小限悪化しないこと、変化なし、少し回復、回復、非常に回復、正常に回復)現行の書き取りレポート
では、比較に関する情報は通常、検査記述に含まれる。上に列記した比較接尾辞の規定は、
この情報を個別の成分として送信しなければならないという意味ではない。単に比較変数を使用できるという意味である。システム側で個別のレポート成分としてこの情報を転送したい場合、これらの接尾辞により所望の比較を選択することができる。
Predicted 推定(PRD)
多くの肺活量測定の場合がそうであるように、検査に推定値がある場合、この接尾辞により推測と実測定が区別される。最大肺活量を表すAS4コードは94010．1である。推定される最大肺活量は94010．1&PRDになるだろう。
Percent of predicted 推定率(PPR)
これは(実測)/(推測)により計算される観察である。最大肺活量の場合、推定率は94010．
1&PPRとなるだろう。
After drug observed 投薬後検査(AFD)
投薬の前後に検査を実施する場合がある。これは特に肺活量測定で生じる。投薬前検査は基本IDにより識別される。投薬後測定は接尾辞｢AFD｣により識別される。最大肺活量に基
本コード｢AS4｣を使用して、投薬後結果は94010．1&AFDとして特定されるだろう。

Copyright©2002 JAHIS V2.0

55

JHLDEX20.DOC 2002/06/26

Predicted value after drug 投薬後推測値(ADP)
投薬後推測値は、接尾辞｢ADP｣により識別される。上記のパターン例に従い、94010．1&ADPとなるだろう。
Percent predicted after drug 投薬後推測率(APP)
投薬後の推測率は、基本単位コードへ接尾辞｢APP｣を適用することで識別される―― 最大肺活量にAS4コードを使用して94010．1&APPとなる。
Timing Informationタイミング情報(TIM)
TIM属性OBX結果セグメントは、波形チャネルをグループ化する与えられた検査サブIDにおいて、第1のデータポイントの日付および時間を確立する。波形データの時間シーケンス
でギャップがある場合、これは、同じ検査サブIDを備えた事後のWAV属性結果セグメントに先立ち、新しいTIM属性結果セグメントの送信によって示されるべきである。
Channel Definition Data チャネル定義データ(CHN)
CHN属性OBX結果セグメントは、ディジタルでサンプリングされた時系列波形のための1
つ以上の記録チャネルを定義する。OBX-5−検査値フィールドは補足チャネルを定義する
ために反復することがある。
Waveform Digital Data 波形ディジタルデータ(WAV)
WAV属性OBX結果セグメントは、実際の波形データ(アナログ/デジタル変換器(ADC)またはサンプリングされた時系列ディジタルデータ)を送信するためである。WAV属性結果セグ
メントは、それらの対応チャネル定義(CHN属性OBX結果セグメント)に検査サブIDを介して関係している。CHN属性結果セグメントの中で定義されたチャネルの数は、それに関連したWAV属性結果セグメントに含まれていた、多重化データのチャネルの数を指定する。
すべてのチャネルに対する多数の連続の時間での波形データの与えられたセットは、単一のWAV属性結果セグメント中で送信される(ただし検査値フィールドの長さがOBXセグメ
ントの最大定義フィールド長さの65536を超過しなければである)。または多数の連続のWAV属性結果セグメント中で送信される。このときは、おそらく他の種類の点在した結果
セグメントとともにである(例えば注釈、すなわちコメントを含んで)。
WAV属性結果セグメントのデータ型はNA(数値の配列)またはMA(多重化される配列)である。NAデータ型を使用すると、データ値は｢チャネルブロック｣、すなわち｢多重化されていない｣書式で記録される。各チャネルのためのディジタルサンプルは、成分の区切記号を使用して分離される。また、連続のチャネルは、反復区切記号を使用して分離される。MA
データ型を使用すると、データ値は｢多重化チャネル｣の書式で記録される。すなわち、第1
時間サンプルの値(すべてのチャネル)が最初に送信される。次に第2時間サンプルの値(すべてのチャネル)が送信される。以下同様にすべてのサンプルが送信されるまで続く。各チャ
ネルのディジタルデータは成分区切記号によって分離される。また、連続のデータは反復
区切記号によって分離される。チャンネル多重化書式が使用できるのは、多重化チャネル
がすべて同じ有効なサンプリング周波数を持っているときだけである。
Waveform Annotation 波形注釈(ANO)
ANO属性OBXセグメントが使用されるのは、波形注釈(波形記録中に与えられたときに関連したコード化された入力)を送信するためである。ANO属性結果セグメントは、それらの対応するチャネル定義(CHN属性OBX結果セグメント)に対して、検査サブIDを介して参照される。CHN属性結果セグメントの中で定義されたチャネルの数は、それに関連した任意のANO属性結果セグメントに含まれる注釈のチャネルの数を指定する。
ANO属性結果セグメントのデータ型はCEである。連続のチャネルへの注釈コード化入力は、
反復区切記号を使用して分離される。隣接する反復区切り記号が使用されるのは、チャネ
ルの注釈コード化入力が多重チャンネルの結果セグメントの中にないときである。値については使用者定義テーブル0317を参照。
使用者定義テーブル 0317 - Annotations
Value
9900
9901
9902
9903

Copyright©2002 JAHIS V2.0

Description
ペーススパイク
SASマーカー
感知マーカー
ビートマーカー

56

JHLDEX20.DOC 2002/06/26

9904

etc

検査結果コメントの例
検査結果コメントは検査結果のOBXに続くOBXで表現する。コメントの値型はSTやTXが代表的と考えられるがコメントコードでの運用しか出来ない場合は二者間の協議で値型CEでコードでの運用も可能である。出来る限りコメント内容に制限のないフリーテキストを推奨する。MEDIS暫定版では統一結果コメントを定めていたのでその場合のsuffixも参考にされたい。下記はその例である。
OBX||NM|3A016000002327101^A/G比^JC10||2.33||1.30-2.00|H|||F 検査結果
OBX||CE|3A016000002327101&TCM^^JC10||E01^参考値です^L||||||F
そのコメントＭＥＤＩＳ−ＤＣ臨床検査データ交換規約暫定版 結果コメントの例
コメント グループ（Ａ） 検査材料に関するメッセージ（Ｂ） 検査方法に関するメッセージ（Ｃ） 結果値を補足する

メッセージ（Ｄ） 単位・基準値に関するメッセージ（Ｅ） 参考値に関するメッセージ（Ｆ） 後日報告に関するメッセージ

Copyright©2002 JAHIS V2.0

記号
Ａ０１
Ａ０２
Ａ０３
Ｂ０１
Ｂ０２
Ｂ０３
Ｂ０４
Ｂ０５
Ｃ０１
Ｃ０２
Ｃ０３
Ｃ０４
Ｃ０５
Ｃ０６
Ｃ０７
Ｃ０８
Ｄ０１
Ｄ０２
Ｅ０１
Ｅ０２
Ｅ０３
Ｅ０４
Ｅ０５
Ｅ０６
Ｅ０７
Ｅ０８
Ｅ０９
Ｅ１０
Ｅ１１
Ｅ１２
Ｅ１３
Ｅ１４
Ｅ１５
Ｅ１６
Ｅ１７
Ｅ１８
Ｅ１９
Ｅ２０
Ｅ２１
Ｅ２２
Ｆ０１
Ｆ０２

コメント内容凝固が認められました
溶血しておりました
乳びしておりました
高値のために希釈いたしました
検体量不足のため希釈検査いたしました
検体状態により希釈検査いたしました
抗補体作用により希釈検査いたしました
濃縮検査いたしました
再検済です
検体量不足のため再検できませんでした
弱い反応が認められました
非特異性反応が認められました
抗補体作用が認められました
薬剤の影響が考えられます
報告書の参照をお願いいたします
別紙の参照をお願いいたします
単位が変更になっております
基準値が変更になっております
参考値です
溶血検体のため参考値です
乳び検体のため参考値です
ビリルビン高値検体のため参考値です
フィブリン析出のため参考値です
非特異性反応が認められ参考値です
検体量不足のため参考値です
指定外材料のため参考値です
凝集のため参考値です
凝固のため参考値です
細胞崩壊のため参考値です
汚染の影響が考えられますので参考値です
リンパ球（細胞数）が少ないため参考値です
除蛋白不十分につき参考値です
指定外容器のため参考値です
検査材料不備のため参考値です
時間経過のため参考値です
混濁検体のため参考値です
採取方法不適当のため参考値です
パターン不良のため参考値です
自己抗体陽性につき参考値です
他成分の重複が考えられます
後日報告いたします
再検中です

57

suffix
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ

JHLDEX20.DOC 2002/06/26

コメント グループ（Ｇ） 検査中止に関する

メッセージ

記号
Ｆ０３
Ｆ０４
Ｇ０１
Ｇ０２
Ｇ０３
Ｇ０４
Ｇ０５
Ｇ０６
Ｇ０７
Ｇ０８
Ｇ０９
Ｇ１０
Ｇ１１
Ｇ１２
Ｇ１３
Ｇ１４
Ｇ１５
Ｇ１６
Ｇ１７
Ｇ１８
Ｇ１９
Ｇ２０

コメント内容高値のため再検中です
低値のため再検中です
検体量不足のため検査不可能でした
溶血検体のため検査不可能でした
乳び検体のため検査不可能でした
凝固検体のため検査不可能でした
部分凝固のため絶対数は出ません
ビリルビン高値検体のため検査不可能でした
非特異性反応が認められ検査不可能でした
測定感度以下のため検査不可能でした
抗補体作用が認められ検査不可能でした
リンパ球（細胞数）不足により検査不可能でした
薬剤の影響が認められ検査不可能でした
細胞崩壊のため検査不可能でした
検査材料が異なるため検査不可能でした
定性結果が陰性のため定量検査は中止いたしました
データ値は換算できませんでした
未知物質干渉のため検査不可能でした
増殖不良のため分析できませんでした
データは検出できませんでした
検査不可能でした
検査を取消いたしました（Ｚ） 運用時にユーザの要望により

suffix
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＴＣＭ
ＡＤＴ

設定するコメントＺ０１〜Ｚ２０

Copyright©2002 JAHIS V2.0

58

JHLDEX20.DOC 2002/06/26