J
JapaneseA

医療情報交換仕様

Association of

H
Healthcare

JAHIS
処方データ交換規約
Ver. 1.1

I
Information

S
Systems Industry

平成15年 2月
保健医療福祉情報システム工業会
メッセージ交換委員会
部門システム委員会

JAHIS 処 方 デ ー タ 交 換 規 約
まえがVer. 1.1

き国内においては、従来よりＨＩＳ（病院情報システム）と自動調剤システム間のデータ交換において、メーカ間での統一はもとより、同一メーカにおいても導入ユーザによってその仕様が異なり、接続するにあたり多くの手間を要している。 保健医療福祉情報ｼｽﾃﾑ工業会（ＪＡＨＩＳ）は、この問題に対処すべく、
部門システム委員会においてデータ交換項目の標準化の検討を開始した。
また、地域連携、病診連携等で病院内外での処方データ交換の必要性が増すなか、処方データ交
換規約の標準化が重要な課題となってきた。
本規約は、そうした状況を踏まえ、部門システムでの検討結果をベースにしたものの、情報の受手を自動調剤システムには限定せず、広く処方データの交換に使える規約をめざし検討をおこなった。基本
的にはＨＬ７に準拠したものであるが、ＭERIT−９をはじめとする関係規約との調整および、すでにＪＡＨ
ＩＳより発行されている「臨床検査データ交換規約」との共通部分の整合性を考慮し、メッセージ交換委
員会を中心にとりまとめたものである。
本規約に基づくインタフェースが多くのシステムに実装され、処方データ交換標準化に貢献できれば幸いである。

保健医療福祉情報システム工業会
メッセージ交換委員会
部門システム委員会

2003年 2月＜＜

告知事項 ＞＞

本規約は関連団体の所属の有無に関わらず、規約の引用を明示することで自由に使用することができるものとします。ただし一部の改変を伴う場合は個々の責任において行い本規約に準拠する旨を表現することは厳禁するものとします。
本規約ならびに本規約に基づいたシステムの導入・運用についてのあらゆる障害や損害について、本規約作成者は何らの責任を負わないものとします。ただし、関連団体所属の正規の資格者は本規約についての疑義を作成者に申し入れることができ、作成者はこれに誠意をもって協議するものとします。

Copyright©2002-2003
Copyright©2002-2003
Copyright©2002-2003

Copyright©2002-2003 JAHIS V1.1

日本ＨＬ７協会
日本医療情報学会ＭＥＲＩＴ−９研究会
保健医療福祉情報システム工業会

i

目

次

1．

はじめに

１

2．

HL7概要

２

3．

主な用語

３

4.

処方データ交換規約の対象範囲

４

5．

処方依頼メッセージ構文

５5．1

HL7メッセージについて

５5．2

処方依頼(OMP/ORP)

５5．3

患者情報照会(QRY/ADR)

７

5．4

オーダ状況照会(OSQ/OSR)

８

関連情報詳細９6．1

メッセージ区切り文字

９

6．2

データ型

１１

6．3

数量/タイミング定義

２１

6．4

HL7以外のテーブル

２７

関連セグメント詳細

２８

7．1

MSH メッセージヘッダーセグメント

２８

7．2

NTE 注釈・コメントセグメント

３３

7．3

PID 患者識別セグメント

３５

7．4

PV1 来院情報セグメント

４２

7．5

AL1 患者アレルギー情報セグメント

４７

7．6

ORC 共通オーダーセグメント

４９

7．7

RXO 処方オーダーセグメント

６２

7．8

RXR 投薬経路セグメント

６９

7．9

MSA メッセージ識別セグメント

７１

6．

7．

7．10 ERR エラー情報セグメント

７３

7．11 QRD 問合せ定義セグメント

７４

付録．

メッセージ使用例

Copyright©2002-2003 JAHIS V1.1

７８ii

1. はじめに本規約の検討は、国内の処方データ交換事例から、共通部分および使用頻度の高い項目を抽出し、標準のデータ項目をまとめることから始めた。 検討を開始した時点では、まだＨＬ7に準拠の方針は固まっておらず、レコードフォーマットを共通化する。
1998年７月に日本ＨＬ７協会が設立され、日本国内でもＨＬ7によるデータ交換標準化の機運が高まり、本規約も将来的に広く使われる規約をめざすためと、処方以外のデータ交換との整合性を考慮し、ＨＬ
7準拠で検討を進めることとした。
本規約の検討にあたっては、国内のデータ交換事例から抽出したデータ項目と、ＨＬ7のメッセージの対応づけを行い、使用するフィールドを明確にした。 規約の記述にあたっては、ＨＬ7 Ver.2.3 日本
語版より処方関連部分をとりまとめ、不足する項目および日本の実情に合わないテーブルについては、
追加・差し替えを行い、解釈が曖昧になりやすい部分については、処方データに限定した注釈を加えた。また、メッセージ使用例については、日本の処方例をもとにメッセージ例を作成し、付録として追加した。 さらに HL7 Ver.2.3.1で変更になった部分について変更を加え、「JAHIS 処方データ交換規約
Ver.1.0」として発行した。
その後、HL7 Ver.2.4が発行されたことに伴い、Ver.2.4に対応した「JAHIS 処方データ交換規約
Ver.1.1」を発行した。
本規約の検討にあたっては、日本医療情報学会ＭＥＲＩＴ−９研究会との協調において、諸先生方から貴重なご助言をいただく事ができた。 また、「ＭＥＲＩＴ−９ 処方オーダ Ver.1.1」で規定されている、
剤形・単位・頓用指示・追加用法・処方区分の各テーブルについては、本規約においても採用させていただいた。 資料のご提供およびご助言をいただいた関係団体と諸先生方に感謝いたします。

Copyright©2002-2003 JAHIS V1.1

1

2. HL7概要(HL7とは)ヘルスケア関連情報の電子的データ交換のための応用規約であり、また、規約の制定団体の名称でもある。異なるベンダーの異なるシステム間のインターフェースとなる標準的書式である。本規約はOSI手順の第7層であるアプリケーション層に由来してHL7と名付けられたものであり、物理的規約は制定していない。
(なぜ標準化なのか)
基本的目的は増大する医療費の削減と医療の質の向上である。それは医療費の効率化のためコスト計算を明らかにするとともにヘルスケア品質の計測化による質の向上を目指すものである。
1960年代は単独処理で他との接続は必要なかったが、1970-85年にかけ部門システムとの接続が始まり、1985年以降様々なシステム間で接続が要望され、インターフェイス標準化の必要性が増大している。
病院単独から病院の統廃合も手伝ってヘルスケア共同体が拡大し、今日のヘルスケアは病院を中心に事務所、製造業、販社、支払者、診療所、政府機関が一体となった情報連携が必要で、かつ患者を取り巻くすべての部門とのトランザクションが通信で出来ることが必要となってきた。
技術の進歩、通信環境の進歩、場所の多様化、システムの巨大化が背景となり標準化されたデータ交換が可能であり不可欠となっている。
(HL7の歴史)1987年3月ペンシルバニア大学病院にて初会合、3-4ヶ月かけV1.0のドラフトができた。V1.0は1987年10月に発表され全体的なインターフェイスと入退院、オーダーエントリー、オーダー照会がふくまれる。患者会計の重要性が認識されていたが時間的制約で含まれなかった。以後1988年9月にV2.0、1990年にV2.1が発表された。1991年にはANSIのメンバーとなり、1992年にはANSI HISPP(Healthcare Informatics Standards
Planning Panel)の起草メンバーとなった。1994年にはANSIに認知された標準化組織となった。1994年末V2.2を発表し、最新版は1997年のV2.3である。さらにオブジェクト指向のV3.0が検討されている。
(HL7の組織)
HL7は会員制の組織であり会員は意見を反映させることができる。即ちHL7の情報源は会員の意見である。HL7の使用は会員であることを問わないが、HL7からのタイムリーな情報提供はない。理事会と作業グループがあり会員が参加できるし、作業グループに参加してなくても案に対して意見を述べることができる。また医療提供者顧問と工業会顧問のアドバイスを受ける。会員には、医療機関、コンピュータ会社、
医療関連会社、コンサルタント会社などがいる。また米国以外の国々の会員もいる。会員数は増加しており現在1500を越える会員数である。
(HL7プロトコル概要)
HL7はOSI第7層(アプリケーション層)での規約であり、データの型や要素、要素の構成やグループ、コードや用語、機密保持、管理規約などが定義される。HL7の包含する対象はV2.1では入退転院、患者基本情報、オーダー、検査報告、財務的処理、照会などである、さらにV2.2では、マスターファイル更新、V2.3
では、文書管理、予約、患者紹介、患者看護が追加された。
HL7の基本的体系は、メッセージタイプID付電文で構成され、複数セグメントで論理的意味をなすメッ
セージとなる。メッセージ(例えば入退転)は、具体的なきっかけとなる事象(例えば患者入院)により、データ構成要素(例えば患者名)からなるセグメント(例えば患者属性)の集合として構成される。メッセージ
交換は会話的にもバッチ処理的にも行われるものである。
(他の標準化組織との関連)
ASTM E1238検査システム間データ交換をもとに検査関連をまとめているので互換性がある。HL7を含め た 標 準 化 団 体 の 調 和 を 図 る た め ANSI で は 、 HISPP ( 現 HISB) 部 門 を 設 置 し 、 NCPDP( 薬 剤 情 報 ),ACR/NEMA(画像DICOM), IEEE MEDIX(医療情報記述交換), ASTM(検査関連臨床情報交換), ASC X12(会計保険情報の電子データ交換)と協調している。また国際的にもCEN-TC251(European Committee forStandardization Technical Committee 251)などと連絡を取り合っている。これら協調は重複の縮小、標準化のスピードアップ、コスト低減、国際関係の促進、政府によらない開発、販売者の共同作業の促進などのため必要なことである。
(日本HL7協会他国内の標準化組織との関連)
日本HL7協会が1998年7月に設立された。日本国内におけるHL7の普及に大きく貢献することが期待されます。

Copyright©2002-2003 JAHIS V1.1

2

3. 主な用語
トリガーイベントTrigger Event： メッセージの交換を始めるきっかけとなる事象をトリガーイベントという。HL7は、実際のヘルスケア現場でのシステム間データ通信の必要性に応じた事象を受けて書かれている。例えば、｢患者が入院｣というトリガーイベントは、その患者についての情報を幾つかの他のシステムに伝送する必要を引き起こすであろう。それらメッセージ型とトリガーイベ
ントコードは一対多の関係である。
メッセージMessage： 1つのメッセージは、システム間で転送されるデータの意味のある最小単位である。これは定義された順序のセグメントの集合からなる。各々のメッセージはその目的を定義するメッセージタイプを持つ。例えば、ADT(入退転)メッセージタイプはあるシステムから別なシステムに患者の入退転データの一部を伝送するために使用される。各々のメッセージに含まれる3文字のコードがそのタイプを識別する。
セグメントSegment(record)： セグメントはメッセージの1つの側面について記述するもので、データ要素(フィールド)の論理的集合体である。各々のセグメントはセグメントIDと呼ばれる3文字のコードで識別される。メッセージ中のセグメントは必要なものと任意のものとある。それらはメッ
セージ中一回だけ出現する場合と繰り返しが許される場合とある。たとえば、単一のオーダー関
連情報はOBRセグメントとして送られ、検査関連情報は別のOBXセグメントとして送られることがある。
フィールドField： 診断名などといったセグメント中の一つの意味付けされた属性であり、フィールドには基本属性をさらに詳細に記したデータ成分の集合を含むことがある。
フィールド成分Field components： フィールドへの入力要素として、成分という識別可能な部分を含むことがある。たとえば患者名は、姓、名、ミドルネーム(イニシャル)として記録されるが、それぞれの要素は別個のエンティティーであり、成分区切り文字により分離される。成分はさらに副成分で構成される場合もある。
メッセージ区切り文字Message Delimiters： メッセージを構成するにあたっては、定義された文字が使用される。それらは、セグメントターミネータ、フィールドセパレータ、成分セパレータ、副成分セパレータ、反復セパレータ、そしてエスケープ文字である。
依頼者Placer(Requestor)：

処方を依頼する人のことである。処方指示を出す医師が該当する。

実施者Filler(Producer)： 依頼された処方を実施する(オーダーに応える)人または部門のことである。調剤を行う薬剤師および、入院患者の服薬を支援する看護提供者が該当する。

Copyright©2002-2003 JAHIS V1.1

3

4. 処方データ交換規約の対象範囲

1.OMP/ORP(ORM/ORR)

オーダリング

2.QRY/ADR
薬剤部門

システム
3.OSQ/OSR

メッセージとトリガーイベント

メッセージ定義

ﾒｯｾｰｼﾞﾀｲﾌﾟ HIS⇔薬剤

１．処方依頼情報通知 OMP/ORP

OMP→

トリガーイベントｲﾍﾞﾝﾄﾀｲﾌﾟ

処方オーダメッセージ

O09/O10←ORP (HL7 Ver2.4 4.13.1,4.13.4)
２．患者情報照会

QRY/ADR←QRY 患者問合せ
ADR→

３．処方依頼情報照会 OSQ/OSR

A19(HL7 Ver2.4 3.3.19)←OSQ オーダ状態問合せ
OSR→

Q06

(HL7 Ver2.4 4.4.3)

本規約では上記のメッセージタイプ及びイベントタイプをサポートし、ＱＲＹ等は標準的に使用する範囲を規定する。
メッセージの概要①処方指示（OMP/ORP）
処方オーダ情報をOMPメッセージで通知する。それに対する応答をORPメッセージで返す。
②患者情報照会（QRY/ADR）
患者情報をQRYメッセージで問合せる。それに対する応答をADRメッセージで返す。
③オーダ状況照会（OSQ/OSR）
オーダの状況をOSQメッセージで問合せる。それに対する応答をOSRメッセージで返す。

Copyright©2002-2003 JAHIS V1.1

4

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

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

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

5.2 処方依頼情報通知(OMP/ORP)
処方指示は,RXO,RXCおよびRXRセグメントを詳細セグメントとして備えたORM／ORRメッ
セージを使用するか、下記のようなOMP／ORPメッセージを使用することができる。ただし、ORM／ORRメッセージはV2.3.1以前との互換性のために保持されているので、本規約では
OMP／ORPの使用を推奨する。

OMP 処方オーダメッセージ（イベントO09）
は未使用セグメント

OＭＰ
MSH[{NTE}][PID[PD1][{NTE}][PV1[PV2]]
[{IN1
[IN2]
[IN3]
}]
[GT1]
[{AL1}]]{ORC
RXO[{NTE}]
{RXR}
[
{RXC}

Copyright©2002-2003 JAHIS V1.1

Pharmacy/treatmentOrderMessage(HIS→薬剤部門)
Message Header
Notes and Comments (for Header)
Patient Identification
Additional Demographics
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit - Additional Info
Insurance
Insurance Additional Info
Insurance Add’l Info - Cert.
Guarantor
Allergy Information

Common Order
Pharmacy/Treatment Order
Notes and Comments (for RXO)
Pharmacy/Treatment Route
Pharmacy/Treatment Component

5[{NTE}]

Notes and Comments (for RXC)OBX[{NTE}]

Observation/Result
Notes and Comments (for OBX)

]
[
{

}
]
[{FT1}][BLG]

Financial Transaction
Billing Segment}
注:[ ]は省略可能、{ }は繰返し可能をを示す。

MSHはオーダの出力単位(メッセージ)に一つ必須である。
PIDは1患者の一連のオーダに1個必須である。オーダがまとめて伝送される場合MSHがオー
ダの区切りとなる。
AL1セグメントはアレルギー情報が無い場合は省略する。
ORCは1患者の個々の詳細オーダー(RXO)毎に1個必須である。

ORP

処方オーダ確認応答メッセージ（イベントO10）
は未使用セグメント

ORP
MSH
MSA
[ERR]
[{NTE}][[PID[{NTE}]
]
{
ORC
[
RXO
[{NTE}]{RXR}[{RXC}][{NTE}]]}]
注:

Description
Message Header
Message Acknowledgment
Error
Notes and Comments(forResponse

Patient Identification
Notes and Comments (for Patient ID)

Common Order
Pharmacy/Treatment Order
Notes and Comments (for RXO)
Pharmacy/Treatment Route
Pharmacy/Treatment Component
Notes and Comments (for RXC)

[ ]は省略可能、{ }は繰返し可能をを示す。

Copyright©2002-2003 JAHIS V1.1

(HIS←薬剤部門)

6

Header)5.3 患者情報照会(QRY/ADR)
薬剤の配送先照会は問合わせメッセージ(QRY)を用い、応答はADTﾚｽﾎﾟﾝｽﾒｯｾｰｼﾞ(ADR)を使用する。その場合のセグメントと構文規則は以下のとおりである。

QRY/ADR – 患者情報の照会

イベント（A19）

問合せ時の患者情報を照会し、その結果を返すイベントである。
薬剤部門においては、薬剤の配送先確認のため、入院患者の入院病床を照会する。

QRY/ADR

患者情報照会メッセージは未使用セグメント

QRY
MSH
QRD
[ QRF ]

PatientQuery
Message Header
Query Definition
Query Filter(薬剤部門→HIS)

ADR
MSH
MSA
[ERR]
[QAK]
QRD

ADT Response
Message Header
Message Acknowledgment
Error
Query Acknowledgment
Query Definition
Query Filter(薬剤部門←HIS)[ QRF ]{[ EVN ]PID
[PD1]
[ {ROL} ][ {NK1} ]PV1[ PV2 ]
[ {ROL} ][ { DB1 } ][ {OBX} ][ {AL1} ][ {DG1} ][DRG][ {PR1[{ROL}]}][ {GT1} ][{IN1[ IN2 ][ IN3 ]}]
[ ACC ][ UB1 ][ UB2 ]}[ DSC ]

Copyright©2002-2003 JAHIS V1.1

Event Type
Patient Identification
Additional Demographics
Role
Next of Kin /Associated Parties
Patient Visit
Patient Visit - Additional Info.
Role
Disability Information
Observation/Result
Allergy Information
Diagnosis Information
Diagnosis Related Group
Procedures
Role
Guarantor

Insurance
Insurance Additional Info.
Insurance Add’l Info - Cert.

Accident Information
Universal Bill Information
Universal Bill Information
Continuation Pointer

7

注:[ ]は省略可能、{ }は繰返し可能をを示す。

5.4 処方依頼情報照会(OSQ/OSR)
OSQ/OSR – オーダ情報の照会

イベント（Q06）

OSQ/OSR オーダ情報の照会／応答メッセージは未使用セグメント

OSQ
MSH
QRD
[ QRF ][ DSC ]

Order Status Query
Message Header
Query Definition
Query Filter
Continuation Pointer

OSR
MSH
MSA
[ERR]

[ QRF ]

Order Status Response(薬剤部門←HIS)
Message Header
Message Acknowledgment
Error
Notes and Comments (for Header)
Query Definition
Query Filter[{NTE}]

Patient Identification
Notes and Comments (for Patient ID)[{NTE}]
QRD(薬剤部門→HIS)

[
[PID
]
{
ORC
[
RXO
[{NTE}]{RXR}][{NTE}][{CTI}]
}
]
[DSC]
注:

Common Order
Pharmacy/Treatment Order
Notes and Comments (for RXO)
Pharmacy/Treatment RouteNotes and Comments (for Detail)Clinical Trial Identification

Continuation Pointer[ ]は省略可能、{ }は繰返し可能をを示す。

Copyright©2002-2003 JAHIS V1.1

8

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

フィールドセパレータ
成分セパレータ
反復セパレータ
エスケープ文字副成分セパレータ

推奨値<cr>
hex 0D
|
^
~
\
&

用法
セグメント記録を終了する。この値は、導入者によってて変えることができない。
セグメント内で2個の隣接データフィールドを分離する。
データフィールド内の隣接成分を分離する。
データフィールド内の反復出現するのを分離する。
TXとFTフィールドに対するエスケープ文字。
データフィールド内の隣接副成分を分離する。

Segment Terminator セグメントターミネータ
セグメント区切りは毎セグメントの最終文字である。それはいつもASCIIの改行文字で(16進0D)である。
Field Separator フィールドセパレータ
HL7のフィールドセパレータはセグメント内の隣接したデータフィールドを分離する。それはまたセグメントIDを最初のデータフィールドから分離する。フィールドセパレータを表す値
は各メッセージ毎に違えて定義してもよい。MSHセグメントの第4文字はそれがどんな文字であっても、そのメッセージ中はフィールドセパレータとして働く。特別な理由がないかぎり、どのアプリケーションもフィールドセパレータとして“ | ”を用いることを推奨する。
Component Separator 成分セパレータ
成分セパレータは、あるデータフィールドの隣り合った成分を区別するセパレータのために使われる。その使用法は、関連するデータフィールドの記述に述べられている。成分セパレータはを表現するキャラクタは、MSHセグメントのコード化文字の最初のキャラクタとして各メッセージ毎に決められる。特別の理由がないかぎり成分セパレータとして“ ^ ”を推奨する。
Repetition Separator反復セパレータ
反復セパレータは、反復の認められたデータフィールドにおいて、複数の発生事象を区切るため用いられる。反復セパレータを示す文字はMSHセグメントのコード化文字の二番目の文字で示される。特に定めのない限り反復セパレータとして“ ~ ”が用いられる。
Subcomponent Separator副成分セパレータ
副成分セパレータはあるデータフィールドの隣接する副成分を区切るのに用いられる。その使用は関連するデータフィールドに説明されている。副成分セパレータとして出現する文字
はMSHセグメントのコード化文字データフィールドの第四文字に指定される。特に定めのない限り副成分セパレータとして“ & ”が用いられる。
Escape Character エスケープ文字
テキストフィールド(TXまたはFT型)では、エスケープ文字のような他の特殊文字も許可されます。TXまたはFTフィールドで許可されるどのような文字も、エスケープ文字とすることができる。エスケープ文字を表している単一の文字は、MSHセグメントのコーディング文字データフィールドの3番目の文字として指定する。このフィールドはオプションです。エスケー
プ文字を使う必要のないアプリケーションではこの文字は省略できます。しかし、副成分セパレータがメッセージの中で使われるならば、存在せねばならない。他に考慮する必要がな
ければ、エスケープ文字として“ \ ”を使用することを推奨する。
注：区切り文字で囲まれる文字列中でASCII以外の文字セットを使用の場合、区切り文字に先Copyright©2002-2003 JAHIS V1.1

9

立ちASCII文字セットにもどすこと。もし区切り文字が検出された場合は文字セットはASCII
へリセットしたものとみなす。

Copyright©2002-2003 JAHIS V1.1

10

6.2 Data types データ型
図 2-2. HL7 data types(抜粋)Data type
Alphanumeric
ST
TX
FT
Numerical
CQ
NMSI
Identifier
ID
IS

Data Type Name
StringText data
Formatted text
Composite quantity with units
Numeric
Sequence ID

HD

Coded values for HL7 tables
Coded value for user-definedtablesHierarchic designator

EI

Entity identifier

PL

Person locationPT
Date/TimeDT
TS
Code Values
CE

Notes/Format<quantity (NM)> ^ <units (CE)>

Processing type<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>Used only as part of EI and other data types.
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^<universal ID type (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)>

DateTime stamp

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

Coded element<identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system(ST)><ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit
scheme employed (ID)> ^ < assigning authority (HD)><ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme
employed (ID)> ^ < assigning authority (HD) )> ^ <identifier type code (IS)>^ < assigning facility (HD)<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)> ^ <identifier check digit (ST)> ^ <code identifying
the check digit scheme employed (ID)> ^ <identifier type code (IS)> ^<assigning facility (HD)>CK

Composite ID with check digit

CX

Extended composite ID withcheck digit

XCN

Extended composite ID
number and name

Generic
CM

Composite

No new CM’s are allowed after HL7 Version 2.2. Hence there are no new
CM’s in Version 2.3.

Demographics
XAD

Extended 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)> ^ <county/parish code (IS)> ^<census tract (IS)><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) >[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)>

XPN

Extended person name

XTN

Extended telecommunications
numberTime Series:
TQ

Timing/quantity

For timing/quantity specifications for orders, see Chapter 4, Section 4.4.
<quantity (CQ)> ^ <interval (*)> ^ <duration (*)> ^ <start date/time (TS)> ^<end date/time (TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^<conjunction (ID)> ^ <order sequencing (*)>

* for subcomponents of these elements please refer to the definition in the text.

Data types データ型解説(抜粋)ST 文字列データ
文字列データは、左詰めにされこれに空白がうしろに続いてもよい。任意の表示可能な(印刷Copyright©2002-2003 JAHIS V1.1

11可能な)ASCII文字(20から7Eまでの16進値)である。例：|almost any data at all|TX テキスト・データ
文字列データは、使用者に対しターミナルまたはプリンターによって表示するためにある。
文字列に先行空白を挿入した方が使用者が見やすいということもあるので、文字列は必ずしも左詰めにするわけではない。この種のデータは表示することが目的なので、表示装置を制御するためのエスケープ文字シーケンスを含むことがある。先行空白文字を挿入し、後書き
空白を取り除くとよい。 例：| leading spaces are allowed.|
TXデータは表示するためにあるので、反復区切文字をTXデータ・フィールドで使うと、それは一連の反復行がプリンターまたはターミナル上に表示されることを意味する。したがって
反復区切文字は、パラグラフ・ターミネータまたはハード・キャリッジ・リターンとみなされる。(そのテキスト内にCR/LFが挿入されたように表示される)。
受信システムでは、任意の大きさの表示ウィンドウに合わせるためテキストを繰り返し区切
り文字間でワードラップするが、反復区切文字で始まる行はすべて新たな行になる。
FT 書式付テキスト・データ
このデータ型は、書式を埋め込み追加することで文字列データ型を拡張したものである。これらの書式は固有であり、フィールドの使用環境から独立している。文字列データ(ST)フィー
ルドとFTフィールドとの違いは、長さが任意(65kまで)であることと、エスケープ文字で囲まれた書式を含むことである。 例：|\.sp\(skip one vertical line)|
CQ 単位付き合成量<数量>^<単位>
第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+.
NM 数字
ASCII数字列として表記される数字は、オプションの先行符号(＋または−)、数字、そしてオプションの小数点から構成される。符号がない場合、その数値は正数であると仮定される。
|-123.792|
小数点がない場合、その数値は整数であると仮定される。 例：|999|
先行ゼロまたは小数点の後の後書きゼロは無意味である。01.20と1.2という2つの数値は同一である。オプションの先行符号(＋または−)およびオプションの小数点(．)を除いては、数字以外のASCII文字は許されない。したがって、値 <12 は、文字列データ型としてコード化しなければならない。
SI シーケンスID
NMフィールド形式の正整数。このフィールドの使用方法は、それが現れるセグメントとメッ
セージを定義している章で定義する。
ID

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

IS 使用者定義コード化値
このフィールドの値は、使用者定義テーブルから引用され、STフィールドの書式規則に従う。
ISデータ型に関連したHL7テーブル番号があるものとする。例えば事象理由コードである。
HD 階層的デジグネータ
Components: <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>
HDデータタイプは他のデータタイプ構成要素の一部として用いられる。それは、ローカルで定義されたアプリケーション識別子や公に割当てられたUIDのいずれかとして使用される。
HDは、HL7の初期の版でISデータ型を使用したフィールドの中で使用される。その場合、第一成分のみである。HDデータ型の第1の成分が存在する場合、第2と第3の成分はオプションである。第3成分が存在する場合、第2成分も存在せねばならない。

Copyright©2002-2003 JAHIS V1.1

12

HDの第2の成分、汎用ID(UID)は、第3の成分、汎用IDタイプ(UIDタイプ)によって定義される書式の文字列である。UIDはUIDタイプ内で時間が経過しても一意的になるよう定義されている。UIDタイプによって定義された各UIDは、UIDを構築する特に列挙された計画のうちの1つに属さなければならない。UID(第2の成分)は、第3の成分によって定義された汎用ID構文規則に従わなければならない。
HL7表 0301−汎用IDタイプ
Value
DNS
GUID
HCD
HL7
ISO
L、M、N
ランダム

UUID
x400
x500

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

A locally defined HD in which the middle component is

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 alocally 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)> S)
エンティティ識別名は、識別子の指定されたシリーズ内の与えられたエンティティを定義する。
指定されたシリーズ、すなわち割り当て権限は、成分2〜4によって定義される。割り当て権
限は階層的指名者データ型(HD)である。しかし、それは3つの個別の成分としてEIデータ型の中で定義され、これは通常単一の成分として定義されるのと異なる。これはいくつかの既存のデータ分野の成分としてのEIの使用と下位互換性を維持するためである。そうでなければ、
成分2〜4はセクション2.8.18｢HD階層的指名者｣の中で定義される。階層的指名者は、与えられたHL7導入を通じて一意的である。
第1成分、エンティティ識別名は、識別子のシリーズ内で一意的であるよう定義され、割当て権限によって作成され、これは階層的指名者によって定義され成分2〜4で表わされる。
PL

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

Copyright©2002-2003 JAHIS V1.1

13

(IS)> ^ <看護単位(IS)> ^ <病室(IS)> ^ <ベッド(IS)> ^ <場所の詳細(ST)> ^ <場所の状態(IS)>。
PT 処理タイプ
Components: <processing ID (ID)> ^ <processing mode (ID)>
このデータ型は、HL7アプリケーションがHL7メッセージの処理をするべきか否か示す。
処理IDで、メッセージが生成、訓練あるいはシステムデバッギングかどうか定義する値。有効な値については｢HL7テーブル0103−処理ID｣を参照すること。処理モ−ドで、メッセージが文書累積の処理あるいはイニシャルロ−ドの一部かどうか定義する。有効な値については｢HL7テーブル0207−処理モ−ド｣を参照すること。
DT 日付
常に書式YYYYLLDDで表記、桁数により精度が規定される。 例：|19880704|
TS タイム・スタンプ
日付と時間を含む、イベントの正確な時間から成る。書式はつぎのようである。
YYYYLLDD[HHMM[SS[.SSSS]]][+/-ZZZZ]^<精度>
タイム・スタンプの日付部は日付フィールドの規則に従う。時間部は時間フィールドの規則に従う。表記する桁数により精度が規定される。すなわち、誕生日として使われるとき、HHMM
部が省略されれば日付であり、HHMM部を0000とすると、まさに明けようとしているその日の真夜中(0時0分)になる。HL7コード化規則の中で使われる特定のデータ表記はISO8824-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 zone of
the sender.
|198807050000^D| Same as prior example, but precision extends only to the day. Could be used for abirthdate.(＝|19880705|)
HL7規格では、すべてのシステムが日常的に時間帯オフセットを送るよう強く推奨するが、強制はしない。HL7システムではすべて時間帯オフセット受け入れる必要があるが、その実装はアプリケーションに任される。多くのアプリケーションの場合、関心ある時間はその発信者の現地時間である。たとえば、東部標準時間帯にあるアプリケーションが12月11日午後11:00にサンフランシスコで入院が発生したという通知を受けた場合、その入院を12月12日ではな
くて(現地時間の)12月11日に発生したものとして扱うのがよい。
この規則における例外は、臨床システムが、互いに近くに存在しながら時間帯の異なる複数の病院で収集された患者データを処理する場合である。そのようなアプリケーションは、そのデータを共通の表記に変換することがある。同じような問題は、サマータイムとの切り替
え時にも発生する。HL7は、情報の送信時に時間帯情報を含めるようにすることで対応する。
しかし、ここで検討した処理のどちらを受信システムが採用するかは指定しない。
CM 複合フィールド
他の有意データ・フィールドと組合せるフィールド。それぞれの部分は成分と呼ばれる。CM
フィールドの特定成分は、そのフィールド記述の範囲内で定義される。その他個別に識別される複合フィールドもあり、それについては以下に記述する。このデータ型の使用は発展的に解消し、独自のデータ型を新たに作成する予定である。
HL7フィールドの成分そのものが成分を含むHL7データ型である場合、その区切り文字は一ラ
ンク下位に落とされる。したがって、CEデータ型として示された成分は、<識別子&テキスト&コーディング方式名>としてコード化すべきである。HL7区切り文字は再帰的でないので、成分を含むHL7データ型は副成分となりえないことに注意。このレベルの詳細情報が必要な場
合、HL7データ型の各成分は、別々の副成分としてコード化することができる。この例に関しては、タイミング/数量データ型のオーダーシーケンス化成分にある実施者オーダー番号のコ
ード化方式を参照のこと。
CE コード化値
Components: <identifier識別子 (ST)> ^ <textテキスト (ST)> ^ <name of coding systemコーディン
グ方式名 (ST)> ^ <alternate identifier代替識別子 (ST)> ^ <alternate text代替テキスト (ST)> ^<name of alternate coding system代替コーディング方式名 (ST)>Copyright©2002-2003 JAHIS V1.1

14

例：|54.21^Laparoscopy^I9^42112^^AS4||F-11380^CREATININE^I9^2148-5^CREATININE^LN|
このデータ型は、コード、およびそのコードと関連するテキストを送る。この型は、次に述べる通り、代替成分を含め6個の成分を持つ：
識別子： 後ろの<text>によって参照される項目を一意に識別する文字列(コード)。異なる
コーディング・スキーマでは、異なる要素を持つ。
テキスト： 問題としている項目の名前または記述。たとえば、心筋梗塞とかX線撮影所見など。そのデータ型は文字列(ST)である。
コーディング方式名： コーディング方式には一意な識別子が割り当てられる。この成分
は、識別子成分内で使われているコーディング・スキーマを識別するのに役立つ。識別子成分とコーディング方式名成分の組合せは、データに対して一意なコードである。ここに指定されるコーディング方式の例は、ICD-9、ICD-10、SNOMEDなどである。各方式には一意な識
別文字列が与えられる。ここにHL7テーブルを使用する場合、HL7テーブル番号をnnnnとしHL7nnnnとして定義する。
代替成分： 3つの代替成分は、上記と同様、代替方式または現地コーディング方式を定義するためにある。代替テキスト成分が存在せず、代替識別子が存在すると、代替テキストはテキスト成分と同じであると解釈される。代替コーディング方式成分が存在しない場合、それはローカル定義の方式であると解釈される。
注記： このデータ型では2組の等価コードを表現しているが、それはCE型フィールドの反復とは意味が違っている。反復を用いる場合は、いくつかの明瞭なコード(明瞭な意味を持つコード)を送信するのが普通である。
CK チェック・ディジット付き複合ID
Components:<ID number ID番号 (NM)> ^ <check digitチェックデジット (NM)> ^ <code
identifying the check digit scheme employedチェックデジット方式 (ID)> ^ < assigning authority割
当権限者(HD)>
このデータ型は、たとえばPID-3-患者ID(内部ID)など、通常チェック・ディジットを含むフィールドで使われる。現場で、あるCKフィールドにチェック・ディジットを使っていない場合、第2、第3成分はNullである。
このデータ型のチェックデジットは、メッセージ処理システムが追加生成するわけではない。
それは、送信アプリケーション内で使われる識別番号に含まれる。送信アプリケーションが識別番号内にチェックデジットを含まない場合、この成分はnullとすべきである。
チェックディジット方式は、テーブル0061 − チェックディジット方式で定義する。
HL7表 0061
値
NPI
ISO
M10
M11

チェックディジットスキーマ

記述
米国プロバイダ識別子内のチェックディジットアルゴリズム
ISO 7064: 1983
Mod 10 アルゴリズム
Mod 11 アルゴリズム

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

Copyright©2002-2003 JAHIS V1.1

15

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 = 6
計算は以下の通り
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
上記以外のチェック・ディジットは、現地双方の取り決めにより使うことができる。
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)例：|1234567＾4＾M11＾ADT01＾MR＾University Hospital|
ID：CKデータ型と同様、ただしSTデータ型がNM・データ型の代わりに許可される。
チェックデジット：CKデータ型と同様、ただしSTデータ型がNM・データ型の代わりに許可される。このチェックデ
ジットはメッセージ処理で追加されるものではなく、送信アプリケーションの中で使用される識別番号の一部である。
送信アプリケーションが識別番号中にチェックデジットを含んでいない場合、この値はヌルであるのがよい。
識別子タイプコード：識別子のタイプに対応するコード。ある場合には、｢割当権限｣成分への修飾語としてこのコードを使用してもよい。
HL7表 0203 – 識別子型
値

説明

AM

アメリカンエクスプレス

AN

会計番号

BA

銀行口座番号BR

出生登録番号BRN

品種登録番号DI

ダイナーズクラブカード

DL

運転免許証番号

DN

医師番号

DR

ドナー登録番号DS

ディスカバーカード

EI

従業員番号

EN

雇用者番号

FI

施設 ID

GI

保証人内部識別子

GN

保証人外部識別子

HC

保険証番号

JHN

司法健康番号(カナダ)

LN

免許証番号

LR

その場所での登録 ID

Copyright©2002-2003 JAHIS V1.1

16

値

説明

MA

メディケイド番号MC

メディケア番号

MCN

マイクロチップ番号

MR

衣料記録番号MS

マスターカードNE

国内雇用者識別子

NH

国内健康プラン識別子

NI

国内固有個人識別子

NNxxx

国内個人識別子(xxx は ISO 表 3166 3 文字(アルファベット)国
コードである)

NPI

国内プロバイダ識別子

PEN

年金番号

PI

患者内部識別子

PN

個人番号

PRN

プロバイダ番号PT

患者外部識別子RR

鉄道引退番号

RRI

地域登録 ID

SL

州免許

SR

州登録 ID

SS

ソーシャルセキュリティ番号

U

不特定

UPIN

メディケア/HCFA 共通医師識別番号

VN

来院番号

VS

VISA

WC

WIC 識別子WCN

労働者組合番号XX

組織識別子

XCN 拡張複合IDと名前
Components: <ID numberID番号 (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)> ^ <assigningauthority割当て権限者 (HD)> ^ <name type code名前タイプコード(ID)> ^ <identifier checkdigitチェックデジット (ST)> ^ <code identifying the check digit scheme employedチェックデジッ
ト方式 (ID )> ^ <identifier type code識別タイプコード (IS)> ^ <assigning facility割当て施設(HD)>
コード値およびテキスト名により人物を識別するフィールド。第1成分は、第8の成分で示されるテーブルに従ったIDである。第2成分から第7成分は人物名を表すPNフィールドである。
第8成分は、第1成分で使われるソース・テーブルを指定する。特定の現場では、それぞれの現場でIDまたは名前を省略することができる。名前タイプコードについては、XPN−拡張人
名を参照。識別タイプコードは使用者定義テーブル0203−識別子タイプ｣を参照すること。

Copyright©2002-2003 JAHIS V1.1

17

例: |12372^RIGGINS^JOHN^""^""^""^MD^ADT1||12372||^RIGGINS^JOHN^""^""^""^MD||1234567＾Smith＾John＾J＾III＾DR＾PHD＾ADT01＾＾L＾4＾M11＾MR|
XAD

拡張住所
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)>^ <county/parish code郡/教区コード (IS)> ^ <census tract国勢調査標準地域 (IS)>例： |1234、Easy St.＾Ste. 123＾San Francisco＾CA＾95123＾USA＾B＾＾SF＾|
他の表示では町名を修飾する。例：Suite 555あるいは4階など。住所・タイプはオプションであり、HL7テーブル0190住所・タイプによって定義される。他の地理的な表示は国、バイオリージョン、SMSAなどを含んでいる。

XPN

拡張人名
Components: <family name姓 (ST)> ^ <given name名 (ST)> ^ <middle initial or nameミドルネー
ム(イニシャルも可) (ST)> ^ <suffix (e.g., JR or III) 接尾辞(たとえばJR) (ST)> ^ <prefix (e.g.,DR) 接頭辞(たとえばDR) (ST)> ^ <degree (e.g., MD) 学位(たとえばMD) (ST)> ^ <name type
code名前タイプ (ID) > ^ <name representation code名前表示コード (ID)>上にリストしたように、名前は複数のフリーテキスト成分から成る。送信システムは大文字と小文字の混合、またはすべて大文字を送ることができる。必要なら、受信システム側です
べて大文字に変換してもよい。名前型コードで法律上の名前や現地名などを示す。取りうる値はHL7テーブル0200名前タイプを参照。一般的に法的な名前は現在の既婚の名前と同じである。名前表現コードでは、データ項目によって提供される名前の表現を指示する。この成分
は受信者にヒントを提供する。それにより、なにが送られており、なにを表示できるかに関する選択を行うことができる。
例： |Smith^John^J^III^DR^PHD^L||日本^太郎^^^^^D^I~にほん^たろう^^^^^D^P~ NIHON^Tarou^^^^^D^A|
使用者定義表 0360 – Degree

学位

Value

Description

AAS

Associate of Applied ScienceAA

Associate of Arts 文系準学士

ABA

Associate of Business Administration

AE

Associate of Engineering

AS

Associate of Science

BA

Bachelor of Arts

BBA

Bachelor of Business Administration

BE

Bachelor or Engineering

BFA

Bachelor of Fine Arts

芸術学士

BN

Bachelor of Nursing

看護学士

BS

Bachelor of Science

理学士

BSL

Bachelor of Science – Law 理学法学士

BT

Bachelor of Theology 工学士

CER

Certificate

証明書

DIP

Diploma

卒業証書

DBA

Doctor of Business Administration

DED

Doctor of Education

Copyright©2002-2003 JAHIS V1.1

応用科学系準学士

経営学系準学士

工学系準学士

理系準学士

文学士

工学士

教育学博士

18

経営学士

経営学博士

ValueDescription

PharmD

Doctor of Pharmacy 薬学博士
工学博士

PHE

Doctor of Engineering

PHD

Doctor of Philosophy 哲学博士

PHS

Doctor of Science

理学博士

MD

Doctor of Medicine

医学博士

DO

Doctor of Osteopathy 整骨療法学博士

HS

High School Graduate

JD

Juris Doctor 法学博士

MA

Master of Arts

MBA

Master of Business Administration

MCE

Master of Civil Engineering

MDI

Master of Divinity 神学修士

MED

Master of Education

MEE

Master of Electrical EngineeringME

Master of Engineering

MFA

Master of Fine Arts

MME

Master of Mechanical EngineeringMS

Master of Science

MSL

Master of Science – Law

MTMaster of Theology 哲学修士

NG

Non-Graduate

SEC

Secretarial Certificate 秘書証明書

TS

Trade School Graduate

高校卒業

文系修士
経営学修士

土木工学修士

教育学修士
電気工学修士

工学修士

芸術修士
機械工学修士

理学修士
理学文学修士未卒業

職業学校卒業生

HL7表 0200 - Name type code 名前タイプコード (ID)
Value
A
L
D
M
C
Ｂ
P
S
T
Ｕ

Description
Alias Name 別名
Legal Name 法律名前
Display Name 表示名称
Maiden Name 旧姓Adopted Name 養子名
Name at Birth 誕生時の名前
Name of Partner/Spouse 同伴者／配偶者の名前（下位互換性維持のため）
Coded Pseudo-Name to ensure anonymity 匿名性を保証するための符号化された匿名
Tribal/Community Name 現地の／部族の／団体の名前
Unspecified 不特定

HL7表 4000 - Name representation code 名前表示コード (ID)
Value
I
A
P

Copyright©2002-2003 JAHIS V1.1

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

19

XTN

拡張電話番号
Components: [NNN国番号] [(999地域)]999局番-9999番号 [X99999] [B99999] [C any text] ^<telecommunication use cod通信使用コードe (ID)> ^ <telecommunication equipment type通信機器(ID)> ^ <email address電子メール (ST)> ^ <country code国番号 (NM)> ^ <area/city code地域市外局番 (NM)> ^ <phone number電話番号 (NM)> ^ <extension内線番号 (NM)> ^ <any text (ST)>
例： (415) 555-3210＾ORN＾FX＾
HL7表 0201 - Telecommunication use code 遠距離通信使用コード
Value
PRN
ORN
WPN
VHN
ASN
EMR
NET
BPN

Description
Primary Residence Number 主要な自宅番号
Other Residence Number 他の自宅番号
Work Number 勤務先番号
Vacation Home Number 別荘番号
Answering Service Number 留守番電話応答サービス番号
Emergency Number 緊急番号
Network (email) Address ネットワーク(電子メール)アドレス
Beeper Number ポケットベルの番号

HL7表 0202 - Telecommunication equipment type 遠隔通信機器タイプ
Value
PH
FX
MD
CP
BP
INTERNET
X.400

Description
Telephone 電話
Fax ファックス
Modem モデム
Cellular Phone 携帯電話
Beeper ポケットベル
Internet Address: Use Only If Telecommunication Use Code Is NET イン
ターネットアドレス：通信使用コードがNETである場合のみ使用
X.400 email address: Use Only If Telecommunication Use Code Is NET
X.400電子メールアドレス：通信使用コードがNETである場合のみ使用

注：成分5〜9は、定形の形式で第1の成分の基本機能を反復する。そしてローカルおよび世界の電話番号の両方が表現できる。電話番号のための形式は、定形形式を使用することを推奨し、第1の成分は下位互換性のために残される。
TQ

タイミング数量サービスの実施時期とその頻度を指定する。 6.3 数量/タイミング定義を参照のこと。

Copyright©2002-2003 JAHIS V1.1

20

6.3 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連結 (ST)> ^ <order sequencingオー
ダーシーケンス化(CM)>
定義： 数量/タイミング(ORC-7,OBR-27)は、オーダーセグメントによって述べられたサービスがいつ，どのような頻度で行なわれるかを規定する手段を与える。それは、繰り返しを持つことができる複合多重成分フィールドである。すなわち複数回の数量/タイミング指定が、反復区切文字で分離されて表現される。数量/タイミング指定の成分を、以下に述べる。
Quantity component 数量成分 (CQ)
副成分： <数量&単位>
定義： 各々のサービス間隔で供給される必要があるサービスの量。たとえば2つの血液培養が4時間毎に得られるとすれば、数量が2である。もし3ユニットの血液が血液型を調べクロス
マッチされるならば、数量は3である。デフォルト値は1である。単位が要求される時、後ろの成分で限定するものによって明示され加えられる。
Interval component 時間間隔成分 (CM)
Subcomponents: <繰り返しパターン&明確な時間間隔>
定義：繰り返されるサービスの時間間隔を決める。デフォルトは1回のみである。第1副成分
は繰り返しパターンである。第2副成分はパターンが実行される明確な時間である。
Repeat pattern繰り返しパターン
使用者定義テーブル 4001 - Repeat pattern 繰り返しパターン
Q<integer>SQ<integer>MQ<integer>HQ<integer>DQ<integer>W
Q<integer>LQ<integer>J<day#>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である時、デフォルトである。

Meal Related Timings食事に関連付けられたタイミング<timing>A
P
I

Copyright©2002-2003 JAHIS V1.1

<timing>C("cum")<meal>

食前
食後
食間（例えば、この食事と次の食事の間、夕食と就寝の間）

21

<timing>
M
D
V

朝食
昼食
夕食

例：朝食前と夕食後： ACM,PCV

第一副成分は、スペースで分離することで繰り返すことができる。繰り返しで指定された副成分は、それぞれの論理和として解釈される。 例えば、
１日２回、１日置き： BID QOD
１日３回、月曜日・水曜日・金曜日： TID QJ135
この構成規則のため、繰り返し値にはスペースが含まれてはならない。もし、「１日２回、１日置き」のようなテキストを送信するときは、テキスト成分（第８成分）を使用する。
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継続時間成分
定義： サービスが開始された後で、サービスがどのくらい長く続くかを示す。デフォルトは、
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 月
オーダーで指定された時間間隔成分の繰り返し回数。
明記されている時間間隔と量で、合計の<整数>『DOSAGE』が蓄積されるまで。単位は、｢数量｣フィールドにおけると同じであると仮定される。
期間を特に定めない(不定)-同様にデフォルト

Start date/time component 開始日時成分 (TS)
定義：依頼者によって規定される。その場合それはサービスを開始する必要がある最も初めの日時を示す。多くの場合、しかしながら、開始日時は、オーダーレコード(たとえば、(緊急)-STAT)の他のフィールドによって示唆されるか、あるいは定義される。そのような場合、
このフィールドは空となる。
実施者サービスは、オーダーを受領後このフィールドの値をしばしば記録する。一方実施サービスの内部使用のために、開始日時を基礎にして終了時刻を計算する
End date/time component 終了日時成分 (TS)
定義：サービスを要求する人によってこの値が指定された時は、このフィールドはサービスが行なわれるべき最後日時である必要がある。ここで明示された時間までに行なわれなかったならば、それは行うべきではない。要求する人がこの値を満たすとは限らない。しかし実Copyright©2002-2003 JAHIS V1.1

22

施者サービスは、それが受け取る指示および実際の開始時間を基礎として、満たしてもよい。
終了日時の値に関係なく、サービスは、継続時間または終了日時によって指定された最も早い日時に終了すべきである。
Priority component 優先度成分 (ID)
定義： 要求の緊急度を述べる。次の値が提案される(優先度のデフォルトはRである)：
S
A
R
P
C
T
PRN

=
=
=
=
=
=
=

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

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

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

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

=
=
=
=
=
=

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

オーダーの連続指定の場合、これらの値は、先行オーダーから後に続くオーダー全部に対してタイミングの重要性を規定する。優先度成分を反復する場合はスペースで区切る。
Condition component 条件成分 (ST)
定義： これは、投薬条件を記述するフリー・テキストフィールドである。たとえば、｢PRNpain｣、｢血圧を110以下に保て｣など。このフィールドにテキストが存在する場合、投薬方法または投薬時期(あるいはその両方)を決定するため人間が見直す必要がある。
注（処方） 頓用指示を行う場合、時間間隔成分および優先度成分に次の表のテキストを条件成分に設定する。
表6.2.1 頓用指示（MERIT-9
投与条件
検査時
頭痛時
疼痛時
歯痛時
発熱時
胸痛時
腹痛時
不眠時
不安時
いらいら時
めまい時
かゆいとき
発作時
便秘時
下痢時
嘔吐時
咳き込み時
空腹時
血圧上昇時
亡尿時
多尿時

処方オーダ

Ver.1.1 表5.）

テキスト
PRNLTs
PRNheadache
PRNpain
PRNteeth pain
PRNfever or PRNfebrile
PRNchest pain
PRNabdominal pain
PRNinsomnia
PRNanxiety
PRNnervous
PRNdizziness or PRNvertigo
PRNitching
PRNattack
PRNcostipation
PRNdiarrhea
PRNvommiting
PRNcough
PRNhungry
PRNhigh BP
PRNauria
PRNpolyuria

Text component テキスト成分 (TX)
定義： 指示(オプショナル)の完全なテキストバージョン。

Copyright©2002-2003 JAHIS V1.1

23

PRN を設定し、

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

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

注記

とみなされ

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

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

図 4-1. オーダー・シーケンスの副成分
Subcomponent
1

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

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

2, 3

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

実施者オーダー番号6

シーケンス状態値

必須/オプション: 2つの副成分を使用する；何故なら依頼者オーダー番号は2つの副成分を持つためである。HL7では副成分の副成分は定義していない。
必須/オプション: 2つの副成分を使用する；何故なら実施者オーダー番号は2つの副成分を持つためである。HL7では副成分の副成分は定義していない。
許容状態値は、プロジェクト計画法で通常使用される形を持つ:<one of "SS", "EE", "SE", or "ES"> +/- <time>

Copyright©2002-2003 JAHIS V1.1

24

Subcomponent

Contains

7

最大繰り返し数

8,9

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

実施者オーダー番号､最後の2つの成分Notes
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を持つ。
次のシーケンス条件値の意味を説明する。
ES + 10M

SS - 10M｢OE1000&OrdEnt(先行オーダー)の終了時間 ＋ 10分｣により、後続オーダー、OE1001^OrdEnt(今回のオーダー)の開始時間を定義する；つまり、先行オーダーが終了してから10分後に、このオーダーを開始せよ、ということ。
｢先行オーダーの開始時間−10分｣によりこのオーダーの開始時間を定義する。つまり、先行オーダ
ーの10分前にこのオーダーを開始、ということ。

循環依頼者グループ
反復すべき循環オーダーがある場合、実行される最初のオーダーは、アスタリスク(＊)で始まる シーケンス条件値 を持つ。
Example:*FS+10M

第10成分に指定された条件を評価せずに、このオーダーを1回実行する。指定された外部オーダーの開始・終了日時がこの条件に合致したときのみその実行を繰り返す。このように指定すると、各サイクルでオーダーが1回反復される。

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

親子パラダイムを使用して、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グループとして送るこCopyright©2002-2003 JAHIS V1.1

25

とができる。この場合HL7では、グループ全体のオーダー状態をまとめて伝送する便利な手段がないので、4つのオーダーの個々の状態を別々に伝送するしかない。
オーダー状態の継承
キャンセル/中断/保留オーダー制御イベント：
ここでは、指定された先行オーダーが通常通り実行されることを想定している。したがって、
先行オーダーのキャンセル(あるいは中断、保留)は、後続の関連オーダーすべてを取り消す(あるいは中断する、保留する)ことを意味する。
参照されているオーダーが取り消された(あるいは中止、保留された)場合、今回のオーダーはそれと同じ状態を継承する。
保留の場合、先行オーダーの保留を解除することは、その該当オーダーも解除するという意味である。(したがって、そのオーダーは第10成分内の指定にしたがって実行することができる。)

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きっかりに採血し、ルーチンにしたがい結果を報告する。
（処方指示における使用例）^TID&PC^D3^20000827

一日3回毎食後服用３日分^DID&PCM,PCV^D14^20000827

一日2回朝夕食後服用14日分^QID&PC,HS^D28^20000827

一日4回毎食後および就寝前服用28日分^Q12H^D7^20000827

一日2回12時間毎服用7日分^PRN^^20000827^^PRN^PRNpain

痛い時服用

Copyright©2002-2003 JAHIS V1.1

26

6.4 ＨＬ７以外のテーブルの使用
当規約においては、ＨＬ7の標準定義テーブルおよびユーザ定義テーブル以外のテーブルを使用する事ができる。
ＨＬ7で定義されたテーブル以外のテーブルを使用する場合、当該テーブルを規定している規約を明らかにする必要がある。要素として <name of coding system> を有するデータタイプ
においては、ここにテーブルを規定した規約をあらわす略号を設定する。
当規約においては、次の略号を使用するものとする。
MR9P : MERIT-9 処方オーダ Ver 1.1
JHSP : 当規約で規定したことを示す

Copyright©2002-2003 JAHIS V1.1

27で規定されている事を示す

7. 関連セグメント詳細
7.1 MSH - Message Header Segmentメッセージ・ヘッダ・セグメント
MSHセグメントは、メッセージの構文の目的、発信源、宛先、特性を定義する。
HL7属性表
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
VID
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

Y

MSH-Message Header メッセージヘッダ
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 準拠宣言ID

NOTE

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

MSHフィールド定義
MSH-1 Field Separator フィールド区切文字 (ST) 00001
定義： セグメントIDと最初の実フィールド(MSH-2-コード化文字)間のセパレーター。そのようなセパレータとしての他に、残りのメッセージでセパレータとして使う文字を定義する。
推奨値は | (ASCII 124)である。
MSH-2 Encoding Characters コード化文字 (ST) 00002
定義： 次の順番で並べられた4文字、つまり、成分セパレータ、反復セパレータ、エスケー
プ文字、副成分セパレータ。推奨値は ^~\& (ASCII 94,126,92 and 38) である。メッセージ区
切文字の解説を参照。
MSH-3 Sending Application 送信アプリケーション (HD) 00003
定義： 送信アプリケーションを識別するために用いる。

Copyright©2002-2003 JAHIS V1.1

28

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
定義： セキュリティの実装に関する情報であるが、その使用法は未定である。
MSH-9 Message Type メッセージ型 (CM)Components:

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

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

Description

ADR
ORM

ADT response 患者管理(ADT)応答
Order message オーダーメッセージ

ORR

Order acknowledgment message

OSR

オーダ肯定応答メッセージ
Order status query オーダ状況問合せ
Order status response オーダ状況応答

QRY

Query, original Mode

OSQ

問合せ

HL7表 0003

Event typeイベント型 (処方関連のみ掲載)

Value

Description

A19
O01

QRY/ADR - Patient query 患者の問合せ
ORM – Order message オーダーメッセージO02

ORRーOrder response

O09

一般オーダ応答メッセージORMに対する応答
OMP – Pharmacy/treatment order 薬剤／処置オーダ

O10

ORP – Pharmacy/treatment order acknowledgment 薬剤／処置オーダ受諾応答

Q06

OSQ/OSR - Query for order status オーダ状況の問合せ

注（処方処方指示メッセージ：OMP^O09
患者情報照会メッセージ：QRY^A19
オーダ状況紹介メッセージ ：OSQ^Q06

応答： ORP^O10
応答： ADR^A19
応答： OSR^Q06

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

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

Copyright©2002-2003 JAHIS V1.1

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

29

HL7表 0207 - Processing mode 処理モード
Value
A
R
I
T

Description
Archive アーカイブ
Restore from archive アーカイブからの復元
Initial load 初期ロード
Current processing, transmitted at intervals (scheduled or on demand)
現在の処理、とびとびに転送される（計画的又は要求に応じて）Not present (the default, meaning current processing)
存在しない（デフォルト、すなわち現在の処理）

not present

注（処方） 処方データにおいては、第二成分（処理モード）は使用しない。
第一成分（処理ＩＤ）で受信側のシステムの動作を示す。
Ｄ： 送信されたデータを無視する
Ｐ： 通常の動作を行う
Ｔ： 送信されたデータにより調剤は行うが、統計には反映しない

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

Description

2.0

Release 2.0 リリース2.0

September 1988

2.0D

Demo 2.0 デモ2.0

October 1988 1988年10月

2.1

Release 2.1 リリース2.1

March 1990

2.2

Release 2.2 リリース2.2

December 1994

2.3

Release 2.3 リリース2.3

March 1997

2.3.1

Release 2.3.1 リリース2.3.1

May 1999

2.4

Release 2.4 リリース2.4

November 2000

1998年9月

1990年3月
1994年12月

1997年3月
1999年5月
2000年11月

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

注（処方） 処方監査結果の応答については、このフィールドで指定する。

Copyright©2002-2003 JAHIS V1.1

30

MSH-17 Country Code 国コード (ID) 00017
定義： メッセージの発信国を定義する。主に通貨単位などのデフォルト要素を指定するのに使用される。ISO 3166は、使用可能な国コードのリストを提供する。
通常は本フィールドは使用しない。
MSH-18 Character Set 文字セット (ID) 00692
定義： メッセージ全体に使用する文字セットコードを定義する。有効な文字セットをテー
ブル0211にしめす。
HL7表 0211 – Alternate Character sets 代替文字セット
Value

Description

ASCII

The printable 7-bit ASCII character set .

8859/1The printable characters from the ISO 8859/1 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(省略時)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)

UNICODE

The world wide character standard from ISO/IEC 10646-1-1993

注:文字セットにかかわらずフィールド区切り文字は 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 (ID) 01598

定義: サイトは、このフィールドを、HL7 かあるサイトによって発行された準拠宣言を支持していることを主張するために用いることができる。準拠宣言は、文法、構文および特定のメッセー
ジやメッセージのセットの詳細化された説明を含む。準拠宣言の使用例は、第５章"照会"に現れる。
このフィールドの反復は、生成され名付けられた準拠宣言に、より柔軟性を持たせる。例えば、反復の最初は、標準準拠宣言を参照でき、二回目はその変更である。
HL7‑標準準拠宣言の値は、次に示す HL7 表 0449-準拠宣言ＩＤに現れる。

Copyright©2002-2003 JAHIS V1.1

31

HL7 表0449 - Conformance statements
値

準拠宣言ＩＤ

説明

注: HL7技術委員会は準拠宣言を投票し、表0449はそれらの識別子で埋められるだろう。バージョン2.4ではどんな識別子も発行されていない。どんなHL7表でも、この表はサイト定義識別子で拡張できる。

Copyright©2002-2003 JAHIS V1.1

32

7.2 NTE - Notes and Comments Segment

注釈コメントセグメント

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

LEN

DT

OPT

Japan

1
2

4
8

SI
ID

O
O

O
O

3

64k

FT

O

O

4

250

CE

O

O

RP/#

Y

ITEM #ELEMENT NAME

00096
00097

Set ID - NTE セットID-NTE
Source of Comment コメント発生源

00098

Comment コメント

01318

Comment Type

NOTE

コメント型

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

NTEフィールド定義
NTE-1 Set ID - NTE セットID-NTE (SI) 00096
定義: ひとつのメッセージ中に複数のNTEセグメントが含まれる場合に使用される。番号付けについては、アプリケーション・メッセージの定義に記述されなければならない。
NTE-2 Source Of Comment コメント発生源 (ID) 00097
定義: コメントの発生源を明示する。これは導入の際にサイトで拡張される可能性がある。
HL7表 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
定義: 先行するセグメントに従属するコメント。
注（処方） ＭＳＨセグメントに従属する場合、処方箋全体にかかるコメントを設定する。
調剤に関する特別指示は、次のコードで設定する。
表7.2.1 調剤特別指示
Value

Description

A
B

別包指示
一包化指示

C

混合指示

D

粉砕指示

Copyright©2002-2003 JAHIS V1.1

33

NTE-4 コメント型 (CE) 01318
成分: <識別子 (ST)> ^ <テキスト(ST)> ^ <コード体系名称 (IS)> ^ <代替識別子 (ST)> ^ <代替識別子(ST)> ^ <代替コード体系名称(IS)>

定義: このフィールドは、特定のコメントレコード中で送られた、コメントテキストの型を識別する値を含んでいる。提案された値は、使用者定義 HL7 表 0364 – コメント型を参照。
使用者定義表 0364 – Comment type コメント型
値

説明

PI

Patient Instructions

患者指示

AI

Ancillary Instructions

補助的指示

GI

General Instructions

一般的指示

1R

Primary Reason

2R

Secondary Reason

GR

General Reason

RE

RemarkDR

Duplicate/Interaction Reason
指示理由

主要理由
二次理由

一般理由

意見
複製/

注: フィールドは、コメントの発生源（例えば、助手、依頼者、その他）を識別するNTEレコード上に既に存在する。けれども、いくつかのアプリケーションは、コメントテキスト（例えば、指示、理由、意見他）の他の型のサポートが必要である。
分離されたNTEセグメントは、それぞれのコメントの型（例えば、指示は一つのNTE上にあり意見は他のNTE上）に使われることができる。

Copyright©2002-2003 JAHIS V1.1

34

7.3 PID - Patient Identification Segment

患者識別セグメント

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

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
1
20
26
40
250
250
80
250

DT
SI
CX
CX
CX
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
ID
IS
TS
HD
CE
CE
ST
CE

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

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

RP/#

Y
Y
Y

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 - PID セットID−患者ID
Patient ID 患者ID
Patient Identifier List 患者IDリスト
Alternate Patient ID - PID 代替患者ID
Patient Name 患者氏名
Mother's Maiden Name 母親の旧姓
Date/Time of Birth 生年月日年齢
Administrative Sex 性別
Patient Alias 患者別名
Race 人種
Patient Address 患者住所
County Code 郡コード
Phone Number - Home 電話番号−自宅
Phone Number - Business 電話番号−勤務先
Primary Language 言語−患者
Marital Status 婚姻状況
Religion 宗教
Patient Account Number 患者会計番号
SSN Number - Patient 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 Reliability Code 識別情報の信頼性
Last Update Date/Time 最終更新日時
Last Update Facility 最終更新施設
Species Code 種コード
Breed Code 品種コード
Strain 血糖情報
Production Class Code 製品分類コード

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

Copyright©2002-2003 JAHIS V1.1

35

NOTE

PIDフィールド定義
PID-1 Set ID - Patient ID セットID−患者ID (SI) 00104
定義：セグメントの反復が許されるメッセージについては、反復を識別するためにセットID
フィールドが使用される。例えば、交換及び照会のトランザクションは、セットID値1、2、3、などの多数のPIDセグメントを持つことができる。
PID-2 Patient ID 患者ID (CK) 00105
定義：このフィールドは旧バージョンとの互換性のためにのみ残されている。独断的であった用語「外部ID」はこのフィールドの名前から取り除かれた。「PID-3患者IDリスト」における発行機関、保健機関、識別区分コードなどの繰り返しは特長ある識別情報を示すために許されている。このフィールドはシステムにおいては「外部」として取り決められた解釈として残されている。PID-3患者IDリストはすべての患者識別情報として使われることを推奨されている。
過去との互換性を持つことが必要な時、患者が外部の施設、事務所他来た時には、このフィールドは値を持たなければならない。そして、このフィールドでその移動元の施設で使用していた識別子が示されなければならない。この識別子は異なる施設で使用されるものであるかもしれないし、医療機関で共用しているものかもしれない。HL7表0061チェックデジットス
キーマを参照のこと。
PID-3 Patient identifier list 患者IDリスト (CX) 00106
定義：患者を一意的に識別するため施設によって使用されるID(たとえば患者IDやカルテ番号、
請求書番号など)。患者番号を設定。
ORMメッセージを使用せず伝票による検査依頼で本フィールドに該当する情報が得られない
場合、ラボ側により付番されるIDを代入し付番組織を明示する。
PID-4 Alternate Patient ID - PID 代替患者ID (ST) 00107
定義：このフィールドは旧バージョンとの互換性のためにのみ残されている。すべての患者
識別情報は「PID-3患者IDリスト」を使用することを推奨する。もしこのフィルドを旧バージ
ョンのとの互換性のために使う時は、このフィールドには代替え、一時的、もしくは必要な場合には保留中のオプション患者識別情報、または補足的な患者識別情報に使用する。このフィールドはまた複数の患者IDを運ぶことに使うこともできる。その中には来院番号、来院日、社会保険番号も含む。
PID-5 Patient Name 患者氏名 (XPN) 00108
成分: <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^<名前表示コード>
複数の名前表示形式が存在する場合には、反復セパレータにより複数記述する。また、少な
くとも、英数字もしくは表音文字による患者氏名が記述されなければならない。
HL7表 0200 - Name Type 名前種別
Value

Description

A

Alias Name 別名

B

Name at

C

Adopted Name

養子縁組み後の名前

D

Display Name

表示名I

Licensing Name

L

Legal Name

M

Maiden Name

Copyright©2002-2003 JAHIS V1.1

Birth

誕生時の名前許可を得た名前

法律的上の名前
結婚前の名前36

ValueDescription
あだ名／よび名／道路名

N

Nickname /"Call me" Name/Street NameP

Name of Partner/Spouse (retained for backward compatibility only)
配偶者の名前（旧バージョンとの互換性のため残している）
登録名（動物のみ）

R

Registered Name (animals only)S

Coded Pseudo-Name to ensure anonymity 匿名のためのコード化された偽名

T

Indigenous/Tribal/Community NameU

Unspecified

土着／部族／共同社会名

未定義

HL7表 4000 – 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
A
N

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

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

Copyright©2002-2003 JAHIS V1.1

00114

37

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 婚姻状況 (IS)00119

使用者定義表 0002 - Marital Status 婚姻状況
Value
A

Description
Separated 別居

DDivorced 離婚

M

Married 既婚

SSingle 未婚

W

Widowed 死別

C

Common law 法的G

Living together

P

Domestic partner

R

Registered domestic partner 登録された配偶者

E

Legally SeparatedN

Annulled

I

Interlocutory 対話者

B

Unmarried

未婚

U

Unknown

不明

O

Other

T

Unreported

同居・同棲
配偶者
法的な別居

取消

その他
未報告

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

00122

PID-20 Driver's License Number - Patient 患者の運転免許証番号 (CM) 00123
定義：患者の運転免許証番号。いくつかのサイトは、患者を識別する一意的な番号としてこれを使用してもよい。第2の成分のデフォルトは患者が登録されている州である。
通常は本フィールドは使用しない。
PID-21 Mother's Identifier 母親の識別子 (CX) 00124
定義：例えば新生児用にリンク・フィールドとして使用される。典型的に、患者IDあるいは会計番号が使用されるかもしれない。
PID-22 Ethnic Group 人種のグループ (IS) 00125
定義：患者の民族的起源を定義する。
通常は本フィールドは使用しない。
PID-23 Birth Place 誕生場所 (ST) 00126
定義：患者の誕生の場所を示す。
通常は本フィールドは使用しない。

Copyright©2002-2003 JAHIS V1.1

38

PID-24 Multiple Birth Indicator多胎児誕生標識 (ID) 00127
定義：患者が多胎児の一人であったかどうか示す。Y/Nインジケータを使用。
通常は本フィールドは使用しない。
PID-25 Birth Order 誕生順序 (NM) 00128
定義：患者が多胎児の一人であった場合、誕生順序を示す値。
通常は本フィールドは使用しない。
PID-26 Citizenship 市民権 (IS) 00129
定義：患者の市民権の国を示す。推奨値として、使用者定義テーブル0171−国コード又は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

(ID)

01535

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

PID-32

Y

患者／個人の識別情報は未知である

N

患者／個人の識別情報は既知である
識別情報の信頼性

(IS)

01536

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

PID-33

Description
US

Unknown/Default Social Security NumberUD

Unknown/Default Date of BirthUA

Unknown/Default Address

AL

Patient/Person Name is an Alias

最終更新日時(TS)

不明／社会保障番号（初期値）

不明／誕生日（初期値）

不明／住所（初期値）
患者／個人名は別名

01537

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

Copyright©2002-2003 JAHIS V1.1

39

PID-34

最終更新施設

(HD)

01538

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

PID-35

種コード

(CE)

01539

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

定義：生物の種。このフィールドはコーディングシステムを用いて一般名もしくは学術名を示す。
SNOMED を推奨する。もしこのフィールドの値が無い場合は人間が対象である。推奨値について
は使用者定義表 0446 種コードを参照のこと。
使用者定義表 0446 – 種コード
Value

Description
No suggested values defined

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

PID-36

繁殖コード

(CE)

01540

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

定義：特定の動物の繁殖。このフィールドは種や血統と異なり動物に対して特有で、一般の生物には使うことができない。SNOMED が推奨されるコーディングシステムである。推奨値について
は使用者定義表 0447 品種コードを参照のこと。
使用者定義表 0447 – 品種コード
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

血統情報

(ST)

01541

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

Copyright©2002-2003 JAHIS V1.1

40

...|DeKalb|...
...|Balb/c|...
...|DXL|...

PID-38

製品分類コード (CE)01542

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

定義：このフィールドはその生物が主に繁殖されたものか、成長したものかを示すコードと／もしくはテキストである。推奨値については使用者定義表 0429 製品分類コードを参照のこと。例：...|DA^Dairy^L|...
...|MT^Meat^L|...
...|RA^Racing^L|...

使用者定義表 0429 – 製品分類コード
Value

Copyright©2002-2003 JAHIS V1.1

Description

BR

Breeding/genetic stock

DA

Dairy

DR

Draft

DU

Dual Purpose

LY

Layer, Includes Multiplier flocks

MT

Meat

OT

Other

PL

PleasureRA

Racing

SH

Show

NA

Not ApplicableU

Unknown41

7.4 PV1 - Patient Visit Segment

来院情報セグメント

PV1セグメントは、来院に関する情報を通信するために登録/ADTアプリケーションによって使用される。このセグメントは複数の来院統計記録を同じ患者の会計に送るため、又は単一の来院記録を複数の会計に送るために、使用することができる。個々のサイトは必ずこのセグメントを使用しなければならない。
HL7属性表 PV1 – Patient visit
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

Optionality
R O C -

OPT
O
R
O
O
O
O
O
O
B
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
B
O
O
O
O
O
O
O
O
O
O
O
B

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

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 – PV1 セットID-PV
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 他のヘルスケア供給者

required
optional
conditional on the trigger event or on some other field(s)Copyright©2002-2003 JAHIS V1.1

42

NOTE

X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

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

Description
Emergency 救急
Inpatient 入院患者
Outpatient 外来患者
Preadmit 予備入院
Recurring Patient 再来院患者
Obstetrics 産科
Checkup 人間ドック
Not Applicable 適応無し
Unknown 不明
注：「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
定義：患者が入院していたか入院予定の状況を示す。

Copyright©2002-2003 JAHIS V1.1

43

使用者定義表 0007 - Admission type 入院タイプ
Value
A
E
L
R
N
U
C

Description
Accident 事故
Emergency 救急
Labor and Delivery 陣痛および出産
Routine 通常
Newborn (Birth in healthcare facility) 新生児（院内で誕生）
Urgent 緊急
Elective 選択

Comments
US UB92

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

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 対麻痺

Copyright©2002-2003 JAHIS V1.1

44

B6

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 来院回数 (CK) 00149
定義：患者の各来院に割り当てられた一意的な数。
PV1-20 Financial Class 財務クラス (CM) 00150
定義：診療報酬の源を識別する目的で患者に割り当てられた、主要な財務のクラス。
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
定義：退院(つまり、帰宅；期限満了；など)の時の患者の処置。

Copyright©2002-2003 JAHIS V1.1

45

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

00171

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
V

Description
Account Level(default)
Visit Level 来院

会計（規定値）

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

Copyright©2002-2003 JAHIS V1.1

46

7.5 AL1 - Patient Allergy Information Segment

患者アレルギー情報

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

LEN
250
250
250
250
15
8

DT
CE
CE
CE
CE
ST
DT

OPT
R
O
R
O
O
B

Japan
R
O
R
O
O
O

AL1 – Patient allergy information 患者アレルギー情報
RP/#

ITEM#
00203
00204
00205
00206
00207
00208

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

NOTE

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

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

Description
Drug Allergy 薬剤アレルギー
Food Allergy 食事アレルギー
Miscellaneous Allergy 様々なアレルギー
Miscellaneous Contraindication 様々な禁忌
Environmental Allergy 環境アレルギー
Animal Allergy 動物アレルギー
Plant Allergy 植物アレルギー
Pollen Allergy 花粉アレルギー

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

Copyright©2002-2003 JAHIS V1.1

47

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

アレルギー重症度

Value

Description

SV
MO
MI
U

Severe重度
Moderate 中程度
Mild
軽度
Unknown 不明

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

Copyright©2002-2003 JAHIS V1.1

48

7.6 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依頼者オーダー番号フィールドど同じ意味
および目的を持つ。
これらのフィールドを使用する規則では、ORCに現れない値はオーダー詳細セグメントに現れねばならない。しかし、両方の箇所に値を入れて混乱を避けることが望ましい。
c)親/子 − キャンセル、保留、中断
親オーダーのキャンセル、保留または中断の要求の伝達は、その要求は親オーダーおよびすべての関連の
子オーダーに対して再帰的に適用されるよう意図されている。たとえば
1)EKGアプリケーションが3回のEKGに対するオーダーを受け、これが3日連続で毎朝行われるとする。
2)EKGアプリケーションは3つの子オーダーを、各々の要求されたEKGに対して1つづつ作成する。
3)元の親オーダーを取消す要求が受取られた時に1日目のEKGが実施されていた。(親は取消せなかった)
4)残りの、未実施の子は要求の結果として取り消される。
注（処方）但し、本規約においては親/子オーダは使用しない。
HL7属性表
SEQ

LEN

DT

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

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

ID
EI
EI
EI
ID
ID
TQ
CM
TS
XCN
XCN
XCN
PL
XTN
TS
CE

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

Copyright©2002-2003 JAHIS V1.1

ORC 共通オーダ

Japan

RP/#

ITEM#

ELEMENT NAME

R
R
O
R
X
O
R
X
O
X
X
O
O
X
X
X

N

00215
00216
00217
00218
00219
00220
00221
00222
00223
00224
00225
00226
00227
00228
00229
00230

Order Control オーダ制御
Placer Order Number 依頼者オーダ番号
Filler Order Number 実施者オーダ番号
Placer Group Number 依頼者グループ番号
Order Status オーダ状態
Response Flag 応答フラグ
Quantity/Timing 数量/タイミング
Parent 親
Date/Time of Transaction トランザクション日時
Entered By 入力者
Verified By 検証者
Ordering Provider 依頼者
Enterer's Location 入力場所
Call Back Phone Number コールバック用電話番号
Order Effective Date/Time オーダ有効日時
Order Control Code Reason オーダ制御コードの理由

N
Y

Y
Y
Y
Y/2

49

NO
TE

SEQ

LEN

DT

17
18
19
20
21
22
23
24
25

250
250
250
250
250
250
250
250
250

CE
CE
XCN
CE
XON
XAD
XTN
XAD
CWE

OP
T
O
O
O
O
O
O
O
O
O

Japan
O
O
O
O
O
O
O
O
O

RP/#

Y
Y
Y
Y
Y
N

ITEM#

ELEMENT NAME

00231
00232
00233
01310
01311
01312
01313
01314
01473

Entering Organization 入力組織
Entering Device 入力装置
Action By 発動者
拡張利用用注意コード
オーダ施設名オーダ施設住所
オーダ施設電話番号
オーダ提供者アドレス
オーダ状態修正NO
TE

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

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

Copyright©2002-2003 JAHIS V1.1

50

テーブル 0119 – Ordeer Control Code オーダー制御コードとその意味
Value1NW
OK
UA

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
(使用しない)(使用しない)b(使用しない)

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

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

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

PA
CH

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

F
F,P

e,d,h
f,d,h(RPにて対応)
g,d,h,l(RPにて対応)
d,e,g,h(使用しない)(使用しない)(使用しない)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

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

注（処方）Copyright©2002-2003 JAHIS V1.1

51

当規約においては、オーダのキャンセルおよび修正は、処方箋単位で行うものとし、薬剤単位でのキャンセルおよび修正は行
わない。

ORCのオーダー制御コードのためのテーブルの注。
a) CA
オーダキャンセル依頼は、以前にオーダーしたサービスを行わないようにとの要求である。
キャンセル要求の確認は、実施者によっておこなわれる。たとえば、CRの(ORC-1-オーダー制
御)値を持つメッセージである。
b) UC
UC オーダーキャンセル(不能)コードは、依頼されたサービスが実施者によって取り消せないポイントにあるとき、あるいは、現場の取り決めで実施者によるキャンセルを禁止するとき使用される。このコードの使用は、ORC-6-応答フラグに従う。
c) DC
オーダー中断要求コードは、進行中の依頼されたサービスをやめるために使用される。それは、キャンセル要求と同じではない。それは、オーダーが起こるのを防止するために使用される。
d) RP, RQ, RU, RO
オーダー修正依頼は、以前に依頼された、1個以上のオーダーの置き換えである。取換えられたオーダーは、あたかも取り消されたオーダーのように扱われる。依頼されたサービスが取換えられるかどうか、いつ取換えるかは、現場独自で決定する。オリジナルのオーダーがもとのままであることをサイトが要求するならば、親/子オーダー制御コードを使用する。このような時は、オーダー修正コードを使用しない。
取換えられる各々のオーダーには、RP(実施者に対するオーダー修正依頼)のORC-1-オーダー
制御値またはRU(実施者によって作成された、オーダー修正通知(実施者))を使用すること。RUは実施者によって使用され、依頼者および、または他のシステムに通知するためのものである。現場の取り決めによって、ORCセグメント(RPまたはRUと)の後には、そのオリジナルのオーダー詳細セグメントが続いてもよい。ORCセグメント(RPまたはRUと)の後には、RO(修正後オーダーを示す)のORC-1-オーダー制御値をもつ、ORCセグメントが続かなければならない。現場の取り決めによっては、RO値を持つORCは、オーダー詳細セグメントが後に続いてもよい。
たとえば、部門のアプリケーションが2個のOBRオーダーを3つの異なったオーダーで取換えていたと仮定する。セグメントの連続は、次の通りになる。
図 4-2. RU と RO 使用法 （例）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 と RO 使用法（例）
Segment
ORC
OBR
ORC

Copyright©2002-2003 JAHIS V1.1

Order Control
RQ

RQ

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

52

Segment
OBR

Order Control

Comment
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
取換えオーダーコードは実施者のアプリケーションによってオーダーされたサービスの正確な取換えを指示する別なアプリケーションに送られる。それは上記の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. ２つの子オーダの例
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つの可能性がある：各々の子はそのCopyright©2002-2003 JAHIS V1.1

53

親の依頼者番号を受け継ぐか、あるいは、実施者は依頼者が依頼者番号を割り当てるよう要求するためにSN/NAトランザクションを使用する。どちらのケースでも、実施アプリケーションは、その通常の手続きに応じて子の実施者番号を作成する。
子オーダーが送られるときは常に、ORCセグメントのORC-8-親に、親の実施者番号(実施者から開始するならば)および親の依頼者番号(実施者から開始するならば、あるいは依頼者から開始するならば)が割り振られる。
親子のメカニズムは、たとえば、毎朝、連続して3回のEKGのオーダーを発行するといったように、親オーダーを拡張することのために使用される。
j) RE
検査付帯情報コードは、オーダーと共に患者固有情報を送るのに使用される。オーダー詳
細セグメント(たとえば、OBR)の後には、1個以上の検査セグメント(OBX)を続けることができる。ORUメッセージとして伝えることができ
るいかなる検査情報も、このメカニズムで伝えることができる。結果がオーダーと共に送られるときは、結果は、そのオーダーの直後に続けられるべきである。
次の例は、3個の処方オーダーのためのセグメントのシーケンスを、REコードの使用例で示す。

図 4-5. RE 使用法（例）
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-実施者
オーダー番号を割り当てたいとき

Copyright©2002-2003 JAHIS V1.1

54

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を持つ。.

Code

From

ORC-2-Placer Order Number

ORC-3-Filler Order NumberSNfiller application

placer order number^filler application ID

null

NA

other application

placer order number^filler application ID

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
From
SN
filler applicationNAother application

ORC-2-Placer Order Number
null
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
NW , RO

From
other application to the filler

Copyright©2002-2003 JAHIS V1.1

ORC-2-Placer Order Number
placer order number^placer application ID

55

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

m) 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|...
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
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal
ID type (ID)>
定義：依頼アプリケーションのオーダー番号
第1成分は、個々のオーダー(たとえば、(OBR))を識別する15文字までの文字列である。それは、依頼者(依頼アプリケーション)によって割り当てられる。それは、特定の依頼アプリケー
ションからのすべてのオーダーの中から一意に一つのオーダーを識別する。第2成分は依頼ア

Copyright©2002-2003 JAHIS V1.1

56

プリケーションのアプリケーション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は、ネットワーク上の送信および受信アプリケーションと同じでなくともよい(MSHセグメントにおいて述べた)。
ORC-2-依頼者オーダー番号は、OBR-2-依頼者オーダー番号と同じある。依頼者オーダー番
号がORCの中に存在していないならば、それは関連したOBR内に存在しなければならない。
その逆もまた真である。もし両方のフィールド、すなわちORC-2-依頼者オーダー番号およびOBR-2-依頼者オーダー番号が設定されるならば、それらは同じ値でなければならない。結果がORUメッセージで送られるとき、ORCは必要ないが、依頼者オーダー識別番号がOBRセグ
メント内に存在せねばならない。
これらの規則は、上位互換性のためORCとOBRの両方の中に存在している他のフィールドにも適用する。(たとえば、数量/タイミング、親番号、オーダー依頼者、および依頼コールバ
ック用電話番号)。
注（処方） すべてのオーダ（処方箋単位）を一意に識別できるオーダ番号。
第一成分のみ使用する。
ORC-3 Filler Order Number 実施者オーダー番号 ( EI) 00217
Components:<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID
type(ID)>
定義： 実施アプリケーションに関連したオーダー番号。その第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セグメント内に存在

Copyright©2002-2003 JAHIS V1.1

57

せねばならない。
実施者オーダー番号(OBR-3あるいはORC-3)は、オーダーとその関連した検査を一意に識別する。たとえば、ある施設が検査をいくつかの関連アプリケーションから集め、それを共通のデータベースの中に入れ、この共通のデータベースがまた別のアプリケーションによって検査のために照会される、と仮定する。この場合、共通のデータベースアプリケーションによって送られた実施者オーダー番号と依頼者オーダー番号は、それぞれオリジナルの実施者
および依頼者であろう。すなわち共通のデータベースアプリケーションによって割り当てられた新しいものではない。
同様に、実施者あるいは依頼者でないオーダーの第三者アプリケーションが、オーダーの状態を修正する(たとえば、それをキャンセルすること)権限があるならば、その第三者アプリ
ケーションは、実施者にORMメッセージを送る。そこには、『CA』に等しいORC-1オーダー制御の付いたORCセグメント、およびオリジナル依頼者オーダー番号および実施者オーダー
番号を含む。いずれもそれ自身が割り当ることはない。
注（処方） 依頼者側で番号を振る必要がある場合は、その番号を示す。
ORC-4 Placer Group Number 依頼者グループ番号 (EI) 00218
定義：オーダー依頼アプリケーションが複数セットのオーダーを一緒にグループ化して後でそれらを識別できるようにする。
第1成分は、15文字までの文字列であって、これがすべての他のオーダーグループを特定の依頼アプリケーションから一意に識別する。それは依頼アプリケーションによって割り当て
られて、ORCの依頼者オーダー番号と同じシリーズでもよいが、これは必須ではない。
注（処方） 全てのＲｐを一意に識別できる番号。第一成分のみ使用する。
ORC-5 Order Status オーダー状態(ID) (ID) 00219
定義： オーダーの状態。取りうる値についてはテーブル0038オーダー状態を参照すること。
このフィールドの目的は、要求された場合または状態が変更になった場合に、オーダーの状態を報告することであり、オーダー自体を処理する事ではない。オーダー状態は、メッセー
ジが送られるとき送信アプリケーションに知られていた状態を反映させる。実施者だけがこのフィールドに値を付けることができる。
テーブル0038に示すオーダー状態は、テーブル0119オーダーコントロールと同じ様な内容を含んでいるが、目的は異なる。オーダ状態は、ORC-1-オーダー制御値のSRまたはSCにおいて典型的に使用される。これはオーダーの状態を、要求を受けた時または当事者に随時報告するためである。
HL7表 0038 - Order status
Value
A
CA
CM
DC
ER
HD
IP
RP
SC

オーダ状態

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

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

応答フラグ

Description
Report exceptions only 例外のみを報告
Same as E, also Replacement and Parent-Child Eと同じ、また取換えおよび親子
Same as R, also other associated segments Rと同じ、また他の関連セグメント

Copyright©2002-2003 JAHIS V1.1

58

F
N

Same as D, plus confirmations explicitly Dと同じ、プラス明確な確認
Only the MSA segment is returned MSAセグメントのみが返却される

ORC-7 Quantity/Timing 数量/タイミング (TQ) 00221
定義：優先度、数量、頻度およびアトミックサービスのタイミングを決定する。詳細は、6.3 数
量／タイミングを参照のこと。
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成分は、親オーダーの依頼者オーダー番号を含んでいる。それは、オーダーが子であるとき要求される。
第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の場所の呼称とするなど。
注（処方） 処方箋・薬袋等に診療科を表示する場合、このフィールドを参照する。

Copyright©2002-2003 JAHIS V1.1

59

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の中で識別されたオーダーが子を持っているならば、開始しなかった子は取り消される必要がある；プロセスに子がいるならば、それは中断される必要がある；子が中断できる点を超えて前進しているならば、その状態は影響されない。
ORC-16 Order Control Code Reason オーダー制御コード理由 (CE) 00230
定義： オーダー制御コード(テーブル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

事前保険金受給通知コード

(CE)

01310

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

定義：このフィールドは潜在的な保険契約にないサービスに対する支払い責任のための患者のま
たは患者の代理人の承諾状態を示す。この要素は、外来患者に対する HCFA 医療要求を満たすことを促す。この要素は次のような内容で、(a)関連づけられたサービスの診断コードが医療上必要な処置の対象かどうか。(b)この種のサービスに対して、それらがサービスのための支払い責任がCopyright©2002-2003 JAHIS V1.1

60

あることを患者に通知されているか。(c)そして、患者がサービスにたいする請求に同意しているか。そのフィールドの値は、使用者定義表 0339 -事前保険金受給通知コードから引用される。
使用者定義表0339−事前保険金受給通知コード

ORC-21値

内容

1

サービスは、医療上必要は処置の対象であること。

2

患者の責任の通知があり、サービスの支払いの同意があること。

3

患者の責任の通知があり、支払人が請求されるよう以来すること。

4

拡張された有益な通知コードがサインされていないこと。

オーダ施設名

(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

オーダ施設住所

(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)>

定義：このフィールドはオーダ依頼している施設のアドレスを含む。
ORC-23

オーダ施設電話番号

(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

オーダ発行者住所

(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オーダ状態修飾子

(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-オーダ状態フィールドの修正、推敲のためにある。このフィール
ドは提供者の付加レベルの明示、または、定義されたオーダ状態コードの付加情報に利用される。
オーダ状態フィールドとは違って、HL７定義表により支配され、このフィールドは、オーダ状態
修正コードの制限のないライブラリを供給するアプリケーションを許す CE データタイプである。
利用規定：このフィールドは ORC-5-オーダ状態フィールドに値があるかどうかにのみ占められる。
例: LIS での IP オーダ状態とともにオーダを処理することは、最新情報を送るのに、検査室を通じてのオーダ進捗状況や、外部検査機関に送られたオーダの状況を示すのにオーダ状態修正が用いられる。別の例は、医療関連でないオーダの利用で、電話が患者ルームに送られたが、一時的に切れてしまったような場合。ORC-5-オーダ状態は IP を示し、ORC-25-オーダ状態修正は切れた状態を示す。第３の例は、薬剤部での調剤 に関するものである。調剤が実施されたかどうかを知るには不十分である。ORC-25-オーダ状態修正はラベルが印刷されているかどうか、処方箋が記入されたかどうか、処方箋が出されたかどうか、などを示す。

Copyright©2002-2003 JAHIS V1.1

61

7.7 RXO – Pharmacy/Treatment Order Segment 処方／処置オーダーセグ
メント
これは 主要な 処方／処置オーダセグメントである。ここには成分または添加剤に特有でないオーダデータが記述される。OBRとは異なり、状況フィールドあるいは結果専用の他のデータは記述されない。
例えば、呼吸器治療や酸素、メタボライト（metabolites）といった薬剤を用いない治療と同様に入院患者（単位分の投与量および複合単位分の投与量）、外来患者、静注点滴および過栄養法点滴（栄養素点滴）を含む、任意のタイプの薬剤オーダに使用することができる。
処方情報に加えて、このセグメントには、担当者およびテキストコメントなどの補足データが記述される。
数量／タイミングフィールドはRXOセグメントでは必要ない。ORCセグメントには、オーダのコード化、分配、あるいは投薬にともない変化することのないオリジナルオーダの要求ORC-7−数量／タイミングが記述される。
HL7属性表 - RXO - 薬剤／処置オーダ
SEQ
1
2
3

LEN
250
20
20

DT
CE
NM
NM

OPT
C
C
O

Japan
R
R
O

RP/#

4
5
6

250
250
250

CE
CE
CE

C
C
O

R
R
O

7
8
9
10
11
12
13
14

250
200
1
250
20
250
3
250

O
O
O
O
O
O
O
C

O
O
X
X
R
O
X
O

Y

Y

00298
00299
00300
00301
00302
00303
00304
00305

15

250

C

X

Y

00306

16
17
18
19
20
21
22
23
24

1
20
20
250
250
6
250
10
250

CE
CM
ID
CE
NM
CE
NM
XC
N
XC
N
ID
ST
NM
CE
CE
ST
CE
CQ
CE

O
C
O
O
O
O
O
O
O

X
O
O
O
X
X
X
O
O

Y

Y

Y

ITEM
00292
00293
00294

ELEMENT NAME
Requested Give Code 要求投薬コード
Requested Give Amount – Minimum要求投薬量−最小
Requested Give Amount – Maximum要求投薬量−最大

00295
00296
00297

Requested Give Units 要求投薬単位
Requested Dosage Form 要求剤形
Provider’s Pharmacy/Treatment Instructions 依頼者の薬剤／治療指示
Provider’s Administration Instructions 依頼者の投薬指示
Deliver-To Location 配布先
Allow Substitutions 代替品許可
Requested Dispense Code 要求調剤コード
Requested Dispense Amount 要求調剤量
Requested Dispense Units 要求調剤単位
Number Of Refills 追加投薬回数
Ordering Provider’s DEA Number オーダ依頼者のDEA番号

00307
00308
01121
01122
01123
01218
01219
01476

Pharmacist/Treatment Supplier’s Verifier ID 検証薬剤師／治療供給者ID
Needs Human Review ヒューマンレビューの必要性
Requested Give Per (Time Unit) 要求投薬時間単位
Requested Give Strength 要求力価
Requested Give Strength Units 要求力価単位
Indication 指示
Requested Give Rate Amount 要求投薬速度
Requested Give Rate Units 要求投薬速度単位
Total Daily Dose 一日分投薬量
Supplementary Code 補足コード

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

Copyright©2002-2003 JAHIS V1.1

62

NOTE

RXOフィールド定義
RXO-1 Requested Give Code 要求投薬コード（CE） 00292
定義：このフィールドは患者に投薬するよう依頼された医用物質の識別子を示している。機
能的にはOBR-４−汎用サービスIDコードと等価である。調剤要求フィールド（患者に与えるべき物のタイプ、量を定義する： RXO-10要求調剤コード、RXO-11−要求調剤量、RXO-12−要求調剤単位を参照）は、投薬量に関する指示とは必ずしも関連しないし、依頼にともない必ず指定されるものでもない。
例えば、オーダの「投薬」部に 15mgのリブリウム(librium)を6時間ごとに投与 というフィールド情報が記述されていても、オーダの「調剤要求」部では この外来患者用に規定した薬剤の等価薬剤10 mgを30錠発行 という内容を伝えることもある。投薬コードに投薬形式が記述されていない場合、RXO-5−要求投薬形式を使用すること。
RXO-2 Requested Give Amount - Minimum 要求投薬量−最小（NM） 00293
定義：このフィールドは依頼量である。可変投与量オーダでは、最小の依頼量を示す。固定
投与量オーダでは、正確な依頼量を示す。
注：このフィールドは、数量／タイミングフィールドの第1成分の複製ではない。なぜなら、
非薬剤／治療オーダの場合、数量／タイミングフィールドの第1成分は依頼量の倍数を指定するのに使用するからである。
言い換えれば、処方／処置オーダの場合、数量／タイミングフィールドの数量成分は各サービス間隔で与えるべきものの数量を示す。したがってRXオーダでは、その第1成分のデフォル
トは常に１である。したがって、実際の依頼では、数量／タイミングフィールドの第１成分の値 1 は、このフィールド（要求投薬量フィールド）に指示された量を1回投薬することを意味する。
注（処方） 一回分の投薬量を示す。不均等投薬時は、一回分投薬量の最小値を示す。
RXO-3 Requested Give Amount - Maximum 要求投薬量−最大（NM） 00294
定義：可変投与量オーダでは、最大依頼量を示す。固定投与量オーダでは、このフィールドは使用しない。
注（処方） 不均等投薬時、一回分投薬量の最大値を示す。
RXO-4 Requested Give Units 要求投薬単位（CE） 00295
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
定義：このフィールドは投薬量の単位を示している。
注：この単位は 複合量 でもよい。つまり、単位は「〜当たりの」という言葉を含んでもよい。例えば、KG当たりのマイクログラム（micg／kg）という単位は（体重の）KG当たりのマイクログラムであることを意味する。ISO＋単位の完全な定義に関しては、第7章を参照のこと。
標準単位テーブルは複合単位の標準略語を定義するために必要である。そのようなテーブルについて合意が得られるまで、それぞれの施設でユーザテーブルが必要になる。複合単位を解釈するのになんらかの検査結果（体重、身長など）を知る必要があるなら、これらの結果
はオプションのOBXセグメントを使用して、同じオーダメッセージで送ることができる。
注（処方） 取りうる値は下図に示すとおりとする。

Copyright©2002-2003 JAHIS V1.1

63

図7.7.1 単位略号（MERIT-9
値
TAB
CAP
G
MG
MCG
L
ML
UNT
AMP
BAG
BTL
HON
KO
PCK
SHT
VIL

処方オーダ

Ver1.1

図4）

内容
錠
カプセル
グラム
ミリグラム
マイクログラムリットル
ミリリットル単位
管、アンプル
袋
瓶
本
個
包
枚
バイアル

第三成分（name of coding system）には、’MR9P’ を設定する。
例.

TAB^錠^MR9P と表現

RXO-5 Requested Dosage Form 要求剤形（CE） 00296
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
定義：このフィールドは、薬物が調合される形態を示している。例えばタブレット、カプセ
ル、坐薬である。ある場合には、この情報はRXO-1−要求投薬コードまたはRXO-10−要求分
配コードの中の分配／投薬コードによって示される。これは次の場合に使用すること。すな
わちRXO-1−要求投薬コードおよびRXO-10−要求分配コードが両方とも薬剤／治療形式を指定しない場合である。
注（処方） 取りうる値は下図に示すとおりとする。
図7.7.2 剤形略号（MERIT-9
値
TAB
CAP
PWD
SYR
SUP
LQD
OIT
CRM
TPE
INJ

処方オーダ

Ver1.1

図3）

内容
錠剤
カプセル剤
散剤、ドライシロップ剤
シロップ剤
坐剤
液剤
軟膏、ゲル
クリーム
テープ、貼付剤
注射剤

第三成分（name of coding system）には、’MR9P’ を設定する。
RXO-6 Provider's Pharmacy/Treatment Instructions 依頼者の処方／処置指示（CE） 00297
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
定義：このフィールドは、オーダ依頼者が薬剤あるいは非薬剤による治療供給者（例えば呼吸器治療）へ出す指示を識別する。もしコード化されるならば、ユーザテーブルを使用しなければならない。もしフリーテキスト・フィールドとして送信されるならば、第1の成分にはヌルを、第2の成分にはテキストを置くこと。例えば、|＾this is a free text treatment instruction|。
注（処方） 複数の指示がある場合、反復セパレータを使用して、複数記述することができる。取りうる値は、下図に示すとおりとする。

Copyright©2002-2003 JAHIS V1.1

64

図7.7.3 依頼者の処方指示
ＩＤ
EMG
EMG
SPS
SPS

テキスト
1
2
1
2

内容
緊急
保管
薬剤情報提供文書発行
健康手帳に記載し、かつ薬剤情報提供文書発行

第三成分（name of coding system）には、

JHSP を設定する。

図7.7.4 調剤特別指示
ＩＤ

テキスト

SOD

A

内容
別包指示

SOD

B

一包化指示

SOD

C

混合指示

SOD

D

粉砕指示

第三成分（name of coding system）には、 JHSP を設定する。
調剤特別指示については、MSHセグメントに従属するNTEセグメントで処方箋単位の調剤特別指示が設定されていても、薬剤単位ではこちらの設定が優先する。
図7.7.5 処方区分（MERIT-9
ＩＤ
TOC
TOC
TOC
TOC
TOC
TOC
TOC

テキスト
OHP
OHI
OHO
IHP
DCG
ORD
XTR

処方オーダ

Ver1.1）

内容
外来処方
院内処方
院外処方
入院処方
退院処方
定期処方
臨時処方

第三成分（name of coding system）には、

MR9Pを設定する。

RXO-7 Prorider's Administration Instructions 依頼者の投薬指示（CE） 00298
Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier(ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (ST)>
定義：このフィールドは、オーダ依頼者が患者、または投薬や治療の供給者へ出す指示を識別する。もしコード化されるならば、ユーザテーブルを使用しなければならない。もしフリーテキストとして送信されるならば、第1の成分にはヌルを、第2の成分にはテキストを置くこと。例えば、|＾this is a free text administration instruction|。
注（処方） 複数の指示がある場合、反復セパレータを使用して、複数記述することができる。取りうる値は、下図に示すとおりとする。
図7.7.6 依頼者の投薬指示（MERIT-9 処方オーダ
ID
DVD

テキスト
a-b-c-dVer1.1）

内容
a,b,c,dは不均等投薬時の投与量をあらわす
投薬毎の投与量をセパレータで区切って指示する
規約上１日の投与回数は制限しない

第三成分（name of coding system）には、

MR9P を設定する。

RXO-8 Deliver-To Location 配布先（CM） 00299
定義：第1の成分は、PLデータタイプに基づいて作られており、薬局または治療供給者が薬または治療装置（適用可能な場合に）を配布する入院患者または外来患者の居場所を含んでいる。デフォルト値（ヌル）は現在の患者登録場所である。この成分はPV1-3−割当患者の居場所と同じ形式を持つ。最後の成分では住所を指定できる。これは、患者または依頼者にオーダ配布を行ったり、ホームレスケアの請求を行うため使用されることがある。
注（処方） 処方オーダ発行時点の入院病床を示す。転棟・転科等で入院病床が変わった場

Copyright©2002-2003 JAHIS V1.1

65

合、QRY/ADRメッセージで照会ができる。
RXO-9 Allow Substitutions 代替品許可（ID） 00300
定義：以下に値を示す：
HL7表 0161 Allow substitution 代替品許可
値
N
G
T

内容
代替品は認可されない（これはデフォルト（ヌル）である）。
一般代替品を許可。
治療用代替品を許可。

RXO-10 Requested Dispense Code 要求調剤コード（CE） 00301
定義：このフィールドは調剤されるまたはされたものを示している。機能的にはOBR-４−汎用サービスIDと等価。オーダに存在するかどうかはアプリケーションに依存する。存在しな
い場合、RXO-11−要求調剤量とRXO-12−要求調剤単位に値が設定されていれば、RXO-1−要求投薬コードが仮定される。要求調剤コードに投薬形式が記述されていなければ、RXO-5−
要求投薬形式を使用すること。
要求調剤フィールドでの注意事項
調剤要求された薬剤の総量が、投薬量やスケジュールと直接関係がしないようにオーダを記述することがある。例えば、外来患者処方オーダが、「錠剤〈薬剤名、値〉をQ6H（6時間毎）に1日4錠飲む −− 30錠を投与する」とい
うこともありうる。入院患者オーダが、「1000ｃｃ／時間でNS／D5W（5％のブドウ糖入り通常塩） −−NSD5W
溶剤1リットル瓶を3本投与する」ということもありうる。要求調剤フィールドはオーダのこの共通のスタイルに対応
して いる。

RXO-11 Requested Dispense Amount 要求調剤量（NM）

00302

定義：このフィールドは調剤される量である。
注（処方） 要求投薬量の総量を示す。
RXO-12 Requested Dispense Units 要求調剤単位（CE） 00303
定義：このフィールドは調剤量の単位を示している。これは、調剤される物質の実際量を反映する単純単位でなければならない。複合単位は含まない。
注（処方） とりうる値は、RXO-4と同様。
RXO-13 Number Of Refills 追加投薬回数（NM） 00304
定義：このフィールドは、要求分配量がローカル規制に従って何回患者に与えられたか定義する。外来患者のみに適用。
RXO-14 Ordering Provider's DEA Number オーダ依頼者のDEA番号（XCN） 00305
定義：このフィールドはもし施設によって要求されるならば、このフィールドは依頼者物質管理番号を識別する。それは条件付きのものとして定義される。なぜなら要求される物質が規制物質（例えば麻酔剤）である場合それが必要とされるからである。
注（処方） 麻薬施用者の免許番号を示す。
RXO-15 Pharmacist/Treatment Supplier's Verifier ID 薬剤師／治療依頼者の検証ID（XCN） 00306
定義：このフィールドは薬剤師／処理物質供給業者検証者の供給者IDである。もし薬剤や治療アプリケーション、またはオーダの施設（またはオーダサブグループ）で要求されるならば、ORC-11検証担当者に追加して使用すること。
例：
依頼に際し、施設が「検証」担当者（例えば看護婦など）と 検証薬剤師／治療供給者 をCopyright©2002-2003 JAHIS V1.1

66

要求するとする。この場合、第1フィールド「ORC-11−検証担当者」はすでに指定されているが、さらに第2フィールド「RXO-15−検証薬剤師／治療供給者ID」を指定する必要がある。
RXO-16 Needs Human Review ヒューマンレビューの必要性（ID） 00307
定義：テーブル0136-Y／N標識−を使用する。このフィールドの値の意味を以下に示す。
HL7表 0136 Yes/no indicator

Y／N標識

値
Y

内容
Yes−オーダを満たす薬剤師または薬剤師以外の治療供給者が、「RXO-6−依頼者の薬剤／治療指示」中のテキストに特別の注意を払う必要があることを示す。警告が存在する。

N

No−注意事項なし。これはデフォルト（Null）と同値。.

このフィールドの使用例を次に示す：
洗練された「オーダ入力」アプリケーションであれば、あるオーダについて考えうる薬剤もしくは相互作用について知っている。しかし、オーダの依頼者は薬理相互作用についての条件を無効にしたい。この場合、実施および治療アプ リケーションでは、相互作用について調査し依頼医師と連絡するようスタッフの薬剤師もしくは薬剤師以外の治療供給者に要求することができる。
RXO-17 Requested Give Per(Time Unit) 要求投薬時間単位（ST）00308
定義：このフィールドは投薬率の計算に使用する時間単位を示している。
フォーマット：S〈整数〉＝〈整数〉秒
M〈整数〉＝〈整数〉分
H〈整数〉＝〈整数〉時間
D〈整数〉＝〈整数〉日
W〈整数〉＝〈整数〉週
L〈整数〉＝〈整数〉月注：
上記フォーマットは、 X 指定以外、数量／タイミングフィールドの「継続時間（DURATION）」成分で指定するフォーマットと同じである。
このフィールドは条件付きである。なぜならそれが要求されるのはオーダされた薬剤が連続的に所定の率（例えばある種の静注意滴）で投与されることになっているからである。例えばもし「投薬量／単位」が300mlで「投薬」時間単位がH1であるならば、率は300ml／hrであり投与の継続時間は１時間である。このようにして、投与量と単位時間当たり投与量によってサービスの継続時間が定義される。
このフィールドは、数量／タイミングフィールドの 時間間隔 成分と異なるが、その成分と組み合わせて使用することができる。例えば、「毎時300mlのNSを1時間投薬。これを1日2回繰り返す」。
RXO-18 Requested Give Strength 要求力価（NM）01121
定義：このフィールドを使用するのは、RXO-1−要求投薬コードが力価を指定しないときである。これは力価の数値の部分であって、要求力価単位と結合して使用される。
力価および力価単位フィールドが、さまざまなRX＿セグメントに含まれた数量および数量単位フィールドに加えて必要になる。その理由を説明する。内科医は、2つの方法でアンピシリ
ンのような薬の処方を書くことができる。1つの方法は次のとおりである。「アンピシリン
250mgの錠剤、2粒を1日４回。」この場合投与量は2、投与単位は錠剤、力価は250、力価単位

Copyright©2002-2003 JAHIS V1.1

67

はミリグラムである。しかしながら、依頼者は「アンピシリン500mg、１日４回」と処方箋を書くことがある。この場合投与量は500で、投与単位はミリグラムである。力価はRXOセグメ
ント中で報告されない。なぜならそれが指定されないからである。薬は、250mg 2カプセルまたは500mg 1カプセル投与することがある。しかし、薬剤師は特定の錠剤サイズを決めて、処方した錠剤サイズを250または500としてRXEセグメントに力価を記録する。
力価、単位、投薬経路、および製造会社を単一コードで指定するコード化方式もある。NDC
コードは通常、医薬品だけでなく力価、単位、剤型も意味する。例えば0047-0402-30＾Ampicillin
250 MG TABS＾NDC。したがって、この情報はすべてRXO-1−要求投薬コードの中で、そして他の薬剤／治療セグメントの中の類似のCEフィールドの中で完全に指定され得る。この場
合、この情報を指定するために力価および力価単位フィールドを使用する必要はない。
注（処方） 製剤単位あたりの力価を示す。
RXO-19 Requested Give Strength Unit 要求力価単位（CE） 01122
定義：これを使用するときは、RXO-1−要求投与コードおよびRXO-10−要求分配コードの両方が強度を指定しないときである。これは力価単位であってRXO-18−要求力価と結合して使用される。
注：これらの単位は「複合量」でありうる。つまり、単位は、単位時間当たりの量を表現することがある。例えばマイクログラム毎時（ug／h）は許容される値である。これらの複合単位はISO+テーブルに含まれている。ISO+単位の十分な定義については第7章を参照すること。
注（処方） とりうる値は、RXO-4と同様。
RXO-20 Indecation 指示（CE） 01123
定義：このフィールドは、薬剤／治療が処方された条件または問題を示している。多数の指示が適切な場合、繰り返すことがある。
RXO-21 Requested Give Rate Amount 要求投薬速度（ST）01218
定義：このフィールドは投薬速度を示している。
RXO-22 Requested Give Rate Units 要求投薬速度単位（CE）01219
定義：このフィールドはRXO-21−要求投薬与速度で使われている単位を含んでいる。
RXO-23 Total Daily Dose 一日分投薬量（ＮＭ）
定義：内服薬の場合、一日分の投薬量を示す。単位は、RXO-4 と同一とみなす。
RXO-24 補足コード (CE)01476

Components: <identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text(ST)> ^ <name of alternate coding system (IS)>このフィールドは、薬剤の物質に関係しているすべてのコードの識別を提供する。 共通のコードは次のものである：Generic Product Identifier(GPI)、Generic Code Number_Sequence
Number(GCN_SEQNO)、National Drug Code(NDC)。

Copyright©2002-2003 JAHIS V1.1

68

7.8 RXR – pharmacy/treatment route segment

投薬経路セグメント

薬剤／治療経路セグメントには、処方される経路、部位、投薬装置、投薬方法の任意な組み合わせが含まれる。どの経路を選ぶかは、薬剤／治療スタッフ及び看護スタッフのいずれか、
またはその両方に任されるが、その判断基準は、各スタッフの専門的判断か、医師の投薬指示に基づく。
HL7属性表 RXR Pharmacy/Treatment Route 投薬経路
SEQ
1
2
3
4
5

LEN
60
60
60
60
250

DT
CE
CE
CE
CE
CE

OPT
R
O
O
O
O

Japan
R
O
O
O
O

RP/#

ITEM#
00309
00310
00311
00312
01315

ELEMENT NAME
Route 経路
Site 部位
Administration Device 投薬装置
Administration Method 投薬方法
Routing Instruction 経路指示

NOTE

フィールド定義

RXR

RXR-1 Route 経路（CE） 00309
定義：このフィールドは投薬経路である。
ある種のNDC系コードなど現在の 経路コード の中には、すでに部位を含むものがある。
このような場合、コード全体は、CEデータタイプの ローカル定義コード として、このフィールドに含めることができる。有効な値については、HL7テーブル0162 − 投薬経路を参照。
HL7表 0162
値
AP
B
DT
EP
ET

内容
Apply Externally 外用
Buccal 頬
Dental 歯
Epidural 硬膜外Endotrachial Tube* 気管内チューブ*
GTTGastrostomy Tube 消化器官
GUGU Irrigant GU洗浄
IMR
Immerse (Soak) Body Part 浸透
IAIntra-arterial 動脈内IB
Intrabursal 滑液包内IC
Intracardiac 心臓内ICVIntracervical (uterus) 子宮
IDIntradermal 皮膚内IHInhalation 吸入
IHA
Intrahepatic Artery 肝内動脈
IMIntramuscular 筋肉内IN
Intranasal 鼻腔内IOIntraocular 眼内IP
Intraperitoneal 腹腔内ISIntrasynovial 滑液包内IT
Intrathecal 鞘内IUIntrauterine 子宮内IV
Intravenous 静脈内MTH
Mouth/Throat 口／喉*主として呼吸器治療および麻酔に使用される。

投薬経路

値
MM
NS
NG
NP
NT

内容
Mucous Membrane 粘膜
Nasal 鼻側Nasogastric 経口径内腔
Nasal Prongs* 鼻のプロング*
Nasotrachial Tube 鼻気管内チューブ

OP
OT
OTH
PF
PO
PR
RM
SD
SC
SL
TP
TRA
TD
TL
UR
VG
VM
WND

Ophthalmic 眼
Otic 耳Other/Miscellaneous その他／さまざま
Perfusion 灌流
Oral 口Rectal
直腸
Rebreather Mask* リブリーザーマスク*
Soaked Dressing 湿性包帯
Subcutaneous 皮下Sublingual
舌下Topical 局所
Tracheostomy* 気管切開*
Transdermal 経皮性Translingual 経舌Urethral 尿道
Vaginal 膣
Ventimask 換気マスク
Wound 創傷

RXR-2 Administrative Site 投薬部位（CE） 00310
定義：このフィールドは投薬経路の部位を含んでいる。有効な値については、HL7テーブル0163− 投薬部位を参照。

Copyright©2002-2003 JAHIS V1.1

69

CEデータタイプとしてこのフィールドを拡張すると、広範囲の部位コードをカバーすることができる（例えば、SNOMEDをテーブルソースとして使用する場合）。
HL7表
値
BE
OU
BN
BU
CT
LA
LAC
LACF
LD
LE
LEJ
OS
LF
LG
LH
LIJ
LLAQ
LLFA
LMFA
LN
LPC
LSC
LT
LUA
LUAQ
LUFA
LVG

内容
Bilateral Ears 両耳
Bilateral Eyes 両眼
Bilateral Nares 両方の鼻孔
Buttock 尻
Chest Tube 胸チューブ
Left Arm 左腕
Left Anterior Chest 左全部の胸Left Antecubital Fossa 左前腕前側の窓
Left Deltoid 左三角筋
Left Ear 左耳
Left External Jugular 左外部頚静脈
Left Eye 左目
Left Foot 左脚Left Gluteus Medius 左・・・
Left Hand 左手
Left Internal Jugular 左内部頚静脈
Left Lower Abd Quadrant 左下腹部
Left Lower Forearm 左下部の前腕
Left Mid Forearm 左中央の前腕
Left Naris 左の鼻孔
Left Posterior Chest 左後部の胸Left Subclavian 左鎖骨の下部
Left Thigh 左腿Left Upper Arm 左上腕
Left Upper Abd Quadrant 左上腹部
Left Upper Forearm 左上部の前腕
Left Ventragluteal 左・・・

0163 投薬部位
値
LVL
NB
PA
PERIN
RA
RAC
RACF
RD
RE
REJ
OD
RF
RG
RH
RIJ
RLAQ
RLFA
RMFA
RN
RPC
RSC
RT
RUA
RUAQ
RUFA
RVL
RVG

内容
Left Vastus Lateralis 左・・・
Nebulized 噴霧器
Perianal 肛門周辺
Perineal 会陰Right Arm 右腕
Right Anterior Chest 右前部の胸Right Antecubital Fossa 右前腕前側の窓
Right Deltoid 右三角筋
Right Ear 右耳
Right External Jugular 右外部頚静脈
Right Eye 右目
Right Foot 右脚
Right Gluteus Medius 右・・・
Right Hand 右手
Right Internal Jugular 右内部頚静脈
Rt Lower Abd Quadrant 右下腹部
Right Lower Forearm 右下部の前腕
Right Mid Forearm 右中央の前腕
Right Naris 右の鼻孔
Right Posterior Chest 右後部の胸Right Subclavian 右の鎖骨下部
Right Thigh 右腿Right Upper Arm 右上腕Right Upper Abd Quadrant 右上腹部
Right Upper Forearm 右上部前腕
Right Vastus Lateralis 右・・・
Right Ventragluteal 右・・・

RXR-3 Administrative Device4 投薬装置（CE） 00311
定義：このフィールドは投薬または他の治療の一助に使用される機械装置を含んでいる。よくある例としては、各種点滴セットがある。 有効な値については、HL7テーブル0164 − 投薬装置を参照。
HL7表 0164
値
AP
BT
HL
IPPB
IVP

内容
Applicator アプリケータ
Buretrol ビューレトロール
Heparin Lock ヘパリン固定具
IPPB
IV Pump 点滴ポンプ

投薬装置

値
IVS
MI
NEB
PCA

内容
IV Soluset 点滴溶剤セット
Metered Inhaler メータ付吸入器
Nebulizer 噴霧器
PCA Pump ＰＣＡポンプ

RXR-4 Administrative Method 投薬方法（CE） 00312
定義：投薬方法の指定により、患者への投薬や治療に必要な特定の方法を識別する。
な値については、HL7テーブル0165 − 投薬方法を参照。
HL7表 0165
値
CH
DI
DU
IF
IS
IR
IVPB
IVP

内容
Chew 咀嚼
Dissolve 溶解
Dust 掃除Infiltrate 浸透
Insert 挿入
Irrigate 洗浄
IV Piggyback ＩＶピギーバック
IV Push ＩＶプッシュ

Copyright©2002-2003 JAHIS V1.1

投薬方法

値
NB
PT
PF
SH
SO
WA
WI

70

内容
Nebulized 噴霧装置適用
Pain 痛み
Perfuse 灌流
Shampoo 洗髪Soak 浸透
Wash 洗浄
Wipe 拭き取り

有効

7.9 MSA - Message Acknowledgment Segmentメッセージ応答セグメント
MSAセグメントは、他のメッセージの肯定応答の特性を定義する。
HL7属性表 MSA Message Acknowledgment
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

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

MSAフィールド定義
MSA-１ Acknowledgment Code 肯定応答ｺｰﾄﾞ 00018
定義： このフィールドでは肯定応答コードを含んでおり、メッセージ処理規則に従っている。
HL7テーブル0008 肯定応答コードを参照。
HL7表 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
定義： このフィールドは下位互換性のためのものである。

Copyright©2002-2003 JAHIS V1.1

71

テーブル 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-2003 JAHIS V1.1

72

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

LEN
80

DT
CM

OPT
R

Japan
R

ERR attribute ERR属性

RP/#
Y

TBL#

ITEM #
00024

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

NOTE

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

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-2003 JAHIS V1.1

73

7.11 QRD – Query Definition Segment

問合せ定義セグメント

ＱＲＤセグメントを使用して問合せを定義する。応答では問い合わせメッセージのQRDセグメントをエ
コーバックする。その構造を図7−13に要約する。
HL7属性表 QRD - Original-Style Query Definition オリジナルスタイル照会定義
SEQ
1
2
3
4
5
6
7
8
9
10
11
12

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

DT
TS
ID
ID
ST
ID
TS
CQ
XCN
CE
CE
CM
ID

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

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

RP/#

Y
Y
Y
Y

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

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

NOTE

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
Japan（JAHIS仕様での取り扱い）
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
N not used useally. use only on the site
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

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

Copyright©2002-2003 JAHIS V1.1

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

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

QRD-4

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

QRD-5 Deferred Response Type 遅延応答タイプ（ID）00029
定義：このフィールドでは採りうる値については、テーブル0107−遅延応答タイプを参照。
QRD-3で記述した理由により通常は使用しない。
HL7表 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成分内で指定した単位で与えられた数値である。採りうる値については、テーブル0126−数量限定要求を参照。デフォルトはLIである。
通常はRD（診療記録）を指定する。
HL7表 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)> ^ <assigningauthority (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)>

定義：対象人物、つまりだれに関する問合せかを識別する。
通常の運用では次のフォーマットになる。

Copyright©2002-2003 JAHIS V1.1

75

患者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を使用する。
HL7表 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側−側両者で話し合って内容を決めておくこと。

Copyright©2002-2003 JAHIS V1.1

76

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
定義：このフィールドは結果の詳細レベルを制御するのに使用する。採りうるコードについては、テーブル0108−問合せ結果レベルを問合せ。
臨床検査依頼照会では通常はO（オーダとオーダ状態）を指定する。
臨床検査結果照会では通常はT（すべての結果）を指定する。
HL7表 0108- Query Results level 問合せ結果レベル
Value
O
R
S
T

Copyright©2002-2003 JAHIS V1.1

Description
オーダとオーダ状態
長文を除いた結果
状態のみ
すべての結果77

付録

メッセージ使用例

この節、実際の処方例にもとずき、処方メッセージがどの様に構築されるかを示すことで、規約の解釈の相違により、メッセージの使用法に相違が出ない様にすることにある。
次の処方例について、メッセージの例を示す。尚、ＯＲＣおよびＲＸＯセグメントについてのみ詳細を記述し、他のセグメントについては内容を省略して記述する。
（１）内服薬（２）外用薬（３）座薬（４）麻薬（５）注射薬（６）自己注射（７）頓服薬（８）漸増（漸減）投与（９）隔日投与（10）不均等投与（11）交互投与

Copyright©2002-2003 JAHIS V1.1

78

（１）内服薬①②

ダーゼン錠（５mg)
パンスポリンＴ錠（１００mg)
１日３回 毎食後 ３日分
アレピアチン１０倍散
フェノバルビタール１０倍散
１日２回 朝夕食後 １４日分

３錠
６錠
１００mg
１００mg

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1001￨￨12345678‑01￨￨E￨^TID&PC^D3^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1086652^ダーゼン錠(5mg)^MDCHOT￨1￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨9￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨3<CR>
ORC￨NW￨1001￨￨12345678‑01￨￨E￨^TID&PC^D3^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1109269^パンスポリンＴ錠(100mg)^MDCHOT￨2￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨18￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨6<CR>
ORC￨NW￨1001￨￨12345678‑02￨￨E￨^BID&PCM^D14^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロ
ウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1006070^アレピアチン１０倍散^MDCHOT￨50￨￨MG^ミリグラム^MR9P￨PWD^散剤^MR9P￨￨￨￨￨￨1400￨MG^ミ
リグラム^MR9P￨￨￨￨￨￨0.1￨G^グラム^MR9P￨￨￨￨100<CR>
ORC￨NW￨1001￨￨12345678‑02￨￨E￨^BID&PCM^D14^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロ
ウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1005653^フェノバルビタール１０倍散^MDCHOT￨50￨￨MG^ミリグラム^MR9P￨PWD^散剤^MR9P￨￨￨￨￨￨1400￨MG^ミリグラム^MR9P￨￨￨￨￨￨0.1￨G^グラム^MR9P￨￨￨￨100<CR>（２）外用薬①

ジフラール軟膏(10g)
１日４回 左手塗布

２本

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨2201￨￨12345678‑01￨￨E￨^QID^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHO^院外処方^MR9P<CR>
RXO￨1062380^ジフラール軟膏(10g)^MDCHOT￨￨￨G^グラム^MR9P￨OIT^軟膏^MR9P￨￨￨￨￨￨2￨HON^本^MR9P<CR>
RXR￨AP^Apply Externally￨LH^Left Hand<CR>

（３）坐薬
①

ボラギノールＮ坐薬
１日２回朝夕 １４日分

２個

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨2201￨￨12345678‑01￨￨E￨^BID&QAM,QPM^D14^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨￨DCG^退院処方^MR9P<CR>
RXO￨1056259^ボラギノールＮ坐薬^MDCHOT￨1￨￨KO^個^MR9P￨SUP^坐剤^MR9P￨￨￨￨￨￨28￨￨￨￨￨￨￨￨￨￨￨￨2^KO^個

Copyright©2002-2003 JAHIS V1.1

79

^MR9P<CR>RXR￨PR^Rectal<CR>

（４）麻薬
①

ＭＳコンチン錠(10mg)
１日２回 １２時間毎 ７日分（麻薬施用者番号

４錠

４−３２１）

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1201￨￨12345678‑01￨￨E￨^Q12H^D7^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨￨IHP^入院処方^MR9P XTR^定期処方^MR9P<CR>
RXO￨1120523^ＭＳコンチン錠(10mg)^MDCHOT￨2￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨28￨TAB^錠^MR9P￨￨4‑321^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨￨4<CR>（５）注射薬①②

セファメジン(1g)１バイアル
生理食塩注(100ml)
１瓶
１２時間毎 １時間で点滴
塩酸モルヒネ注(50mg)
１アンプル
生理食塩注(20ml)
１アンプル
１日２回 皮下注 ＰＣＡ−ポンプ使用（右腕）５０mg／１２時間

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨2001￨￨12345678‑01￨￨E￨^Q12H^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P XTR^臨時処方^MR9P<CR>
RXO￨1109634^セファメジン(1g)^MDCHOT￨1￨￨VIL^バイアル^MR9P￨INJ^注射剤^MR9P￨￨￨￨￨￨1￨VIL^バイアル^MR9P￨￨￨￨￨H1<CR>
RXR￨IV<CR>
ORC￨NW￨2001￨￨12345678‑01￨￨E￨^Q12H^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P XTR^臨時処方^MR9P<CR>
RXO￨1076677^生理食塩注(100ml)^MDCHOT￨1￨￨BTL^瓶^MR9P￨INJ^注射剤^MR9P￨￨￨￨￨￨1￨BTL^瓶^MR9P￨￨￨￨￨H1<CR>
RXR￨IV<CR>
ORC￨NW￨2001￨12345678‑02￨￨E￨^BID^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P XTR^臨時処方^MR9P<CR>
RXO￨1120608^塩酸モルヒネ注(50mg)^MDCHOT￨1￨￨AMP^アンプル^MR9P￨INJ^注射剤^MR9P￨￨￨￨￨￨1￨AMP^アン
プル^MR9P￨￨4‑321^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨<CR>
RXR￨SC￨RA￨PCA<CR>
ORC￨NW￨2001￨￨12345678‑02￨￨E￨^BID^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P XTR^臨時処方^MR9P<CR>
RXO￨1076608^生理食塩注(20ml)^MDCHOT￨1￨￨AMP^アンプル^MR9P￨INJ^注射剤^MR9P￨￨￨￨￨￨1￨AMP^アンプル^MR9P<CR>
RXR￨SC￨RA￨PCA<CR>

Copyright©2002-2003 JAHIS V1.1

80

（６）自己注射①②

ヒューマリンＮ注射液（Ｕ−４０）１０ｍｌ
１日２回 朝１４単位 夕１０単位
ＢＤプラスチパック注射器（Ｕ−４０）

１瓶
２８本

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨2001￨￨12345678‑01￨￨E￨^BID^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨DCG^退院処方^MR9P<CR>
RXO￨1054620^ヒューマリンＮ注射液（Ｕ−４０）１０ｍｌ^MDCHOT￨10￨12￨UNT^単位^MR9P￨INJ^注射剤^MR9P￨￨DVD^14‑10￨￨￨￨1￨BTL^瓶^MR9P<CR>
RXR￨IM<CR>
ORC￨NW￨2001￨￨12345678‑02￨￨E￨^BID^^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨DCG^退院処方^MR9P<CR>
RXO￨1990002^ＢＤプラスチパック注射器（Ｕ−４０）^MDCHOT￨￨￨HON^本^MR9P￨￨￨￨￨￨￨28￨HON^本^MR9P<CR>（７）頓服薬①

ボルタレン錠（２５ｍｌ）
１錠
痛い時 １０回分 （１日２回まで）

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1002￨￨12345678‑01￨￨E￨^PRN^^20000825^PRN^PRNpain￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHO^院外処方^MR9P<CR>
RXO￨1007954^ボルタレン錠（２５ｍｇ）^MDCHOT￨1￨￨TAB^錠^MR9P￨TAB^錠^MR9P￨￨１日２回まで￨￨￨￨10<CR>
RXR￨PO<CR>（８）漸増（漸減）投与①

ペルマックス錠（５０μg）
１錠
１日１回 夕食直後 ２日分② ペルマックス錠（５０μg）
２錠
１日２回 朝夕食直後 ３日分③ ペルマックス錠（５０μg）
３錠
１日３回 毎食直後 ２日分（①を服用終了後に②を服用、②を服用終了後に③を服用）
MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1001￨￨12345678‑01￨￨E￨^Q1D&PCV^D2^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P ORD^定期処方^MR9P<CR>
RXO￨1012309^ペルマックス錠（５０μｇ）^MDCHOT￨1￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨2￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨1<CR>
RXR￨PO<CR>
ORC￨NW￨1001￨￨12345678‑02￨￨E￨^QID&PCM,PCV^D3^20000827￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P ORD^定期処方^MR9P<CR>
RXO￨1012309^ペルマックス錠（５０μｇ）^MDCHOT￨1￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨6￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨2<CR>

Copyright©2002-2003 JAHIS V1.1

81

RXR￨PO<CR>
ORC￨NW￨1001￨￨12345678‑03￨￨E￨^TID&PC^D2^20000830￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨IHP^入院処方^MR9P ORD^定期処方^MR9P<CR>
RXO￨1012309^ペルマックス錠（５０μｇ）^MDCHOT￨1￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨6￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨3<CR>
RXR￨PO<CR>（９）隔日投与①

プレドニン錠（５ｍｇ）
１日１回 朝食後 ７日分（１日おきに１４日間で服用）

３錠

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1001￨￨12345678‑01￨￨E￨^Q2D&PCM^D14^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロ
ウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1052718^プレドニン（５ｍｇ）^MDCHOT￨3￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨21￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨3<CR>
RXR￨PO<CR>（10）不均等投与①

プレドニン錠（５ｍｇ）
１日３回 毎食後 ７日分

７錠（４錠−２錠−１錠）

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1001￨￨12345678‑01￨￨E￨^TID&PC^D7^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1052718^プレドニン（５ｍｇ）^MDCHOT￨1￨4￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨DVD^4‑2‑1￨￨￨￨49￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨7<CR>
RXR￨PO<CR>（11）交互投与①

プレドニン錠（５ｍｇ）
１日１回 朝食後 ７日分② プレドニン錠（５ｍｇ）
１日１回 朝食後 ７日分（①と②を交互に服用）

３錠
１錠

MSH￨......<CR>
PID￨......<CR>
ORC￨NW￨1001￨￨12345678‑01￨￨E￨^Q2D&PCM^D14^20000825￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロ
ウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1052718^プレドニン（５ｍｇ）^MDCHOT￨3￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨21￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨3<CR>
RXR￨PO<CR>

Copyright©2002-2003 JAHIS V1.1

82

ORC￨NW￨1001￨￨12345678‑02￨￨E￨^Q2D&PCM^D14^20000826￨￨￨￨￨123456^山田^太郎^^^^^^^L^I ヤマダ^タロ
ウ^^^^^^^L^P￨￨￨￨￨￨￨￨OHP^外来処方^MR9P OHI^院内処方^MR9P<CR>
RXO￨1052718^プレドニン（５ｍｇ）^MDCHOT￨1￨￨TAB^錠^MR9P￨TAB^錠剤^MR9P￨￨￨￨￨￨7￨TAB^錠^MR9P￨￨￨￨￨￨￨￨￨￨￨1<CR>
RXR￨PO<CR>

Copyright©2002-2003 JAHIS V1.1

83