ＪＡＨＩＳ標準 １６－００５

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

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

ＪＡＨＩＳ

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

え

が

き

生理検査とは、血液、尿など被検者から検体を採取し、それを検査機器で分析を行う検体検査とは異なり、生体に装着された電極やセンサーを用いて生体情報を直接検査機器などに取り込み、記録や表示を行う検査のことであり、心電図検査、脳波検査、呼吸機能検査などがある。HL7 では心電図の記述など一部の生理検査に対するガイドはみられるが、多くの生理検査データ交換に関しては具体的な仕様が決まっていない。また、例えば心電図検査結果に関しても、そのメッセージ記述には生理学、機器・信号処理、臨床診断に関する知識、経験を必要とし、それらの情報を交換することは容易でない。そのため、そのほとんどは機器メーカや専門メーカによる独自規格で処理されているにすぎなかった。
生理検査の業務における、いわゆるオーダエントリシステムや電子カルテなどのシステム開発が進むにあたり、生理検査結果の相互利用性の要請が高まり、標準化が必須の状況になった。それらの要請に沿い、保健医療福祉情報システム工業会メッセージ交換委員会（当時、現在は改称
し相互運用性委員会）において、HL7 V2.5 に基づいて各種生理検査情報交換の規約を作成し、2007
年 8 月に Ver.1.0 を発行した。その後、2013 年 4 月に各種メッセージの見直しを行い、Ver.2.0を発行した。
当生理検査データ交換規約 Ver.3.0C では、昨今のシステム連携事情を鑑み、生理検査結果電文
メッセージ等を見直した。また、他規約との整合性を保ちながらデータ交換規約共通編との分冊化を行うとともに、共通編に合わせて文章構成や記載フォーマット等を改訂した。
今日、地域医療連携などにおいてもメッセージ交換の標準化はますます重要度を増し、実装経験に基づき各分野で交換規約が改訂されている。また心電図や脳波などの医用波形はMFER(Medical waveform Format Encoding Rules:ISO/IS22077-1)に委ねることができ、生理検査
情報の取り扱いは容易になり、広く利用が期待できる。
本規約が医療資源の有効利用、保健医療福祉サービスの連携・向上を目指す医療情報標準化とデータ交換の円滑化に多少とも貢献できれば幸いである。
2016 年 12 月
一般社団法人 保健医療福祉情報システム工業会
医療システム部会 相互運用性委員会

＜＜

告知事項

＞＞

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

i

目

次

1.
2.

はじめに ..................................................................................................................................... 1
使用している HL7 について ...................................................................................................... 2
2.1.
概要 ..........................................................................................................................................2
2.2.
メッセージ ...............................................................................................................................2
2.3.
フィールド ...............................................................................................................................2
2.4.
メッセージ区切り文字 .............................................................................................................2
2.5.
データ型 ...................................................................................................................................2
3. 主な用語と参照規格 ................................................................................................................... 3
3.1.
主な用語 ...................................................................................................................................3
3.2.
参照する他規格・マスタ ..........................................................................................................3
4. JAHIS 標準テーブル .................................................................................................................. 4
5. 生理検査データ交換規約の対象範囲 ........................................................................................... 55.1.
基本方針 ...................................................................................................................................55.2.
生理検査概要 ............................................................................................................................5
5.3.
対象範囲 ...................................................................................................................................7
6. 生理検査依頼・検査結果メッセージ構文 .................................................................................. 106.1.
患者情報通知(ADT/ACK) .......................................................................................................10
6.2.
患者情報照会(QBP/RSP) ........................................................................................................ 116.3.
生理検査依頼(OMG/ORG) ...................................................................................................... 116.4.
生理検査依頼の照会(QBP/RSP) .............................................................................................13
6.5.
生理検査結果、検査ステータス通知(ORU/ACK) ...................................................................14
6.6.
データ保存確認(QBP/RSP).....................................................................................................15
6.7.
生理検査結果照会(QRY/ORF) ................................................................................................17
7. 関連セグメント ........................................................................................................................ 19
7.1. AL1 - PATIENT ALLERGY INFORMATION SEGMENT 患者アレルギー情報セグメント .............19
7.2. ERR - ERROR SEGMENT エラーセグメント ...........................................................................19
7.3. EVN - EVENT TYPE SEGMENT セグメント ............................................................................19
7.4. MSA - MESSAGE ACKNOWLEDGMENT SEGMENT メッセージ応答セグメント .......................19
7.5. MSH - MESSAGE HEADER SEGMENT メッセージヘッダセグメント .....................................19
7.6. NTE - NOTES AND COMMENTS SEGMENT 注釈コメントセグメント .....................................197.7. OBR - OBSERVATION REQUEST SEGMENT 検査要求セグメント ............................................20
7.8. OBX - OBSERVATION/RESULT SEGMENT 検査結果セグメント ..............................................28
7.9. ORC - ORDER COMMON SEGMENT 共通オーダセグメント ...................................................45
7.10. PID - PATIENT IDENTIFICATION SEGMENT 患者識別セグメント ...........................................63
7.11. PV1 - PATIENT VISIT SEGMENT 来院情報セグメント ............................................................63
7.12. QAK - QUERY ACKNOWLEDGMENT SEGMENT 照会応答セグメント ......................................63
7.13. QPD - QUERY PARAMETER DEFINITION 照会パラメータ定義 ...............................................64
7.14. QRD - QUERY DEFINITION SEGMENT 照会定義セグメント ...................................................66
7.15. QRF - QUERY FILTER SEGMENT 問合せフィルタセグメント ................................................70
7.16. RCP - RESPONSE CONTROL PARAMETER SEGMENT 応答制御パラメータセグメント ............72
7.17. TQ1 - TIMING/QUANTITY タイミング/数量セグメント ..........................................................72
付録―１．生理データ交換規約メッセージの例 ............................................................................... 73
１．各ワークフロー ...........................................................................................................................73
２．メッセージ使用例 .......................................................................................................................74© JAHIS 2016ii

３．心電図等の波形情報と検査結果情報の記述 ............................................................................. 116
付録―２．作成者名簿 ................................................................................................................... 117© JAHIS 2016iii

1. はじめに生理検査では種々の数値、文字あるいはコードなどで記述される測定値や解析結果と共に波形情報が不可欠である。ベンダー間でデータ交換を行う際、共通仕様が無かったため波形を画像化し、メタ情報に乏しい
画像ファイルとして検査結果データ交換を行っていた。メタ情報を伴った生波形の共通プロトコル策定について臨床現場からの要求が高まったこともあって、交換電文については 2007 年 8 月に JAHIS 生理検査データ交換規約 Ver.1.0 を制定し、同時期に生波形形式として MFER（Medical waveform Format Encoding
Rules）が ISO/TS として成立した。これらを機会に、当規約に準拠してベンダー間でデータ交換を行うことでマルチモダリティシステムにて実稼働する施設が増えていった。
部門システムに求められていた機能が、検査結果ファイルのファイリング機能だけではなく検査フローを管理する業務支援機能、レポーティング機能など増えていき、ベンダー間の情報交換では検査結果データの交換だけでなく、検査ステータスの交換も臨床現場のニーズを実現していく上で必要となった。さらに、サーバや PC 機器を介さずに心電計など医療機器から直接共通規約で検査データが送受信できる共通仕様が必要となってきた。それらをふまえて、検査ステータス交換やデータ埋め込みに対応した Ver.2.0 を 2013 年 4月に制定した。2014 年 9 月には、当規約を多角的視点で検証する目的で JAHIS 実証実験を行った。
今回の改定では、最新のJAHIS データ交換規約 共通編や各分野のJAHIS 標準との整合性をとりながら、
主に以下のような点を主眼として本規約をとりまとめた。
・JAHIS データ交換規約 共通編をふまえた分冊化
・MFER や HL7CDA 等検査結果データファイルの電文埋め込み仕様見直し
・誤解を招く文言の修正や分かりにくい箇所についての解説改善
生理検査情報の記述規約として、2015 年 8 月には JAHIS 生理機能検査レポート構造化記述規約 Ver.1.0が制定された。一方 MFER については 2015 年 4 月に ISO/IS22077-1 として成立した。これら検査結果情報の記述規約と本規約により、医用機器メーカ、医療情報システムベンダ間でのデータ相互利用が容易になり、生理検査情報の電子利用が促進され、医療に貢献できることを期待している。
なお、本規約は JAHIS データ交換規約 共通編と差異がある部分だけを記載した資料構成になっているた
め、JAHIS データ交換規約 共通編 Ver.1.1 との併読を前提としている事を留意いただきたい。本規約のバージョンの後に“C”という接尾辞があるが、これは JAHIS データ交換規約 共通編を参照している事を意味している。

© JAHIS 20161

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

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

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

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

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

© JAHIS 20162

3. 主な用語と参照規格
3.1. 主な用語
JAHIS データ交換規約 共通編 Ver.1.1「３．主な用語」を参照のこと。
以下は共通編との差異のみを記載する。
LOINC (Logical Observations Identifiers Names and Codes)
ASTM の検査項目コード体系を相互に関連付ける universal コード。検査室の結果と測定項目の正式名称とコードの体系的アプローチで、検査室、システムベンダ、病院、学術機関の会議により作成される数字、
コード、または注釈テキストを使用する。
Modality
Acquisition Modality：医用画像の撮影や心電図等生体情報の記録機能をサポートする検査装置。
生理検査部門システム：HIS/EMR からオーダ等情報を受信し、受付、検査結果データ管理などの検査業
務全般を司る。
以下の機能がある（部門システムの規模によって、一部の機能を実装している）。
・オーダ情報管理：HIS/EMR の生理検査依頼を受信し、部門システムで確認できる。さらに、
Modality からのリクエストにより生理検査依頼を配信できる。
（患者情報を含む）
・患者到着時の受付管理：部門で使用する受付票の発行や、部門内での患者待受け表示板もある。
・検査進捗管理：“検査中”や“検査終了”などの検査進捗を管理して一覧表示する。
・データファイリング：Modality から送信される検査データをファイリング管理する。
・実施情報管理：実施した検査項目や手技、使用薬剤情報を管理し、HIS/EMR へ送信する。
・レポーティング：検査結果レポートを作成管理し必要に応じて検査結果として HIS/EMR へ送信する。

3.2. 参照する他規格・マスタ
本規約では、以下他規格の使用を想定している。
ISO/IS22077-1 Medical waveform Format Encoding Rules
標準 12 誘導心電図波形については、MFER 形式でのデータ交換を推奨する。MFER 規格は HELICS（医療情報標準化推進協議会）の HS010 にて採択されている。また、国内の MFER 委員会では、いくつかの心電図計測値について、OID を定めている。本規格を「MFER」と略称、略記する。
臨床検査マスターコード:JLAC10
一般財団法人 医療情報システム開発センターにて開発され、同じく HELICS の HS014 にて採択されている JLAC10 コードでは、生理検査に関する検査項目コードの一部が定義されている。
LOINC(Logical Observation Identifiers Names and Codes)
LOINC は Regenstrief 研究所によって 1994 年に運用が開始された、診療名や計測値項目を表すコード集。
HL7CDA 内の各項目を識別するコードにも利用される。
ISO/HL7 27931::2009 Data Exchange Standards -- Health Level Seven Version 2.5 -- An application
protocol for electronic data exchange in healthcare environments
本規約が参照するオリジナル規格で、2009 年、HL7 version2.5 が ISO IS として承認された。

© JAHIS 20163

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

JHSS表 0001 結果データ（コーディングシステム名：JHSS0001）
Value
DUID

DataUID

Description

MIME

MIMEPackage

MFER

MFER ファイル

XML

付帯情報ファイル

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

JHSS表 0002 メッセージイベントタイプ（コーディングシステム名：JHSS0002）© JAHIS 2016

Value
ZS1

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

ZS2

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

ZS3

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

ZS4

データ保存確認応答メッセージ45. 生理検査データ交換規約の対象範囲
5.1. 基本方針
文字コード：HL7 でのトランザクションを行う全てのアクタに対し、マルチバイト文字をサポートすることを必須する。1 バイト系文字には ASCII 文字コード（ISO IR6）
、2 バイト系文字には JIS 漢字コード（ISO IR87）を使用し、文字コードの切替えには ISO 2022-1994（JIS-X0202）を使用する。また、半角カ
タカナ（ISO IR13）の使用を禁止し、JIS 補助漢字（ISO IR159）の使用は推奨しない。ISO IR87 にない
2 バイト系文字は類似形態の文字またはひらがな（カタカナ）を代用とする。

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

5.2.1. 生理機能検査室での生理検査データ
生理検査には、循環器系検査（心電図検査、心臓カテーテル検査、超音波検査など）、脳・神経系検査（脳波、筋電図など）、呼吸器系検査（スパイロメトリーなど）、肝臓、消化器、腎臓、産科、婦人科系などの検査（超音波検査など）、サーモグラフィ、眼底検査、（MRI）などの画像検査がある。
生理検査には、予め予約を行い実施する検査と予約をせず行う検査がある。一般的に標準１２誘導心電図
以外は予約が必要であることが多い。予約にあたっては部屋や機器の配置、実施者、前処置等の準備が必要である。
各検査の特徴について、以下に記載する。
（１）心電図検査
安静心電図検査（標準１２誘導心電図）ECG：通常両手両足、胸部に 6 個、合計 10 個の電極を用いて検査する。心筋梗塞、狭心症といった虚血心疾患、心房・心室性期外収縮、心房細動などの不整脈、カリウム・カルシウムなどの電解質異常などの診断に用いる。
マスターステップ（マスター２階段試験）：年齢、体重などにより設定された条件に応じて昇降台（凸状の階段）を上り下りして運動負荷をかけて検査を行い、心筋虚血の有無を診断する。
トレッドミル運動負荷試験 TMT：負荷量を設定可能なベルトコンベア風のトレッドミルによって運動負荷をかけて検査を行い、心筋虚血の有無を診断する。
エルゴメータ心肺運動負荷試験（運動耐容能検査）CPX：自転車エルゴメータに呼気ガス分析を併用して運動予備能力を測定する。主として心肺疾患の重症度、適切な運動療法の確認を行う。
長時間心電図（ホルター心電図）検査：小型の電子的記録機能を持ったレコーダ（従来はカセットテープを用いた記録装置であったが最近では電子的メモリに記憶する）に主として胸部に貼られた電極から導出された２４時間程度の期間の心電図を記録する。これは日常生活中に発生する不整脈や虚血疾患の診断に使用される。
その他の循環器検査 ：心音・心機図検査、短期間（３０秒から数分）の心電図記録、遅延心電図（レートポ© JAHIS 20165

テンシャル）、体表面電位図（体表面マッピング）検査、末梢循環検査（指尖脈波）などがある。
（２）神経生理検査
脳波検査 EEG：頭皮に電極を貼り導出、増幅（50μ ボルト程度）、記録する。てんかん、脳腫瘍、脳部障害、脳死などの判定、診断に用いる。脳波検査とは周波数分析あるいはバイスペクトル分析などを行い、別に術中の麻酔深度などに用いるものもある。
誘発電位検査：音刺激、視覚刺激などを与えることにより、頭部から脳波を加算平均して記録する。それぞれ聴性脳幹反応、視覚誘発電位という。
筋電図検査 EMG：筋肉に針電極などを挿入し筋の電気現象を記録する。
誘発筋電図検査 ：運動神経を電気刺激して伝導速度などを検査する。
睡眠脳波検査（ポリソムノグラフィ）PSG：脳波、眼球運動、筋電図、呼吸、心電図、SPO2 など睡眠時に測定し、睡眠時無呼吸症候群などの診断を行う。
聴力検査 ：聴覚測定装置（オージオメータ）や測定者自身によって測定され、難聴、聴覚の異常などの診断を行う。
平衡機能検査（重心動揺計）：三角形や四角形の荷重検出計台により患者の体重移動を測定する。迷路障害や小脳異常などの診断に用いる。
眼振検査：眼球に帯電した電位を測定し眼球運動を測定する。メニエール症候群や脳・中枢神経系の障害診断に用いる。
（３）肺機能検査
スパイロメトリー（換気機能）検査 ：呼吸の吸排気により、拘束性障害、閉塞性障害などの診断に用いる。
肺胞機能検査 ：クロージングボリュームなどにより肺胞の分布、拡散について検査する。
基礎代謝検査 ：換気量、酸素消費量、炭酸ガス産生量を測定しエネルギー代謝を測定する。バセドー氏病、
褐色細胞腫などの診断に用いられる。
（４）その他
その他、医用波形を含まないが超音波検査、眼底（写真）検査、内視鏡検査、サーモグラフィ等が生理検査部門で行われる場合がある。

5.2.2. 生理機能検査室以外(病棟等)で発生する生理検査データ（１）病棟
心電図検査、長時間心電図、脳波・誘発、超音波検査がある。
（２）産科
CTG（胎児心拍陣痛図）、超音波検査がある。
（３）心臓カテーテル検査（含む電気生理検査）
カテーテル手技と並行して、ポリグラフによる電気生理学的検査がある。

© JAHIS 20166

5.3. 対象範囲
5.3.1. 生理検査システム構成イメージ

HIS/EMR①患者情報通知③生理検査依頼⑧生理検査結果照会

生理検査部門シ

Modality

ステム(オーダ管理有)②患者情報照会④生理検査依頼照会⑤検査ステータス通知⑥生理検査結果⑦データ保存確認

Modality(オーダ管理無)②患者情報照会⑥生理検査結果⑦データ保存確認②患者情報照会④生理検査依頼照会⑤検査ステータス通知⑥生理検査結果

Modality⑥生理検査結果⑦データ保存確認

(患者情報
管理無)

※ 各数字（①～⑧）は 5.3.2 データ交換規約の対象範囲の番号に対応する
注）
生理検査部門システム：HIS/EMR からオーダ等情報を受信し、受付、検査結果データ管理などの検査業
務全般を司る。以下の機能がある（部門システムの規模によって、一部の機能のみを実装している場合があ
る）
。



オーダ情報管理。HIS/EMRの生理検査依頼を受信し、部門システムで確認できる。さらに、Modalityからのリクエストにより生理検査依頼を配信できる。
（患者情報を含む）
患者到着時の受付管理。部門で使用する受付票の発行や、部門内での患者待受け表示板がある場合もある。



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



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



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

© JAHIS 20167

5.3.2. データ交換規約の対象範囲
本規約では下記メッセージタイプ及びイベントタイプをサポートする。
「メッセージタイプ」欄の矢印（→、←）は、メッセージの応答関係を表す。上側の矢印（→）が最初のメッセージ送信を意味し、下側の矢印（←）が最初のメッセージに対する応答メッセージの送信を意味する。
メッセージとトリガーイベント
NO

メッセージ定義

メッセージタイプ

トリガーイベント
入院／来院の通知①②

患者情報通知患者情報照会③

生理検査依頼④

生理検査依頼照会⑤

検査ステータス通知⑥

生理検査結果⑦

データ保存確認⑧

生理検査結果照会

ADT→
←ACK

QBP→
←RSP
OMG→
←ORG
QBP→
←RSP
ORU→
←ACK
ORU→
←ACK
QBP→
←RSP
QRY→
←ORF

イベントタイプ
A01

患者転送

A02

退院／来院終了

A03

患者情報の更新

A08

入院/来院の通知(A01)の取消

A11

患者転送(A02)の取消

A12

退院/来院終了(A03)の取消

A13

患者の外出、外泊開始

A21

患者の帰院

A22

個人情報の更新

A31

患者の外出・外泊開始(A21)の取消

A52

患者の帰院(A22)の取消

A53

患者基本情報の問合せ

Q22/K22

患者基本情報および所在の問合せ

ZV1/ZV2

検査の依頼

O21/O22
R19/R20

検査依頼の照会

ZS1/ZS2

検査ステータスの通知

R01

検査結果メッセージ

R01

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

ZS3/ZS4

検査結果の照会

R02/R04【 メッセージの概要 】
患者情報通知（ADT/ACK）
患者に関する各種イベントの情報を ADT メッセージで通知し、それに対する応答を ACK メッセージで返す。
患者情報照会（QBP/RSP）
患者情報を QBP メッセージで問合せ、それに対する応答を RSP メッセージで返す。
生理検査依頼（OMG/ORG）
生理検査依頼のオーダ情報を OMG メッセージで通知し、それに対する応答を ORG メッセージで返す。
生理検査依頼照会（QBP/RSP）
生理検査依頼のオーダ情報を QBP メッセージで問合せ、それに対する応答を RSP メッセージで返す。
検査ステータス通知（ORU/ACK）
モダリティでの検査開始、検査終了等の検査ステータスを ORU メッセージで通知し、それに対する応答
を ACK メッセージで返す。従来の“到着確認”も本メッセージに含まれる。

© JAHIS 20168

生理検査結果（ORU/ACK）
生理検査結果を ORU メッセージで通知し、それに対する応答を ACK メッセージで返す。
データ保存確認（QBP/RSP）
データ保存確認を QBP メッセージで問合せ、それに対する回答を RSP メッセージで返す。
生理検査結果照会（QRY/ORF）
生理検査結果を QRY メッセージで問合せ、それに対する回答を ORF メッセージで返す。

© JAHIS 20169

6. 生理検査依頼・検査結果メッセージ構文
6.1. 患者情報通知(ADT/ACK)JAHIS データ交換規約 共通編 Ver.1.1「6.2．患者情報通知(ADT/ACK)」を参照のこと。
以下は共通編との差異のみを記載する。

6.1.1. ADT/ACK - 患者管理メッセージ
本規約では、表 6.1 に記載されている ADT メッセージを使用する。
表 6.1 患者管理メッセージ イベント
Value

Description

A01

入院／来院の通知

A02

患者転送

A03

退院／来院終了

A08

患者情報の/更新

A11

入院／外来の通知(A01)の取消

A12

患者転送(A02)の取消

A13

退院／来院終了(A03)の取消

A21

患者の外出・外泊開始

A22

患者の帰院

A31

個人情報の更新

A52

患者の外出・外泊開始(A21)の取消

A53

患者の帰院(A22)の取消

Comment

A06(外来患者→入院患者)やA07(入院患者→外来患者)は使用せず、上記の入院/退院を用いる。
日本の場合、A04 は外来の患者受付に相当するため使用しない。



患者情報の登録/更新はA08のみで行う。
ADT/ACK

患者管理メッセージ※生理検査用としての患者情報交換(A08 の場合)
ADT^A08^ADT_A01

ADT Message

Comment(JPN)

MSH

Message Header

R

EVN

Event TypeR

PID

Patient Identification

R

PV1

Patient VisitR[ PV2 ]

Patient Visit – Additional InfoN[{ AL1 }]Allergy InformationN

ACK^A08^ACK

General Acknowledgement

Comment(JPN)

MSH

Message Header

R

MSA

Message Acknowledgment

R[{ ERR }]

Error

O




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



患者識別(PID)セグメントはメッセージに一つ必須である。

© JAHIS 201610 来院情報(PV1)セグメントはメッセージに一つ必須である。
6.2. 患者情報照会(QBP/RSP)JAHIS データ交換規約 共通編 Ver.1.1「6.1．情報照会(QBP/RSP)」を参照のこと。

6.3. 生理検査依頼(OMG/ORG)
生理検査の依頼時には、一般オーダメッセージ(OMG)を用い、その応答には一般オーダ応答メッセージ(ORG)を使用する。

6.3.1. OMG - 一般オーダメッセージ（生理検査依頼）イベント(O19)
OMG 一般オーダメッセージ
OMG^O19^OMG_O19

General Clinical Order Message

Comment(JPN)

MSH

Message Header

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

PID

Patient Identifiation

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

O

PV1

Patient VisitR[ PV2 ]

Patient Visit 2

N[{ AL1 }]AllergyN

Order Common

R

TQ1

Timing/Quantity

R[{ TQ2 }]Timing/Quantity Order SequenceN

OBR

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

OBX

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

O

{
ORC
{

}

[{

}]
}



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



患者識別(PID)セグメントはメッセージに一つ必須である。



来院情報(PV1)セグメントはメッセージに一つ必須である。



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

【生理】では1患者の一連のオーダにPIDとPV1を必須とHL7ではPID～AL1までを省略可能としているが、する。

ORC(NW)～OBR、ORC(PA)～OBX、ORC(CH)～OBRの順に繰り返すことで親子オーダを構成する。
（詳細は6.3章を参照））
ORC(CH)～OBRは検査項目の数だけ繰り返す。

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

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

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

図２：親子メッセージの関係

6.3.2. ORG - 一般オーダ応答メッセージ（生理検査依頼応答）イベント(O20)
ORG 一般オーダメッセージ
GeneralClinical

Order

Acknowledgement

ORG^O20^ORG_O20

Comment(JPN)
Message

MSH

Message Header

R

MSA

Message Acknowledgment

R[{ ERR }]

Error

O

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

PID

Patient Identification

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

O

Order Common

O

TQ1

Timing/Quantity

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

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

O

[

{
ORC
[{

}]

}
]




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



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

【生理】では1患者の一連のオーダにPIDとPV1を必須とHL7ではPID～AL1までを省略可能としているが、する。

ORC(NW)～OBR、ORC(PA)～OBX、ORC(CH)～OBRの順に繰り返すことで親子オーダを構成する。
（詳細は6.3章を参照）
ORC(CH)～OBRは検査項目の数だけ繰り返す。
【生理】では、OBR-25に”O”をセットする。

© JAHIS 201612

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

6.4.1. QBP - 生理検査依頼照会メッセージイベント(ZS1)
QBP 生理検査依頼照会メッセージ
QBP^ZS1^QBP_Q11

Query for Physical Examination Order

Comment(JPN)

MSH

Message Header

R[{ SFT }]Software Segment

N

QPD

Query Parameter Definition Segment

R

RCP

Response Control Parameters

R[ DSC ]

Continuation PointerN

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

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



QPD-1は「ZS1^Order Query^JHSS0002」とする。
継続ポインタ(DSC)セグメントについて、【生理】ではその使用を想定しておらず、後出の「関連セグメント」
でも説明していない。

6.4.2. RSP - 生理検査依頼照会の応答メッセージイベント(ZS2)
RSP 生理検査依頼照会応答メッセージ
RSP^ZS2^RSP_K11

Query Response for Order Status

Comment(JPN)

MSH

Message Header

R[{ SFT }]Software Segment

N

MSA

Message Acknowledgement

R[ ERR ]

Error

O

QAK

Query Acknowledgement

R

QPD

Query Parameter Definition Segment

R

PID

Patient Identification

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

O

PV1

Patient VisitR[ PV2 ]

Patient Visit 2

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

Common OrderR

TQ1

Timing/Quantity

R[{ TQ2 }]Timing/Quantity Order SequenceN

OBR

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

O

[{

{
ORC
{

}

© JAHIS 201613

RSP^ZS2^RSP_K11

Query Response for Order Status

Comment(JPN)

OBX

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

O

[{

}]
}
}]




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



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



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



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



ORC(NW)～OBR、ORC(PA)～OBX、ORC(CH)～OBRの順に繰り返すことで親子オーダを構成する。
（詳細は6.3章を参照）
ORC(CH)～OBRは検査項目の数だけ繰り返す。



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

6.5. 生理検査結果、検査ステータス通知(ORU/ACK)
生理検査結果報告には検査結果(ORU/R01)メッセージを用いる。
検査ステータス通知は、ORC セグメントの ORC-5(オーダ状態)によって表わす。HL7 表 0038 オーダ状
態の値と検査ステータスの対応は以下の通りである。
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 進行中、予定

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

注：検査ステータス通知メッセージと検査結果メッセージとの区別は、OBR-25（結果状態）で行う。

OBR-25=”I”：検査ステータス通知 OBR-25=”F”：検査結果メッセージ。
【生理】では生理検査結果メッセージ（OBR-25="F"）の場合、TQ1-7（検査日時）、OBX-14（測定日時）を値必須とする。

6.5.1. 生理検査結果報告(ORU)イベント(R01)
生理検査結果報告時には検査結果(ORU)メッセージを用い、そのセグメント構文は以下のとおりである。
ORU 生理検査結果メッセージ
ORU^R01^ORU_R01

Unsolicited Transmission of an Observation

Comment(JPN)

MSH

Message Header

R{© JAHIS 201614

ORU^R01^ORU_R01

Unsolicited Transmission of an Observation

Comment(JPN)

PID

Patient Identification

RE[ PV1 ]

Patient VisitO[ ORC ]

Order common

O

OBR

Observation RequestR{[ NTE ]}Notes and comments

O

TQ1

Timing/Quantity

O[{ TQ2 }]Timing/Quantity Order Sequnece

N

OBX

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

O

Continuation Pointer

N

[

]
{

[{

}]
{[

]}
}
}
[ DSC ]



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

【生理】では、データを一意に識別できるユニークなID（DataUID)をOBX-5にセットし、データ保存確認の際の問い合せキーとして使用することができる。その場合、受信側でデータ保存する際はDataUIDにて検索可能なように検査結果と紐付けて保存管理する必要がある。

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

General Acknowledge Message

Comment(JPN)

MSH

Message Header

R

MSA

Message acknowledgment

R[{ ERR }]

Error

O




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



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

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

6.6.1. QBP データ保存確認メッセージ イベント(ZS3)
データ保存確認メッセージ(ZS3)は、DataUID を指定し、データ保存確認を送信するメッセージである。

© JAHIS 201615

QBP データ保存確認メッセージ
QBP^ZS3^QBP_Q11

Query of Document Storage Status Message

Comment(JPN)

MSH

Message Header

R[{ SFT }]Software Segment

O

QPD

Query Parameter Definition Segment

R

RCP

Response Control Parameters

R[ DSC ]

Continuation PointerO

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



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



QPD-1は「ZS3^Storage Commitment^JHSS0002」となる
継続ポインタ(DSC)セグメントについて、【生理】ではその使用を想定しておらず、後出の「関連セグメント」
でも説明してない。ただし、実装上、十分に大きなメッセージ単位(トランザクション)を扱えない場合は、当該システムのすべての関係システム・関係者の同意のもとにHL7 V2.5に従って継続ポインタ(DSC)セグメン
トを採用することができる。この決定には継続ポインタの表現方法も含まれる(関連するHL7 V2.5は、2.10.2
節、2.15.4節)。以下、他のメッセージも同様である。

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

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

Query Response of Document Storage Status

Comment(JPN)

MSH

Message Header

R[{ SFT }]Software Segment

O

MSA

Message Acknowledgement

R[ ERR ]

Error

O

QAK

Query Acknowledgement

R

QPD

Query Parameter Definition Segment

R[ DSC ]

Continuation PointerO

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

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



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



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



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

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

継続ポインタ(DSC)セグメントについて、【生理】ではその使用を想定しておらず、後出の「関連セグメント」でも説明していない。ただし、実装上、十分に大きなメッセージ単位（トランザクション）を扱えない
場合は、当該システムのすべての関係システム・関係者の同意のもとに HL7 V2.5 に従って継続ポインタ(DSC)セグメントを採用することができる。この決定には継続ポインタの表現方法も含まれる（関連する
HL7 V2.5 は、2.10.2 節、2.15.4 節）。以下、他のメッセージも同様である。

© JAHIS 201616

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

6.7.1. QRY - 生理検査結果の照会(R02)
生理検査結果照会(R02)で生理検査結果の照会をする。
QRY 生理検査結果照会メッセージ
QRY^R02^QRY_R02

Query

Comment(JPN)

MSH

Message Header

R

QRD

Query Definition

R

QRF

Query FilterR

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



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

6.7.2. ORF - 生理検査結果の応答 (R04)
生理検査結果(R04)で問合せ結果を返す。
ORF

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

ORF^R04^ORF_R04

Observational Report

Comment(JPN)

MSH

Message Header

R

MSA

Message Acknowledgment

R

QRD

Query DefinitionR[ QRF ]

Query Filter

O

PID

Patient ID

RE[{ NTE }]Notes and Comments

O[ ORC ]

Order common

O

OBR

Observation requestR{[ NTE ]}Notes and comments

O

TQ1

Timing/Quantity

R[{ TQ2 }]Timing/Quantity Order Sequnece

N[ OBX ]

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

Clinical Trial Identification

N[{ ERR }]

Error

O

[ DSC ]

Continuation Pointer

N

{[

]
{

[{

}]
{

}
{[ CTI ]}}}© JAHIS 2016

17




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



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



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

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

© JAHIS 201618

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

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

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

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

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

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

© JAHIS 201619

7.7. OBR - Observation Request Segment 検査要求セグメント
検査要求(OBR)セグメントは、診断、検査、身体検査あるいは所見などを要求するオーダに特有な情報を伝送する。
検査要求セグメントは、診断要求（例えば生理検査、EKG）あるいは検査要求(例えば生理検査、身体検査)など特定の属性を定義する。依頼者があるまとまった検査を要求する場合、必ずオーダセグメントを指定する。
以下に HL7 属性表 – OBR –検査要求を示す。この表の十字印（+）を付けた項目は実施者によって作成され、OBR セグメントが報告時に設定される。従って実施者に送られる新しいオーダではそれらはまだ設定されていない。実施者がオーダを実施する際には実施者オーダ番号が設定される。また、依頼者オーダ番
号が空白の場合は OBR セグメントが報告書として返されるとき実施者によって設定される。
OBR-7－検査日付／時間、および OBR-8－検査終了期日／時間（フラッグは#で立てられた）は、例えば検体検査の場合、検体採取の開始および終了を表わすが、【生理】では検査日時の格納にはそれぞれ TQ1-7、TQ1-8 を使用する。
HL7属性表－OBR－Observation Request
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

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

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

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

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

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

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

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

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

O
O
O
O
B
O
C
O
O
O
O
O
N
O
N
N
N
O
O
O
O

© JAHIS 2016

RP/#

TBL#

Y

Y
Y/2

0074
0123
Y
Y
0124
Y
Y
Y
Y

Y
Y
0224
0225
Y

20

検査要求

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

44
45
46

250
250
250

CWE
CWE
CWE

O
O
O

O
N
O

Y
Y

0088
0411

47

250

CWE

O

O

Y

0411

48

250

CWE

C

C

49

2

IS

O

O

0507

Procedure Code 手続きコード
Procedure Code Modifier 手続きコード修飾子
Placer Supplemental Service Information 依頼者補足サービス情報Filler Supplemental Service Information 実施者補足サービス情報
Medically Necessary Duplicate Procedure Reason. 重複検査を要する医学的理由
Result Handling 結果の取り扱い

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

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

OBR-2 Placer Order Number 依頼者オーダ番号 (EI) 00216

成分： <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID type
(ID)>

定義： ORC-2 依頼者オーダ番号に同じ。
第 1 成分の文字列で個々の OBR を識別する。これは依頼アプリケーションによって割り当てられ、ある依頼アプリケーションから送信されるすべてのオーダの中から特定のオーダを一意に識別する。
第 2 の成分ネームスペース ID は、ユーザによって定義されたコード化された値であり、特定のアプ
リケーションと一意に結び付けられている。

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

成分： <Entity Identifier (ST)> ^ <Namespace ID (IS)> ^ <Universal ID (ST)> ^ <Universal ID type(ID)>

定義：このフィールドは、実施アプリケーションと関連したオーダ番号である。オーダおよびその関連する検査に対する永久的な識別子。
第 1 成分は個々のオーダセグメント（例えば OBR)を識別する文字列である。これはオーダ実施（受信）アプリケーションによって割り当てられ、ある実施アプリケーション（例えば APIS）によるす
べてのオーダの中から特定のオーダを一意に識別する。第 2 の成分はユーザに定義されたコード化された値であって、ネットワーク上の他のアプリケーション中から特定のアプリケーションを一意に識別する。

OBR-4 Universal Service ID 検査項目 ID (CWE) 00238

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

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

© JAHIS 201621

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

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

OBR-7 Observation Date/Time 検査日時 (TS) 00241

成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
書式：YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]^<degree of precision>

定義：このフィールドは下位互換性のためだけに用意されている。
【生理】検査開始日時は、TQ1-7-開始日時で指示する。

OBR-8 Observation End Date/Time 検査終了日時 (TS) 00242

成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>
書式：YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]^<degree of precision>

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

OBR-9 Collection Volume 採取量 (CQ) 00243
成分: <Quantity (NM)> ^ <Units (CE)>

定義：検体検査の場合、検体量。

OBR-10 Collector Identifier 採取者 ID (XCN) 00244

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

定義：検体検査の場合、このフィールドは、検体を採取した個人、部門あるいは施設を識別する。

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

OBR-12 Danger Code 危険(検体)コード (CWE) 00246

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

定義：危険であることが知られている、あるいは疑われる患者・検体を示すコードかテキスト、ある
いはその両方(例えば、陽性結核患者、肝炎患者の血液などの感染情報)。コードとテキストのどちらかあるいはいずれも指定しない場合がある。しかしながらコードは第 1 成分の位置に置かれ、フリー
テキストは第 2 成分の位置に置かれる。したがって、フリーテキストのみが記述される場合、フリー
テキストの前に区切り記号が先行しておかれる。

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

© JAHIS 201622

OBR-14 Specimen Received Date/Time 検体受領日時 (TS) 00248
定義：検体検査の場合、診断サービスの実際のログイン時間/検体受領日時。

OBR-15 Specimen Source 検体材料 (SPS) 00249
定義：検体検査の場合、検体の採取部位や医療サービスの対象となる部位や検査材料を示す。

OBR-16 Ordering Provider 依頼者 (XCN) 00226

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

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

OBR-17 Order Callback Phone Number オーダ問合せ電話番号 (XTN) 00250

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

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

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

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

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

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

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

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

OBR-23 Charge To Practice 課金 (MOC) 00256

成分： <Monetary Amount (MO)> ^ <Charge Code (CWE)>

定義：適用可能な場合、実行された検査オーダの料金である。

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

© JAHIS 201623

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

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

Value
OUS
OT
OTH
OSL
PHR
PT
PHY

CP
EC

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

PF
RAD

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

RXRadiograph 放射線写真

RUS
RC

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

RT
SR
SP
TX
VUS
VR
XRC

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

EN
HM
ICU
IMM
LAB
MB
MCB
MYC
NMS
NMR
NRS

内科

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

Description
Order received; specimen not yet received オーダ受信：検体未到着
No results available; specimen received, procedure incomplete
結果なし。検体到着、検査未完了
No results available; procedure scheduled, but not done
結果なし。検査予定されるも未実施

A

Some, but not all, results available 部分的結果あり

P

Preliminary: A verified early result is available, final results not yet obtained
暫定：暫定結果有り、最終結果未確認

C

Correction to results 結果訂正

R
F

Results stored; not yet verified 結果保存済：未確認
Final results; results stored and verified. Can only be changed with a corrected result. 最終
結果：結果格納・確認済み、訂正結果のみ書き換え可能
No results available; Order canceled. 結果なし： オーダキャンセル
No order on record for this test. (Used only on queries)
オーダによらない検査結果(照会時のみ使用)
No record of this patient. (Used only on queries)
この患者の記録がない。(照会時のみ使用)

X
Y
Z

Comment

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

© JAHIS 2016

24

［参考］
【生理】では患者到着を検体到着として示す。各メッセージと検査状態を表す、OBR-25 とORC-5 の組合せを以下に示す。
OBR-25とORC-5の組合せによる検査ステータス
メッセージ
生理検査依頼OBR-25O

ORC-5SC

検査ステータス通知

IIP

受付（到着確認）

検査ステータス通知

S

IP

検査中

検査ステータス通知

S

DC

検査中断

検査ステータス通知

F

CM

検査終了

生理検査結果FCM

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

生理検査結果PSC

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

検査ステータス通知

X

CA

検査中止

Comment
オーダ受信

OBR-26 Parent Result 親結果 (PRL) 00259

成分： <Parent Observation Identifier (CWE) ^ <Parent Observation Sub-identifier (ST)> ^<Parent
Observation Value Descriptor (TX)>

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

OBR-27 Quantity/Timing 数量／タイミング (TQ) 00221
定義：このフィールドは下位互換を保つためだけに残している。TQ1 セグメントを参照のこと。このフィールドは 1 回のサービスで施すサービスの数、そのサービスの繰り返し数に関する情報を含んでいる。これにより要求の継続時間が決まる。

OBR-28 Result Copies To 結果配布先 (XCN) 00260

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

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

OBR-29 Parent Number 親番号 (EIP) 00261

成分： <Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>

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

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

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

Comment

ValueWHLC

Description

Comment

Wheelchair 車いすを使用する

OBR-31 Reason For Study 検査理由 (CWE) 00263

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

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

OBR-32 Principal Result Interpreter 結果判定責任者 (NDL) 00264

成分： <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)>^<Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location
Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

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

OBR-33 Assistant Result Interpreter 結果判定アシスタント (NDL) 00265

成分： <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)>^<Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location
Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

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

OBR-34 Technician 医療技術者 (NDL) 00266

成分： <Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)>^<Room (IS)> ^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location
Type (IS)> ^ <Building (IS)> ^ <Floor (IS)>

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

OBR-35 Transcriptionist 転記者 (NDL) 00267
成分：<Name (CNN)> ^ <Start Date/time (TS)> ^ <End Date/time (TS)> ^ <Point of Care (IS)> ^<Room (IS)>^ <Bed (IS)> ^ <Facility (HD)> ^ <Location Status (IS)> ^ <Patient Location Type (IS)> ^ <Building (IS)> ^<Floor (IS)>
定義：報告書の口述筆記を担当する人。

OBR-36 Scheduled - Date/Time 予定日時 (TS) 00268

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

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

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

OBR-38 Transport Logistics Of Collected Sample 採取検体搬送 (CWE) 01029

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

定義：検体検査の場合、このフィールドは診断サービス実施者への検体到着で意味がある。

OBR-39 Collector’s Comment 採取者コメント (CWE) 01030

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

定義：検体に関する付加的コメント。

© JAHIS 201626

OBR-40 Transport Arrangement Responsibility 搬送調整者 （CWE） 01031

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

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

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

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

Comment

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

Description

Comment

Required 必要
Not Required 不要
Unknown 不明

OBR-43 Planned Patient Transport Comment 患者移動コメント (CWE) 01034

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

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

OBR-44 Procedure Code 手続きコード (CWE) 00393

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

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

OBR-45 Procedure Code Modifier 手続きコード修飾子 (CWE) 01316

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

定義：このフィールドはフィールド 44 において報告された手続きコードに適用できれば手続きコー
ド修飾子を含む。

OBR-46 Placer Supplemental Service Information 依頼者補足サービス情報 (CWE) 01474

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

定義：このフィールドは、依頼者システムから OBR-4 汎用サービス ID で報告された手続きコードにより実施者システムまで送られた補給サービス情報を含む。このフィールドは OBR セグメントの他の不明なオーダ詳細情報を解決する為に使われる。複数の補助サービス情報の要素が報告されるかもしれない。
「使用者定義表 0411－補助サービス情報値」を参照。
このフィールドは、検査が右部にされたか左部にされたか、例えば、検査部位が腕のどこかになされたがオーダマスタファイルには右腕か左腕か区別されない場合など、(オーダマスタファイルに区別はなく)検査が対比有りか無しかで実施されたかというような詳細情報を記述するのに使われる。

© JAHIS 201627

OBR-47 Filler Supplemental Service Information 実施者補足サービス情報 (CWE) 01475

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

定義：このフィールドは、OBR-4 汎用サービス ID で報告されている処理コードのための実施者から依頼者に送付される補助サービス情報を含んでいる。このフィールドは、OBR セグメントの特別なフィールドとして、オーダでは利用できないオーダリング情報の詳細を報告するのに使われるであろう。実施者システムがこのフィールドを使って実際に果たした事を報告するケースでオーダが改変されない限りにおいては、典型的には、それは OBR-46－依頼者発行の追加サービス情報の中の実施者
システムへ送られた情報と同じ情報を反映するであろう。複数の補助サービス情報の要素が報告されるかもしれない。
「使用者定義表 0411－補助サービス情報値」を参照。
このフィールドは、検査が右部にされたか左部にされたか、例えば、検査部位が腕のどこかになされたがオーダマスタファイルには右腕か左腕か区別されない場合など、(オーダマスタファイルに区別はなく)検査が対比有りか無しかで実施されたかというような詳細情報を記述するのに使われる。

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

定義：このフィールドは、OBR-44 - 手続きコード内の手続きが、同じ患者に関する同じ日のサービスに対して既にオーダ或いは課金されたものと重複している場合に文書化する目的で使用される。かつ医学的に必要と判断された場合に限る。理由は、コード化されるか自由なテキスト形式で入力される。 このフィールドは、誰に重複した手続きによって請求するかの会計システム情報を提供することを意図している。

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

定義：結果の取り扱いに関する情報伝達。例えば、あるオーダでは、結果（例えば、X 線フィルム）
は患者に与えられるべきで、これは請求者に対する成果である。推奨値に関しては、「使用者定義表0507－結果の取り扱い」を参照のこと。このフィールドが入力されていない場合、通常の取り扱いを意味する。
HL7表 0507 – Observation Result Handling 検査結果操作
Value
F
N

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

Comment

7.8. OBX - Observation/Result Segment 検査結果セグメント
OBX セグメントは単一検査あるいは部分検査を転送するのに使用される。それは分割不可能なレポートの最小単位に相当する。OBX は検査情報を記述するために使用し、これには CDA 文書、DICOM、MFERなどのデータも含まれる。OBX はオーダ発行時に過去の検査情報などを記載することで、本オーダの実施
者に情報を伝えることができる。また、検査結果を適切に解釈する際に必要な情報を伝えることができる。
HL7表 －OBX－Observation/Result 検査結果
SEQ
1
2
3
4
5

LEN
4
3
250
20
65536

DT
SI
ID
CWE
ST
*

OPT
O
C
R
C
C

Japan
O
R
R
C
C

RP/#

TBL#
0125

Y1

1

ELEMENT NAME
Set ID – Observational Simple セットID
Value Type 値型
Observation Identifier 検査項目ID
Observation Sub-ID 検査副ID
Observation Value 検査値： 適切なデータ・タイプ(例えば CE、TX、FT データ・タイプ)を備えた多重部分および単一の検査結果
は繰り返してもよい。

© JAHIS 2016

28

SEQ
6
7
8
9
10
11
12

LEN
250
60
5
5
2
1
26

DT
CWE
ST
IS
NM
ID
ID
TS

OPT
O
O
O
O
O
R
O

Japan
O
N
O
N
N
R
N

13

20

ST

O

N

14
15
16
17
18
19

26
250
250
250
22
26

TS
CWE
XCN
CWE
EI
TS

O
O
O
O
O
O

RE
O
O
N
O
N

RP/#

TBL#

Y/5

0078

Y
0085

Y
Y
Y

ELEMENT NAME
Units 単位
References Range 基準値範囲
Abnormal Flags 異常フラグ
Probability 確率
Nature of Abnormal Test 異常検査の性質
Observe Result Status 検査結果状態
Date Last Obs Normal Values 最新検査正常値日付
User Defined Access Checks 使用者定義アクセス点検Date/Time of the Observation 測定日時
Producer’s ID 実施者ID
Responsible Observer 検査責任者
Observation Method 検査方法
Equipment Instance Identifier 装置識別ID
Date/Time of the Analysis 分析日時

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

OBX フィールド定義
OBX-1 Set ID – Observation Simple セット ID – OBX (SI) 00569
定義： 同一の OBR セグメントに対し 1 から付番される OBX のシーケンス番号である。

OBX-2 Value Type 結果値タイプ (ID) 00570
定義： OBX 内の検査結果値データタイプを示す。
この項目は、OBX 内の検査結果値のフォーマットを含んでいる。OBX-11「検査結果状態」が「X」
でない場合、それは値を持たねばならない。値が CWE である場合､結果はコード化入力値でなければならない。値型が TX または FT である場合、結果はテキスト群である。値型の検査で取りうる値は、下記の HL7 表 – 0125 値型に列記される。
検査値は、第 2 章 2.5 節「データ型」で定義されたデータ型のフォーマットに応じて表記されなければならない。例えば、PN は成分区切り文字により分離した 6 つの成分から成る。
NM は有効な型であるが、通常数字として報告される検査では、結果の一部として非数値文字が報告されることがあるので(結果が測定器で計りきれないことを示すために>300 を使う場合など)、文字列(ST)データ型を持つことがある。たとえば">300"では、">"は記号であり桁"300"は数値と考えられる。
しかしながら、ST タイプのこの使用は推奨されない。なぜなら SN（構造化した数値）データ型は今
そのような報告を受入れ、さらに SN データ型によって受信システムが大きさを解釈できるからである。
HL7 データ型はすべて有効であり、HL7 表 – 0125 値型に含まれている。ただし、CM、CQ、SI および ID は除く。CM 定義が意味を持つためには、CM に関する詳細が項目定義に含まれていなければならない。OBX-5－検査値はデータ型 OBX-3 によって影響を及ぼされる一般的な項目定義である。
したがって、CM はこの文脈中で定義されない。CQ は無効である。なぜなら OBX-5－検査値のためのユニットが、OBX-6 ユニットを備えた OBX セグメント中で明示的に常に指定されるからである。
SI は無効である。なぜなら、それは単に HL7 メッセージセグメントに適用されるに過ぎないからである。ID は無効である。なぜなら、それは一定の項目定義を必要とするからである。
実際の検査値が OBX では送られていないが、他のどこかに存在する場合、RP 値（参照ポインタ）を使用しなければならない。例えば、検査が画像（ドキュメント関連画像あるいは医学関連画像）から成る場合、画像そのものは OBX で送ることができない。その場合送信システムは、参照ポインタを送信するよう選択することができる。受信システム側は、DICOM などの他の標準インタフェースにより、あるいは適切なデータベースサーバにより実際の画像へアクセスする必要がある場合は、いつでもこの参照ポインタを使用することができる。

© JAHIS 2016

29

HL7表 0125 – Value Type 値型
Value
AD
CE
CNE
CWE
CF
CK
CN
CP
CX
DT
ED
FT
MO
NM
PN
RP
SN
ST
TM
TN
TS
TX
XAD
XCN
XON
XPN
XTN

Description
Address 住所
Coded Entry コード化値
Coded with No Exceptions 例外のないコード化
Coded with Exceptions 例外ありコード化
Coded Element with Formatted Values 書式付コード化値
Composite ID with Check Digit 点検数字付き複合 ID
Composite ID and Name 複合 ID と名前
Composite Price 合成価格
Extended Composite ID with Check Digit
検査数字を備えた拡張合成 ID
Date 日付
Encapsulated Data カプセルに入れられたデータ
Formatted Text (Display) 書式付テキスト（表示）Money 貨幣
Numeric 数値
Person Name 人名
Reference Pointer 参照ポインタ
Structured Numeric 構造化した数値
String Data 文字列データ
Time 時間
Telephone Number 電話番号
Time Stamp (Date & Time) 時間スタンプ（日時）Text Data (Display) テキスト・データ（表示）Extended Address 拡張アドレス
Extended Composite Name and Number for Persons
人の拡張合成名前および番号
Extended Composite Name and Number for Organizations
組織の拡張合成名前および番号
Extended Person Number 拡張人番号（人名）Extended Telecommunications Number 拡張遠隔通信番号

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

OBX-3 Observation Identifier 検査項目 ID (CWE) 00571

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

定義： 検査項目を表す一意な識別子。
例：8625-6^P-R interval^LN。
検査結果コメントをセットする場合、検査項目 ID を接尾辞で修飾したコードを用いる。検査結果コ
メントの扱いを参照。
大半のシステムでは、識別子は受信システムが検査情報を処理するために、他の検査属性を列記した
検査項目マスタテーブルを参照するために使用される。検査 ID と検査項目マスタテーブルとの関係
は、請求記録中の課金コードと課金マスタテーブルの関係に類似している。
【生理】では、下記の通りとする。
DataUID を記述する場合：「DUID^DataUID^JHSS0001」© JAHIS 201630

MIME パッケージを記述する場合：「MIME^MIMEPackage^JHSS0001」
MFER 形式ファイルを記述する場合：「MFER^MFER ファイル^JHSS0001」
付帯情報ファイルを記述する場合：「XML^付帯情報ファイル^JHSS0001」
検査結果情報は Base64 で内包して送信する：
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^ x-hl7-cda-level-one ^A^<CR><LF>
MIME-Version: 1.0<CR><LF>
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"<CR><LF>
Content-Transfer-Encoding: Base64<CR><LF>--HL7-CDA-boundary<CR><LF>
Content-Type: application/x-hl7-cda-level-one+xml<CR><LF>（ここに Base64 エンコードされた CDA 文書）<CR><LF>--HL7-CDA-boundary<CR><LF>
Content-Type: application/mwf<CR><LF>（ここに Base64 エンコードされた MFER ファイル）<CR><LF>--HL7-CDA-boundary<CR><LF>||||||R|||20050201100000<CR>※<CR><LF>コードはエスケープ処理したコード¥X0D0A¥を記述すること。
※「MFER^MFER ファイル^JHSS0001」および「XML^付帯情報ファイル^JHSS0001」は下位互換性のためだけに用意されている。
※検査項目コードとしては、JLAC10 コードを用いることを推奨する。

OBX-4 Observation Sub-ID 検査サブ ID (ST) 00572
定義： 1 つの OBR の下で編成された複数の OBX セグメントが同じ検査項目 ID を持つ場合、それぞれの OBX セグメントを識別するのに使う。たとえば、心電図検査では独立した複数の波形ファイ
ルセットが含まれることがある。標準では、複数の OBX セグメント(1 つの波形ファイルセットに 1
つの OBX セグメントセット)が必要である。
これら OBX セグメントの 1 番目セットのサブ ID に 1、2 番目セットのサブ ID に 2、および n 番目セットのサブ ID に n を入れることにより、HL7 は、編集あるいは交換に際し各波形ファイルセットに対応した OBX セグメントを識別することができる。
検査サブ ID 使用の例は付録１参照

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

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

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

成分２のテキストは成分１のコードの正確な記述とすべきである。同様に、もし使用されれば成分５のテキストは成分４のコードの正確な記述とするべきである。
OBX の CDA への挿入：
CDA ドキュメントは OBX セグメントを交換に使用する。
OBX－2 結果値タイプの値は ED である。

© JAHIS 2016

32

OBX-5 検査結果に MIME データも含む。その成分は以下に通りである。
・ OBX-5.2－データ構成タイプ値'multipart'の設定
・ OBX-5.3－データサブタイプ 値'x-hl7-cda-level-one'の設定
・ OBX-5.4－エンコード値 'A'. (注意： MIME package はそれ自身は Base64 でエンコードされない。
むしろ MIME package の実体 が Base64 でエンコードされている。MIME package は ASCII テキストで送信される。それゆえ正しい値は 'A'であり 'Base64'ではない。)
・ OBX-5.5－データ値 MIME package. MIME package は Base64 でエンコードされている。JAHIS データ交換規約共通編 2 章に述べられたように、データ要素は、送信前に HL7 デリミタ文字(そしてLineFeed のような印刷されない ASCII 文字や非 ASCII 文字)をスキャンされなければならず、そして見つかった文字は2.4 節で定義されているHL7 エスケープ文字列を用いてエスケープされなければならない。受信アプリケーションは、パースした後にデータフィールドを戻さなければならない。その結果、MIME パッケージで要求されている CR/LF シーケンスは、送信前にエスケープされる(すなわち'¥X0D0A¥'に変換される)必要がある。最初の MIME コンテンツタイプは'application/x-hl7-cda-level-one+xml' がセットされ、CDA ドキュメント自体を含まなければならない。
CDAドキュメントの中で送られる必要があるCDAドキュメントによって参照されるマルティメディ
アオブジェクトは、MIME package の実体と連続して配置される。

OBX-6 Units 単位 (CWE) 00574

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

定義： 測定単位で ISO 2955-83 の ISO 省略形、または ISO 省略形と矛盾しない拡張形示す。
[バックグラウンド]検査の値が連続的な目盛りで測定される場合、OBX セグメントの単位項目内で測定単位を報告しなければならない。HL7 V2.2 の仕様の中では、単位を報告する項目はすべてデータ型 CWE にある。単位コードのためのデフォルト値コーディングシステムは、単一ケースの（大文字だけ、または小文字
だけの）単位（ISO 2955-83）の ISO 省略形、および ISO 省略形と矛盾しない拡張形から構成される。
我々は ISO+としてこのコーディングシステムを指定する。
ISO の単位の省略形および拡張形の両方が、節 7.4.2.6.2「ISO および ANSI の慣習的な単位省略形」の中で定義される、ISO+省略形はデフォルト値コーディングシステムのためのコードである。したがって、ISO+単位が使用される場合、ISO+省略形だけを送る必要がある。また、単位項目の内容は、HL7 と下位互換性を持つ。
[報告する単位の識別]
我々は、ISO+省略単位を排他的に使用するように検査担当者に強く奨励するが、必要な場合米国の慣習的な単位（ANSI X3.50）およびローカルに定義されたコードを含む他のコードシステムの使用を許す。ローカルな単位は L または 99zzz と呼ばれる。ここで z は英数字である。
ANSI X3.50-1986 は、これらの規格を丁寧に説明し、またフィートまたはガロンのような米国の慣習的な単位のための、単一ケース省略形の表を提供している。
我々は当初 ANSI X3.50-1986 の米国の慣習的な単位をデフォルト値 ISO+コーディングシステムの中に含める意図があった。しかしながら、ISO の省略形と米国の慣習的な単位の省略形の間に重複がある。例えば、ft は米国の慣習的な単位でフィートの省略形であり、ISO の中の femtotesla の省略形である；
pt は米国の慣習的な単位でパイントの省略形であり、ISO の中の picotesla の省略形である（ANSI 文
書は、一部の ISO 単位の省略形に関する ISO の文書とさらに異なることに留意すること）。潜在的な曖昧さを回避するために、我々はもう 1 つのコーディングシステムすなわち ANS+を定義した。それに含まれるのは、米国の慣習的な単位（例えばフィート、ポンド）、ANSI X3.50-1986 に定義された ISOの省略形、非メートル系の単位、およびこれらの単位の ISO の組合せである。一部の ANSI ISO 単位
省略形は ISO の中のそれらの省略形と異なることに留意すること。
ANS+仕様は、ISO および米国の慣習的な単位の両方、およびさまざまな非メートル系の単位を含んでいるので、省略形のうちのいくつかは曖昧である。特別の検査の文脈では混同はほとんどないが、この曖昧さがあるので ANS+単位コードはできるだけ避けた方がよい。

© JAHIS 201633

ANS+単位コード（省略形）が送信される場合、ANS+は、項目の第 3 の（第 6 の）成分に含まれていなければならない。もし距離の単位がメーター（ISO+）として送信されれば、ISO+が単位のデフォ
ルト値コーディングシステムなので、それは m として送信される。しかしながら、もし米国の慣習的な単位のフィートで送信されれば、単位は ft＾＾ANS+として送信される。要求されたとき、単位の全文は第 2 の成分として送ることができる。これは CWE データ型の慣習に従った形である。
ISO および ANSI の両方とも 1 セットの混合ケースの（大文字と小文字が混合した）省略形を提供する。しかし、これらの省略形は意味の損失なしで単一のケースに変換できない。それゆえこの仕様書
内では使用すべきでない。この仕様書の内容は、ケースの如何を問わず（大文字か小文字かに関係なく）解釈できるよう要求されているからである。
[ISO および ANSI の慣習的な単位省略形]
ISO は 7 つの基礎的な測定次元からその単位を作っている。すなわち、メーター、キログラム、秒、
アンペア、ケルビン、モルおよびカンデラである（下記表１を参照）。他の単位は、基礎単位に接頭辞を付けて誘導する。これによって目盛りを変え、および／または 2 つ以上の基礎単位または誘導単位を代数的に組み合わせたものを作る。しかしながら、いくつかの誘導単位はそれ自身の省略形を持っている（表１を参照）。米国の慣習的な単位の省略形は表 2 に与えられる。
ISO の規則は、ANSI X3.50 の中でよく説明されており、倍数接頭辞を加えることにより、異なる目盛の単位を作成する方法を提供する。これらの接頭辞は単語または省略形として表現できる。この規格
では、我々が省略形だけに関心がある。
表1

ISO single case units abbreviations

単位
省略形
基礎単位コード／省略形
A
アンペア
cd
カンデラ

単位

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

ケルビン
キログラム

K
kg

指定された名前および省略形を持つ誘導単位
C
hr
クーロン
時間
D
j
日
ジュール
cel
min
セルシウス度分（時間の）
F
n
ファラド
ニュートン
Hz
ohm
ヘルツ
オーム
他の単位
U
gy
原子質量単位
グレー
B
h
ベル
ヘンリー
Db
l
デシベル
リットル
deg
lm
度
ルーメン
G
lx
グラム
ルクス
十分なセットに関しては、ISA2955-1983 を参照すること。

単位

省略形

メーター
モル
秒

m
mol
s

パスカル
ボルト
ワット
ウェーバー
年

Pal
V
W
Wb
Ann

角度の分
ラジアン
ジーメンス
ステラジアン
テスラ

Mnt
Rad
Sie
Sr
T

倍数接頭辞は ISO の省略形にも存在する。10-24（1 兆分の 1 のさらに 1 兆分の 1）から 1024（1 兆×1 兆）の範囲の接頭辞がある。キロ（×1000）の単一ケース省略形はｋである。1000 秒から成る単位の省略形は ks であり、1000 グラムは kg であり、1000 メートルは km であり、以下同様である。いくつかの接頭辞は基礎単位の省略形を共有する。例えばファラドとフェムト（10-18）は両方とも省略
形は f である。混乱を回避するために、ISO は接頭辞だけの単独使用を禁止する。また 1 つの複合単位に 2 つの接頭辞を使用することを推奨しない。したがって f は常にファラドを意味し、ff は、1 フ
ァラドの 100 万分の 1 のさらに 1 兆分の 1 を意味する。複合した接頭辞は許されない。
単位は指数関数的に何乗または何乗分の 1 で表現できる。正の指数はその数を単位の省略形の直後に付ける。
つまり平方メーターは m2 によって表示される。
負の指数は基礎単位の直後に負数を付ける。
例えば、1 平方メートル当たりは m-2 で表される。分数の指数は分数を括弧の中に入れて表す：メー
ターの平方根は m（1／2）として表現される。単位の掛け算は単位の間の終止符（ .）によって示される。例えば、メーター掛ける秒は m.s で表す。スペースが許されないことに留意すること。割り算
は 2 つの単位の間の斜線（/）によって示される。例えば毎秒メーターは m／s として表示される。ISO
単位省略形の代数的な組合せであって、基礎 ISO 単位の割り算、掛け算または累乗によって作ったものも有効な ISO 省略形単位である。累乗は掛け算または割り算に優先する。例えば、1 ヘルツ当たりのマイクロボルトの 2 乗（スペクトルのパワーの単位）は uv2／hz と表され、マイクロボルトの 2 乗© JAHIS 201634

割る 1 ヘルツとして評価される。一方、1 ヘルツの平方根当たりのマイクロボルト（スペクトルの振幅の単位）は uv／hz（1／2）と表され、マイクロボルト割る 1 ヘルツの平方根として評価される。もし 2 つ以上の割り算演算子が表現中に含まれるならば、結合は括弧内に入れて曖昧さを避ける。しかし最良のアプローチは、a／（b／c）を変換して a.c／b あるいは a.c.b-1 として表現を単純化することである。
ISO コードは、構造単位では正用法である。これらの単位の構造の規則は表 1 と表 3（倍数接頭辞のための単一ケース ISO 省略形）に基づいている。下記の表 2（一部の米国の慣習的な単位の ANSI+
単位コード)は、英語単位だけにつかわれるべきで、それは表 3 との連結に使うべきではない。
ISO＋表はこの正用法からの単位構成のようなもっとも公共に含まれる。他の ISO 単位は同じように正当な用法から由来する。
表2

ANSI+ unit codes for some U.S. customary units 一部の米国の慣習的な単位のANSI+単位コード
単位

省略形

単位

省略形
単位
省略形
体積
時間
in
cft
yr
インチ
立方フィート
年
ft
cin
mo
フィート
立方インチ
月
mi
cyd
wk
マイル（法定）
立方ヤード
週
nmi
tbs
d
海里
大さじ
日
rod
tsp
hr
ロッド
小さじ
時間
yd
pt
min
ヤード
パイント
分
qt
sec
クォート
秒
gal
ガロン
foz
オンス（流体）
面積
質量
sqf
dr
平方フィート
ドラム
sin
平方インチ
グレーン
gr（常衡）sydoz
平方ヤード
オンス（重量）lb
ポンド
他の ANSI 単位、誘導単位、およびその他**英国の熱単位 btu**華氏の温度 degf**ミリラド mrad
立方フィート/分 cft/min**フィート／分 ft/min**RAD ラド
注：時間の慣習的な米国の単位の省略形は、年を除いて ISO と同じである。年の場合は ISO=ANN、ANSI=yr である。X3.50 の中のメートル単位は、次のものを除いて ISO と同じである：パスカル（「pa」は ANSI、「pal」は ISO）；
ANSI は「min」を時間と角度の両方に使用し、一方 ISO は「mnt」を角度に使用している；そして秒は ISA では「s」と略され、ANSI では「sec」と略される。
注：ANS＋仕様米国、ISO 両方の単位を含む、雑多なニモニック単位があり受け入れがたいものもある。そのため実際の検査では混乱がある、ANS+コードの削除のためには理由になる。
この一覧表は全部を網羅したものではない。他のメートル系および米国の標準単位については、ANSI X3.50-1986、
テーブル 1 を参照すること。
**ANSI で明示的に列挙されていない非メートル系単位
長さ

表3Single case ISO abbreviations for multiplier prefixes 倍数接頭辞のための単一ケースISO省略形
接頭辞
ヨッタ*
ゼッタ*
エクサ
ペタ
テラ
ギガ
メガ
キロ
ヘクト
デカ

コード
接頭辞
1024
Ya
10-24
ヨクト
21
10
Za
10-21
ゼプト
18
10
Ex
10-18
アト
15
10
Pe
10-15
フェムト
1012
T
10-12
ピコ
9
10
G
10-9
ナノ
6
10
Ma
10-6
マイクロ
3
10
K
10-3
ミリ
2
10
H
10-2
センチ
101
Da
10-1
デシ
*これらの省略形は、単一ケース省略形の ISO 仕様の中では定義されていない。

表4

一般的なISO誘導単位および*ISO拡張子

コード／省略形

名前/(arb_u)*1／任意の単位/iu*1／国際単位© JAHIS 2016

35

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

コード／省略形

名前/kg*1／キログラム/L

1／リットル

1/ml*1／ミリリッター

10.L/min*10×リットル／分

10.L/(min.m2)*10×（リットル／分）／meter2=リットル／（分×meter2）

10*3/mm3*103／立方ミリメートル（例えば白血球カウント）

10*3/L*103／リットル

10*3/mL*103／ミリリッター

10*6/mm3*106／millimeter3

10*6/L*106／リットル

10*6/mL*106／ミリリッター

10*9/mm3*109／millimeter3

10*9/L*109／リットル

10*9/mL*109／ミリリッター

10*12/L*1012／リットル

10*3(rbc)*1000 の赤血球+

a/m

メーター当たりアンペア(arb_u)

*任意単位

Bar

バール（圧力；1bar=100kilopascals）/min

毎分のビートBq

ベクレル(bdsk_u)*Bodansky 単位

(bsa）

*体表面積

(cal）

*カロリー

1

*触媒の部分/L細胞／リットルCm

センチメートル

cm_h2O*水のセンチメートル=H2O（圧力）cm_h20.s/L(cfu)

センチメートル H20（リットル／秒）=(センチメートル H2O×秒)／リットル（例えば平均の肺の抵抗）（センチメートル H20／秒）／メートル=センチメートル H20／(秒×メートル)（例えば肺の圧力時間積）。
*コロニー生成単位m3/s

毎秒立方メーター

cm_h20/(s.m)

D

日

Db

デシベル

Dba

*デシベルアスケール

Cel

摂氏の温度

Deg

角度の度

(drop)

ドロップ

10.un.s/cm5
10.un.s/(cm5.m2)

ダイン×秒／centimeter5（1 ダイン=10micronewton=10un）（例えば全身血管抵抗）（（ダイン×秒）／centimeter5）／meter2=（ダイン×秒）／（centimeter5×meter2）（1 ダ
イン=10micronewton=10un）電子ボルト（例えば全身血管抵抗／体表面積）eV

電子ボルト（1 電子ボルト=160.217zeptojoules）

Eq

当量

F

ファラド（キャパシタンス）Fg

フェムトグラムfL

フェムトリットルFmol

フェムトモル/mL*ファイバー／ミリリッター

G

グラム© JAHIS 201636

コード／省略形

名前

g/d*グラム／日g/dL

グラム／デシリットル

g/hr

グラム／時間g/(8.hr)*グラム／8 時間シフト

g/kg

グラム／キログラム（例えば体重 1 キログラム当たりの薬物投与質量）g/(kg.d)g/L（グラム／キログラム）／日=グラム／（キログラム×日）（例えば 1 日当たり体重 1 キログ
ラム当たりの薬物投与質量）（グラム／キログラム）／時間=グラム／（キログラム×時間）（例えば毎時の体重 1 キログ
ラム当たりの薬物投与質量）（グラム／キログラム）／8 時間シフト=グラム／（キログラム×8 時間のシフト）（例えば 8
時間のシフト当たり体重 1 キログラム当たりの薬物投与質量）（グラム／キログラム）／分=グラム／（キログラム×分）（例えば毎分の体重 1 キログラム当たりの薬物投与質量）グラム／リットル

g/m2

グラム／meter2（例えば単位体表面積当たりの薬物投与質量）

g/min

グラム／分

g.m/(hb)

グラム×メートル／心拍数（例えば心室のストローク仕事量）

g/(kg.hr)g/(8.kg.hr)
g/(kg.min)g(creat)（グラム×メートル／心拍数）／meter2=（グラム×メートル）／（心拍数×meter2）（例えば心室のストローク仕事量／体表面積（心室のストローク仕事の指標）*グラム、クレアチニン

g(hgb)*グラム、ヘモグロビン

g.m

グラムメーターg.m/((hb))．m2)

g(tot_nit)*グラム、窒素の合計

g(tot_prot)*グラム、タンパク質の合計

g(wet_tis)*グラム、湿重量組織

Gy

グレー（吸収された放射線量）

hL

ヘクタリットル=102リットル

H

ヘンリー

In

インチ

in_hg

水銀の（=Hg）のインチ

Iu

*国際単位

iu/d

*国際単位／日

iu/hr*国際単位／時間

iu/kg

国際単位／キログラム

iu/L*国際単位／リットル

iu/mL*国際単位／ミリリッター

iu/min*国際単位／分

j/L

ジュール／リットル（例えば呼吸仕事量）

Kat*Katalkat/g*Katal／キログラム

kat/L*Katal／リットル

k/ワット

1 ワット当たりケルビン(kcal

キロカロリー（1kcal=6.693 キロジュール）(kcal)/d*キロカロリー／日(kcal)/hr*キロカロリー／時間(kcal)/(8.hr)*キロカロリー／8 時間シフト

Kg
kg(body_wt)

キログラム*キログラム体重kg/m3キログラム／立方メーター

kh/hキログラム／時kg/Lキログラム／リットル

kg/minキログラム／分kg/molキログラム／モル© JAHIS 201637

コード／省略形
kg/s

名前
キログラム／秒

kg/(s.m2)（キログラム／秒）／meter2=キログラム／（秒×meter2）

kg/ms

1 平方メーター当たりキログラム

kg.m/sキログラム・メーター毎秒

Kpa

キロパスカル（1mmHg=0.1333kilopascals）

Ks

キロ秒

(ka_u)

キング-アームストロング単位(knk_u)*クンケル単位

L

リットル

L/d

*リットル／日

L/hr

リットル／時間

L/(8.hr)*リットル／8 時間シフト

L/kg

リットル／キログラム

l/min

リットル／分

L/s（リットル／分）／meter2=リットル／（分×meter2）（例えば、心拍出量／体表面積=心臓の指標）
リットル／秒（例えば、ピーク呼気流）

L.s

リットル／秒／second2=リットル×秒

L/(min.m2)

Lm

ルーメン

lm/m2

ルーメン／meter2(mclg_u)*マックレーガン単位

Ma

メガ秒

M

メーター

m2

meter2（例えば体表面積）m/s

メーター／秒m/s2

メーター／second2

Ueq*マイクロ当量Ug

マイクログラム

ug/d

マイクログラム／日

ug/dL

マイクログラム／デシリットル
マイクログラム／グラム

ug/g
ug/hr

*マイクログラム／時間

ug(8hr)マイクログラム／8 時間シフト

ug/kg

マイクログラム／キログラム

ug/L（マイクログラム／キログラム）／日=マイクログラム／（キログラム×日）（例えば 1 日当たり患者体重 1 キログラム当たりの薬物投与質量）（マイクログラム／キログラム）／時間=マイクログラム／（キログラム×時間）（例えば毎時の患者体重 1 キログラム当たりの薬物投与質量）（マイクログラム／キログラム）／8 時間のシフト=マイクログラム、／（キログラム×8 時
間のシフト）（例えば 8 時間のシフト当たりの患者体重 1 キログラム当たりの薬物投与質量）（マイクログラム／キログラム）／分=マイクログラム／（キログラム×分）（例えば毎分の患者体重 1 キログラム当たりの薬物投与質量）
マイクログラム／リットル

ug/m2

マイクログラム／meter2（例えば患者体表面 1 平方メートル当たりの薬物投与質量）ug/min

マイクログラム／分

uiu*マイクロ国際単位

ukat*Microkatelum

マイクロメートル（ミクロン）

umol

ミクロモル

umol/dミクロモル／日

umol/L

ミクロモル／リットル

umol/min

ミクロモル／分

mg/(kg.d)mg/(kg.hr)
mg/(8.hr.kg)
mg/(kg.min)© JAHIS 201638

コード／省略形

名前

us

マイクロ秒

uv

マイクロボルトmbar

ミリバール（1 ミリバール=100 パスカル）

mbar.s/L

ミリバール／（リットル／秒）=（ミリバール×秒）／リットル（例えば呼気性の抵抗）

meq

*ミリ当量

meq/d

*ミリ当量／日

meq/hr*ミリ当量／時間

meq/(8.hr)

ミリ当量／8 時間シフト

meq/kg

ミリ当量／キログラム（例えば患者体重 1kg 当たりのミリ当量での薬物投与量）

meq/(kg.d)（ミリ当量／キログラム）／日=ミリ当量／（キログラム×日）（例えば 1 日当たり患者体重1kg 当たりのミリ当量での薬物投与量）（ミリ当量／キログラム）／時間=ミリ当量、／（キログラム×時間）（例えば毎時の患者体
重 1kg 当たりのミリ当量での薬物投与量）（ミリ当量／キログラム）／8 時間のシフト=ミリ当量、／（キログラム×8 時間のシフト）（例えば 8 時間のシフトについての患者体重 1kg 当たりのミリ当量での薬物投与量）（ミリ当量／キログラム）／分=ミリ当量／（キログラム×分）（例えば毎分の患者体重 1kg
当たりのミリ当量での薬物投与量）

meq/(kg.hr)meq/(8.hr.kg)
meq/(kg.min)meq/L

ミリ当量／リットル

meq/m2

ミリ当量／meter2（例えば患者体表面積 1 平方メートル当たりのミリ当量での薬物投与量）

meq/min

ミリ当量／分

mg

ミリグラム

mg/m3

ミリグラム／meter3mg/dミリグラム／日mg/dL

ミリグラム／デシリットル

mg/hr

ミリグラム／時間

mg/(8.hr)

ミリグラム／8 時間シフト

mg/kg

ミリグラム／キログラム

mg/(kg.d)（ミリグラム／キログラム）／日=ミリグラム、／（キログラム×日）（例えば 1 日当たり患者体重 1kg 当たりの薬物投与質量）（ミリグラム／キログラム）／時間=ミリグラム／（キログラム×時間）（例えば毎時の患者
体重 1kg 当たりの薬物投与質量）（ミリグラム／キログラム）／8 時間シフト=ミリグラム／（キログラム×8 時間のシフト）（例えば 8 時間のシフトについての患者体重 1kg 当たりの薬物投与質量）mg/(kg.hr)
mg/(8.hr.kg)

mg/L（ミリグラム／キログラム）／分=ミリグラム／（キログラム×分）（例えば毎時の患者体重1kg 当たりの薬物投与質量）ミリグラム／リットル

mg/(kg.min)

mg/m2

ミリグラム／Meter2（例えば患者体表面積 1 平方メートル当たりの薬物投与質量）mg/minミリグラム／分mL

ミリリッターmL/cm_h20

ミリリッター／水（H20）のセンチメートル（例えば動的な肺コンプライアンス）

mL/d*ミリリッター／日

mL/(hb)

ミリリッター／心拍（例えば心拍出量）

mL/hr（ミリリッター／心拍数）／meter2=ミリリッター／（心拍数×meter2）（例えば心室の拍出量の指標）*ミリリッター／時間

mL/(8.hr)*ミリリッター／8 時間シフト

mL/kg

ミリリッター／キログラム（例えば患者体重 1kg 当たりの薬物投与あるいは処理の体積）

mL/(kg.d)（ミリリッター／キログラム）／日=ミリリッター／（キログラム×日）（例えば 1 日当たり
患者体重 1kg 当たりの薬物投与あるいは処理の体積）（ミリリッター／キログラム）／時間=ミリリッター／（キログラム×時間）（例えば毎時の
患者体重 1kg 当たりの薬物投与あるいは処理の体積）（ミリリッター／キログラム）／8 時間のシフト=ミリリッター／（キログラム×8 時間のシフト）（例えば 8 時間のシフトについての体重 1kg 当たりの薬物投与あるいは処理の体積）（ミリリッター／キログラム）／分=ミリリッター／（キログラム×分）（例えば毎分の患者
体重 1kg 当たりの薬物投与あるいは処理の体積）

mL/((hb)m2)

mL/(kg.hr)mL/(8.hr.kg)
mL/(kg.min)© JAHIS 201639

コード／省略形

名前

mL/m2

ミリリッター／meter2（例えば患者の体表面積当たりの薬物投与あるいは他の処理の体積）

mL/mbar

ミリリッター／ミリバール（例えば動的な肺コンプライアンス）

mL/minミリリッター／分

mL/s（ミリリッター／分）／meter2=ミリリッター／（分×meter2）（例えば体表面積についての規定された注入のミリリッター（酸素消費指標）
ミリリッター／秒

mm

ミリメートルmL/(min.m2)

mm(hg)*ミリメートル（HG）（1mmHg=133.322kilopascals）

mm/hr

ミリメートル／時間

mmol/kg

ミリモル／キログラム（例えば患者体重についての薬物治療のモル量）

mmol/(kg.d)

mmol/L（ミリモル／キログラム）／日=ミリモル／（キログラム×日）（例えば 1 日当たり患者体重についての薬物治療のモル線量）（ミリモル／キログラム）／時間=ミリモル／（キログラム×時間）（例えば毎時の患者体重についての薬物治療のモル量）（ミリモル／キログラム）／8 時間のシフト=ミリモル、／（キログラム×8 時間のシフト）（例えば 8 時間のシフトについての患者体重についての薬物治療のモル量）（ミリモル／キログラム）／分=ミリモル／（キログラム×分）（例えば毎分の患者体重についての薬物治療のモル量）
ミリモル／リットル

mmol/(kg.hr)
mmol/(8.hr.kg)
mmol/(kg.min)

mmol/hr

ミリモル／時間mmol/(8hr)

ミリモル／8 時間シフト

mmol/min

ミリモル／分mmol/m2

ミリモル／meter2（例えば患者体表面積についての薬物治療のモル量）

mosm/L*ミリオスモル／リットル

ms

ミリ秒

mv

ミリボルト

miu/mL*ミリユニット／ミリリッター

mol/m3モル／立方メーター

mol/kg

モル／キログラムmol/(kg.s)（モル／キログラム）／秒=モル／（キログラム×秒）

mol/L

モル／リットル

mo/s

モル／秒

ng

ナノグラム

ng/d

ナノグラム／日ng/hr*ナノグラム／時間

ng/(8.hr)

ナノグラム／8 時間シフト

ng/L

ナノグラム／リットル

ng/kg

ナノグラム／キログラム（例えば患者体重についての薬物治療の質量）ng/(kg.d)

ng/m2（ナノグラム／キログラム）／日=ナノグラム／（キログラム×日）（例えば 1 日当たり患者
体重についての薬物治療の質量）（ナノグラム／キログラム）／時間=ナノグラム／（キログラム×時間）（例えば毎時の患者
体重についての薬物治療の質量）（ナノグラム／キログラム）／8 時間のシフト=ナノグラム／（キログラム×8 時間のシフト）（例えば 8 時間のシフトについての患者体重についての薬物治療の質量）（ナノグラム／キログラム）／分=ナノグラム／（キログラム×分）（例えば毎分の患者体重についての薬物治療の質量線量）
ナノグラム／meter2（例えば患者体表面積についての薬物治療の質量）ng/(kg.hr)ng/(8.hr.kg)
ng/(kg.min)

ng/mL

ナノグラム／ミリリッター

ng/min*ナノグラム／分

ng/s*ナノグラム／秒

nkat*Nanokatel

nm

ナノメーター

nmol/s

ナノモル／秒ns© JAHIS 2016

ナノ秒

40

コード／省略形

名前nニュートン（力）n.sニュートン秒(od)*O.D.（光学濃度）

ohm

オーム（電気的な抵抗）

ohm.m

オーム・メーター

osmoleオスモル

osmole/kg

オスモル／キログラム

osmole/L

オスモル／リットル/m3*粒子／meter3/L*粒子／リットル/(tot)*粒子／総カウント(ppb)*10 億についていくつ(ppm)*100 万についていくつ(ppth)

1000 についていくつ(ppt)

1 兆（1012）についていくつ

pal

パスカル（圧力）/(hpf)*高出力項目について

(ph)

*pH

pa

ピコアンペア

pg

ピコグラム

pg/L

ピコグラム／リットル

pg/mL

ピコグラム／ミリリッター

pkat*Picokatelpm

ピコメーター

pmol

*ピコモル

ps

ピコ秒

pt

ピコテスラ

(pu)

*P.U。

%

パーセント

sec

Rem（ヒト線量等量）=10-2meter2／second2=decimeter2／second2 1 ラドの X 線またはガンマ線と等価な電離放射線の線量［Dorland 医学辞典から］
角度の秒

sie

ジーメンス（電気的なコンダクタンス）

sv

シーベルト

m2/s

平方メーター／秒

cm2/s

平方センチメートル／秒

dm2／s2T(td_u)

テスラ（磁束密度）
トッド・単位V

ボルト（電位差）

1

ボリューム部分Wb

ヴェーバー（磁束）*：星印のついている項目は純粋の ISO ではないが矛盾しない。
+：単位へのこのアプローチを IUPAC は推奨していない。我々は単に下位互換性のためここに残した。

表４は、共通の ISO 誘導単位の省略形を列挙する。それに含まれるものは、一般的な単位の標準の単位省略形（例えばミリ当量）、国際単位、mm（Hg）、そして数えるために除法記号によって示すもの、分母だけで分子のないもの、例えば／c、であって上記に引用した ISO 規格の一部でないものである。
我々は、単位表を拡張して、薬ルートおよび生理学上の測定量を一層受け入れ、またその他の方法でバージョン 2.2 のギャップを埋めた。
我々は、単位の定義において IUPAC1995 のシルバーブック 2 に一般に従った。しかしながら、IUPAC
は、単位を報告し表示するための基準を指定し、それらを識別するために 8 ビット・データセットを使用する。この規格は、患者情報の送信に関係がある。したがって、我々は大文字、小文字に無関係© JAHIS 201641

な英字、および少数の特殊文字（例えば、
「.」
、
「/」
、
「(」
、
「）
」
、
「*」
、および「_」）に限定して、送信中に起こりうる混乱を回避した。したがって、我々は ISO 2955-1983（情報処理－制限のある文字セットを持ったシステム中の、SI および他の単位の表現）、および ANSI X3.50-1986（制限のある文字
セットを持ったシステム中の、米国の慣習的な単位、SI および他の単位の表現）の、大文字、小文字に無関係の単位省略形を、それらが定義されている場合、使用する。これは、場合によっては IUPAC
省略形が ISO+と異なる省略形を持つことを意味する。例えば IUPAC 省略形が標準の英字だけを使用していたとしてもである。例えば、パスカルは IUPAC の中のでは Pa と略される。しかし ISO+（ISO2955 に従う）の中では PAL である。なぜなら Pa は大文字、小文字に無関係な表示として（Pa と）
見るとピコアンペアを意味するからである。しかしながら、送信用の要件は、エンドユーザに紙またはビデオで報告するプレゼンテーションのため IUPAC 基準を使用することを妨げない。
すべての単位省略形は大文字、小文字に無関係である。ミリリットルは、ML、ml あるいは mL と書くことができる。このテーブルでは、我々はすべての省略形に対して小文字を使用した。ただし L は大文字にした。数字の 1（1）と混同しないようにである。これは表示方法の変更であって規則の変更ではない。システムとしては通常どおり大文字または小文字で引き続き送信すべきである。
表 4： HL7 V2.5 7.18.3. HL7 表 - 7-9 「一般的な ISO 誘導単位および ISO 拡張子」を参照する。
[ローカルの単位コード]
ローカルコードは、
第 3 の成分の中で 99zzz のコード・ソースを示すことによって単位に使用できる。
ここで 99zzz は英数字の文字列である。ローカルコードの場合には、コードのテキスト名あるいは単位の記述も（第 2 の成分中で）送信されるべきである。その結果を受信システムが、別のサービスによって送られた同じ測定の結果と比較できるようにするためである（2 章の節 2.9「データ型」
を参照）。
「L」はコードがローカルに定義されることを示すために第 3 の成分に保存されるべきである。さらに特定化されたローカルコード指示も、CWE データ型定義中で指定されたように、使用できる。

OBX-7 References Range 基準値範囲 (ST) 00575
定義： 検査で有毒物質の量を計測する場合、範囲の上限により毒性限界を表す。検査で薬剤の量を計測する場合、下限により治療の期待できる最小量を表し、上限によりそれ以上の薬剤投与により通常副作用が発生しうることを表す。
a）
下限よりさらに下（下限と上限の両方が定義された場合。例えば、3.5―4.5 の様に記載する）b）>下限（もし上限がないならば、例えば>10）c）<上限（もし下限がないならば、例えば<15）
アルファベットの値：正常値はこの場所で報告される。

OBX-8 Abnormal Flags 異常フラグ (ID) 00576
定義： 結果の正常状態を示す。取りうる値については、使用者定義表 0078－異常フラグ－を参照。
検査室で、胸部 X 線あるいは微生物培養などのテキスト・レポートの正常状態を識別できる場合、正常な場合は N、異常な場合は A として報告すべきである。複数のコード（例えば異常と悪化）を報告する場合は、反復区切り文字（例えば A～W）により分離記述される。
使用者定義表0078
Value
L
H
LL
HH
<
>
N
A
AA
null
U
D
B
W

© JAHIS 2016

–Abnormal flags 異常フラグ

Description
Below low normal 基準値下限以下
Above high normal 基準値上限以上
Below lower panic limits パニック下限以下
Above upper panic limits パニック上限以上
Below absolute low-off instrument scale 測定限界下限未満
Above absolute high-off instrument scale 測定限界上限超
Normal (applies to non-numeric results) 正常（非数値結果に適用）
Abnormal (applies to non-numeric results) 異常（非数値結果に適用）
Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units) 非常に異常（数値単位のパニック値に対応するが、これは非数値単位に適用される）
No range defined, or normal ranges don't apply 範囲未定義、もしくは正常が適用されない
Significant change up 大幅な上昇変化
Significant change down 大幅な下降変化
Better--use when direction not relevant 改善－－方向が適用されない場合使用
Worse--use when direction not relevant 悪化－－方向が適用されない場合使用42

検査結果は、結果の正確な数値を指定せずに正常状態を報告することによってメモ書きによって報告されることができる。その場合、結果は、OBX-5－検査値の中で何らかの値を指定せずに、「OBX-8－異常なフラグ」中の正常コードを報告することで、OBX の中で報告できる。

OBX-9 Probability 確率 (NM) 00577
定義： 定性値を持つ結果の場合、結果が真である確率（結果が特定のコードとなる確率）を記述する。主として離散的コード化結果に適用される。0～1（0 と 1 を含む）の ASCII 文字列で表した 10進数である。

OBX-10 Nature of Abnormal Test 異常検査の特質 (ID) 00578
定義： 異常検査の特性を示す。例えば HL7 表 0080「異常検査の特質」では、年齢、性別および人種に基づいた正常値は、Ａ～Ｓ～Ｒとしてコード化されている。
コード表の使用上の制限は PID セグメント定義に制限される。
HL7表 0080 - Nature of Abnormal Testing 異常検査の特質
Value
A
N
R
S
SP
B
ST

Description
An age-based population 年齢別分布
None - generic normal range なし － 一般正常範囲
A race-based population 人種別分布
A sex-based population 性別分布
Species 種
Breed 交配
Strain 血統

OBX-11 Observe Result Status 検査結果状態 (ID) 00579
定義： 一つの検査項目についての検査結果完了状態を示す。取りうるコードについては、HL7 テー
ブル 0085－検査結果状態－を参照。
HL7表 0085 - Observation result status codes interpretation 検査結果状態コード解釈
Value
C
D
F
I
N

O
P
R
S
X
U
W

Description
Record coming over is a correction and thus replaces a final result 到着レコードは修正であり、結果を書き換える。
Deletes the OBX record OBX レコードを削除する。
Final results; Can only be changed with a corrected result. 最終結果： 修正結果でのみ変更可能。
Specimen in lab; results pending 臨床検査室の検体；結果保留
Not asked; used to affirmatively document that the observation identified in the OBX was not sought
when the universal service ID in OBR-4 implies that it would be sought
問い合わせなし。OBX-4 中の universal service UID からは検索可能と見えるが、OBX で指定された記載は検査されなかったことを知らせる。
Order detail description only (no result) 依頼詳細記述(結果無し)
Preliminary results 暫定結果
Results entered -- not verified 結果は保存済：未確認
Partial results 部分結果
Results cannot be obtained for this observation この検査では、結果は得られない。
Results status change to Final. Without retransmitting results already sent as ‘preliminary. 結果状態
を「暫定」としてすでに報告された結果を再送せず、結果状態を「最終」へ変更する
Post original as wrong, e.g., transmitted for wrong patient 元の結果を誤りと通知

OBX-12 Effective Date Last Obs Normal Value 最新検査正常値有効日付 (TS) 00580
成分: <Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義： 検査の有効期限を指定する。
例えば、旧方式で得られた値が新規方式で得られた値と比較できなくなる場合、そのような測定方法の変更を示す事が必要な場合などに使用する表すことを含んでいる。

OBX-13 User Defined Access Checks 使用者定義アクセス点検 (ST) 00581
定義： 実施者は、受信システムで検査を分類するために使用する結果依存コードを示す。これは、ほとんどの分類は固定の検査 ID 属性であり、関連検査マスターファイルで定義することができるので、この項目はめったに必要とされない© JAHIS 2016

43

OBX-14 Date/Time of the Observation 測定日時 (TS) 00582

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

定義： 測定（検査）が実施された日時である。
次の 2 つの状態で必要になる。
レポートーヘッダー（OBR）の下で報告された複数の検査が互いに異なる日付を持つ場合
OBX セグメントを依頼者から実施者へ送る場合の（依頼）検査日時。この検査の日付は要求検査の日付とはなんの関係もない。
患者に対して直接行われる測定（例えば X 線画像、病歴、身体測定）の場合には、検査日時は測定が行われた日時である。

OBX-15 Producer’s ID 実施者 ID (CWE) 00583

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

定義： 検査実施責任者の一意な識別子である。

OBX-16 Responsible Observer 検査責任者 (XCN) 00584

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

定義： 検査に直接責任を負う個人（検査を実行、もしくは検証した人）の識別子である

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

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

定義： 検査項目案内などで公表している検査方法と異なる検査方法を実施した場合、本フィールドに明示する。

OBX-18 Equipment Instance Identifier 装置識別 ID (EI) 01479

成分: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type
(ID)>

定義： このフィールドは検査に用いられる装置の識別ＩＤである。
これは、施設の装置マスタリストからきている識別 ID である。マスタリストにおいて施設はnamespace ID をもとに、もしくはそれがない場合は実施者 ID（OBX-15)をもとに識別される。装置
タイプ、シリアルナンバーなどの情報はマスタリストより取得することが可能であろうが、それらの情報を全ての OBX に格納して送信することを想定しているわけではない。このフィールドの繰り返
しにより、装置の階層構造を示すことができる（低階層が先）。つまり、装置のモジュール、モジュールで構成した装置、複数の装置をさらにまとめたクラスタなどである。

OBX-19 Date/Time of the Analysis 分析の日時 (TS) 01479

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

定義： OBX-18 装置識別 ID（Equipment Instance Identifier)で指定された機器による分析結果の発生日時を示す。

© JAHIS 201644

7.9. ORC - Order Common Segment 共通オーダセグメント
共通オーダセグメント(ORC)は、すべてのオーダに共通なデータ要素を伝達するために使用される(要求されるすべてのタイプのサービス)。場合によっては、ORC は文字列 ORC|OK|<依頼者オーダ番号>|<実施
者オーダ番号>|<CR>のように単純になる。
詳細内容がオーダのために必要ないならば、オーダ詳細セグメントは省略してよい。たとえば、オーダを保留するためには、ORC で次のフィールドを付けて伝達する(HD の値付きの ORC-1－オーダ制御、ORC-2－依頼者オーダ番号、および ORC-3 実施者オーダ番号)。
ORC のフィールドとオーダ詳細セグメントの中のフィールドとの間にいくつかの重複がある。これらは以下の節に述べる。原則として、ORC と OBR に重複する情報は、OBR セグメントのものを優先する。
ORC 使用注記a)依頼者オーダグループ
本規格では、複数のオーダを 1 つのグループに集めるメカニズムをサポートする。大抵の場合、これは 1人の患者に対して｢依頼セッション｣を表すために使用される。
オーダグループは、ORC-4-依頼者グループ番号に関連するオーダ(ORCs)のリストである。グループは、
依頼者が最初のオーダに依頼者グループ番号を付けた時に確立する。オーダグループは、同じ依頼者グルー
プ番号を有するすべての ORCs およびすべての詳細セグメントから成る。オーダは、グループからキャンセ
ルを使用して除去したり、取換えや親子メカニズムを使用して追加したりできる。新規オーダは、その他の方法でのグループへの追加はできない。
b)重複フィールド
ORC は、すべてのオーダ(すなわち要求されたサービス)に共通なフィールドを一様に定義するよう意図されている。ただし、一部の ORC フィールドは、一部のオーダ詳細セグメント(たとえば OBR、RXO)では重複する。たとえば、ORC-2 依頼者オーダ番号は、OBR-2 依頼者オーダ番号フィールドど同じ意味および目的を持つ。これによって過去のバージョンおよび ASTM との上位互換性が保たれる。
これらのフィールドを使用する規則では、ORC に現われない値はオーダ詳細セグメントに現われねばならない。しかし、両方の箇所に値を入れて混乱を避けることが望ましい。
c) 親／子 － キャンセル、保留、中断
親オーダのキャンセル、保留または中断の要求の伝達は、その要求は親オーダおよびすべての関連の子オーダに対して再帰的に適用されるよう意図されている。
例：
1)EKG アプリケーションが 3 回の EKG に対するオーダを受け、これが 3 日連続で毎朝行われるとする。
2)EKG アプリケーションは 3 つの子オーダを、各々の要求された EKG に対して 1 つずつ作成する。
3)元の親オーダを取消す要求が受取られた時に 1 日目の EKG が実施されていた。(親は取消せなかった)
4)残りの、未実施の子は要求の結果として取り消される。

HL7属性表－ORC－Order Common Segment 共通オーダセグメント
SEQ
1
2
3
4
5
6
7
8
9

LEN
2
22
22
22
2
1
200
200
26

DT
ID
EI
EI
EI
ID
ID
TQ
EIP
TS

OPT
R
C
C
O
O
O
B
O
O

Japan
R
R
O
O
O
O
X
C
R

RP/#

10
11

250
250

XCN
XCN

O
O

O
O

Y
Y

© JAHIS 2016

TBL#
0119

0038
0121
Y

45

ELEMENT NAME
Order Control オーダ制御
Placer Order Number 依頼者オーダ番号
Filler Order Number 実施者オーダ番号
Placer Group Number 依頼者グループ番号
Order Status オーダ状態
Response Flag 応答フラグ
Quantity/Timing 数量/タイミング
Parent 親
Date/Time of Transaction トランザクショ
ン日時Entered By 入力者
Verified By 検証者

SEQ
12
13
14

LEN
250
80
250

DT
XCN
PL
XTN

OPT
O
O
O

Japan
R
O
O

RP/#
Y

15
16

26
250

TS
CWE

O
O

O
O

17
18
19
20

250
250
250
250

CWE
CWE
XCN
CWE

O
O
O
O

O
O
O
O

21
22
23

250
250
250

XON
XAD
XTN

O
O
O

O
O
O

Y
Y
Y

24

250

XAD

O

O

Y

25
26

250
60

CWE
CWE

O
C

O
C

27

26

TS

O

O

28
29
30

250
250
250

CWE
CWE
CNE

O
O
O

O
O
O

TBL#

Y/2

Y
0339

0552

0177
0482
0483

ELEMENT NAME
Ordering Provider オーダ依頼者
Enterer's Location 入力場所
Call Back Phone Numberオーダ問い合わせ
電話番号
Order Effective Date/Time オーダ有効日時
Order Control Code Reason オーダ制御コ
ード理由Entering Organization 入力組織
Entering Device 入力装置識別Action By 発動者
Advanced Beneficiary Notice Code
事前保険金受給通知コード
Ordering Facility Name オーダ施設名
Ordering Facility Address オーダ施設住所
Ordering Facility Phone Number オーダ施
設電話番号
Ordering Provider Address オーダ提供者住所
Order Status Modifier オーダ状態変更
Advanced Beneficiary Notice Override
Reason 事前保険金受給通知上書き理由
Filler's Expected Availability Date/Time 実
施者可能日時Confidentiality Code 守秘モード
Order Type オーダタイプ
Enterer Authorization Mode 承認モード入力

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

Description
Order/service refill request
approval
補充オーダ要求承認© JAHIS 2016

Comment
Placer Applications.
AF は依頼者が補充または補充の量を許可する RF への応答である。

46

ValueCA

Description
Cancel order/service
requestオーダキャンセル要求

Comment
Placer Applications.
オーダキャンセルは、以前にオーダしたサービスを実施者に行わせないようにする依頼者からの要求である。キャンセル要求の確認は、実施者によって行われる、例えば、CR の ORC-1 オーダ制御値）を持つメッセージである。一般的な応答は、これらに限定されないが、以下のようなものが挙げられる、CR－要求通りオーダキャンセル完了、UC－オーダキャンセル不能。

CH

Child order/service
子オーダPlacer or Filler Applications.
PA とあわせて使用－親オーダコントロールコード。
詳細は PA オーダコントロールコードを参照。

CN

Combined result
統合検査結果Filler Applications.
統合検査結果コードは、複数のオーダに関連する結果を送るためのメカニズムを提供する。この状態は、医師が通常複数のオーダで表示された複数の検査に対して単一のレポートを作成するときのレポートに見られる。例えば、医師はリューマチ性の関節炎患者のひざと手のフィルムに対してひとつのレポートを生成することがある。
その結果報告のときに、最後の ORC を除く RE はすべて CN コードに置換される、結果は最後のORC とその OBR に続く。以下 3 つの ORC に対する単一のレポート例は下記の通りである。
MSH|...<cr>
PID|...<cr>
ORC|CN|...<cr>
OBR|1|A4461XA^HIS|81641^RAD|73666^Bilateral Feet|...<cr>
ORC|CN|...<cr>
OBR|2|A4461XB^HIS|81642^RAD|73642^Bilateral Hand PA|...<cr>
ORC|RE|...<cr>
OBR|3|A4461XC^HIS|81643^RAD|73916^Bilateral Knees|...<cr>
OBX|1|CE|73916&IMP|1|Radiologist's Impression|...<cr>
OBX|2|CE|73642&IMP|1|Radiologist's Impression|...<cr>
OBX|3|FT|73642&GDT|1|Description|...<cr>

CRCanceled as requested
要求通りオーダキャンセ
ル完了

Filler Applications.
キャンセル（依頼者アプリケーションからの CA）の要求が成功したことを示す実施者アプリケー
ションからの応答

DC

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

Placer Applications.
実施者アプリケーションに前もって要求したサービスを中断するための依頼者アプリケーションからの要求。中断とキャンセルの違いとして、中断はオーダ／サービスおよび今後起こるすべての動作に影響、キャンセルは現在のアクションだけに影響する。
一般的な応答は、これらに限定されないが、以下のようなものが挙げられる、CR－要求通りオー
ダキャンセル完了、UC－オーダキャンセル不能DEData errors
データエラー

Placer or Filler Applications.

DF

Order/service refill request
denied補充オーダ要求拒否

Placer Applications.
補充許可(RF)に対する実施者アプリケーションの応答、DF は依頼者がオーダの補充を許可しないことを意味する。ORC-16 オーダ制御コードの理由は要求拒否の理由を意味する。提案された値は以下を含む：AA

Patient unknown to the provider
患者は療養提供者に知られていない。
AB
Patient never under provider care
患者は療養提供者の療養を受けたことがない
AC
Patient no longer under provider care
患者はもはや療養提供者のもとにない
AD
Patient has requested refill too soon
患者の補充要求が頻繁すぎる
AE
Medication never prescribed for the patient
患者の薬は一度も処方されていない
AF
Patient should contact provider first
患者は最初に療養提供者に連絡せねばならないAG
Refill not appropriate
補充は適していない
注：これらの値は NCPDP SCRIPT 応答セグメントコードリストに由来する。
資料の複製は©National Council for Prescription Drug Programs, Inc. （米国規格協会認定の機関）
1988, 1992, 2002 NCPDP の承諾を得てください。
DR

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

Filler Applications.
実施者は、中断（依頼者アプリケーションからの DC）の要求に応じて、オーダ／サービスを中断する。

47

ValueFU

Description
Order/service refilled,
unsolicited
補充オーダ済、未承諾

Comment
Filler Applications.
FU は依頼者に実施者が患者要求のオーダに対して補充を発行したことを通知する。

HD

Hold order request
オーダ保留要求

Placer Applications.
一般的な応答は、これらに限定されないが、以下のようなものが挙げられる、CR－要求通りオー
ダキャンセル完了、UC－オーダキャンセル不能。

HR

On hold as requested
要求通りオーダ保留Filler Applications.

LI

Link order/service topatient care problem orgoal
患者看護プロブレムまたはゴールへのリンクオー
ダ
Number assigned
番号が割り当て済

Placer or Filler Applications.
本規約では取り扱わない。
詳細は HL7 Ver.2.5 第 12 章：患者看護を参照。

NA

Placer Applications.
オーダ番号の要求に関与する 3 つの状態がある（ORC-2－依頼者オーダ番号または ORC-3－実施
者オーダ番号）。
(1) 実施者アプリケーションが、例えば、HIS のような中央型アプリケーションから ORC-3－実施者オーダ番号を要求する必要があるとき。
SN－送信オーダ番号コードは、実施者が集中アプリケーション（下記の表で “other” と呼ばれている） 例えば、中央 HIS から ORC-3－実施者オーダ番号を要求するためのメカニズムを提供する。これは SN の ORC-1－オーダ制御値を含んでいる ORM メッセージを送ることによって行う。
この ORC は null の ORC-3－実施者オーダ番号と ORC-2－依頼者オーダ番号を持つ。これらは実施者がオーダを開始するとき、実施者アプリケーションによって作成されたものである。
OMG(SN 型)メッセージは、以下の 2 つの方法によって応答される：
OK の OR C-1-オーダ制御値を含んでいる ORG メッセージによる。要求されなかった OMG メッ
セージは、NA の ORC-1-オーダ制御値つきの ORC を含んでいて、後のある時間に送られる。
以下で述べる NA の ORC-l-オーダ制御値を含んでいる ORG メッセージによって実現できる。
Code

From

ORC-2-Placer
ORC-3-Filler
Order Number
Order NumberSNfiller application
placer ordernull
number^filler
application ID
NAother application
placer orderfiller ordernumber^filler
number^filler
applica ion ID
application ID
Note: Both the placer order number and the filler order number have the filler's
application ID
注：依頼者オーダ番号と実施者オーダ番号は実施者のアプリケーション ID を持ちます。
(2) 実施者アプリケーションはその他のアプリケーション（例：オーダエントリ）から ORC-2 依
頼者オーダ番号を要求する必要があるとき
SN －送信オーダ番号コードは、実施者アプリケーションが ORC-2－依頼者オーダ番号をその他のアプリケーション（下記表で“other”と記載）から要求するためのメカニズムを提供する。これはSN の ORC-1－オーダ制御値を含みオーダメッセージを送ることによって行う。この ORC は nullの ORC-2－依頼者オーダ番号と ORC-3－実施者オーダ番号を持つ。これらは実施者がオーダを開始するとき、実施者アプリケーションによって作成されたものである。
OMG(SN 型)メッセージは、2 つの方法によって応答される：
OK の ORC-1-オーダ制御値を含んでいる ORG メッセージによって。要求されなかった OMG メ
ッセージは、NA の ORC-1-オーダ制御値つきの ORC を含んでいて、後のある時間に送られる。
以下で述べる NA の ORC-l-オーダ制御値を含んでいる ORG メッセージによって。
NA －コードを割り当てられた番号は、“other”アプリケーションが新しく割り当てられた ORC-2－依頼者オーダ番号を実施者アプリケーションに知らせることを許す。ORC は NA の ORC-1－オ
ーダ制御値、新しく割り当てられた ORC-2－依頼者オーダ番号、および ORC-3－実施者オーダ番
号（SN 値を持つ ORC から）を含む。
CodeSN© JAHIS 2016

Fromfiller application48

ORC-2-Placer
Order Numbernull

ORC-3-Filler
Order Number
filler orderValueDescription

Comment
number^filler
application ID
NAother application
placer or filler
filler ordernumber^placer
number^filler
application ID
application ID
Note: The new ORC-2-placer order number has the placer's application ID
注：新しい ORC-2 依頼者のオーダ番号は依頼者のアプリケーション ID を持ちます。
3) アプリケーション（実施者アプリケーションではない）が、新規オーダの ORC-3 実施者オーダ番号を割り当てたい場合。
NW －オーダを作成するアプリケーション（実施者アプリケーションではない）が、新規オーダの実施者オーダ番号を割り当てたいとき。
またはRO －（RP に続く RO）この場合、“other”のアプリケーションが ORC3－実施者オーダ番号を完成する。このときには実施者オーダ番号の 2 番目の項目として、実施者アプリケーション ID を使
用する。
Code
From
ORC-2-Placer
ORC-3-Filler
Order Number
Order Number
NW or
Other
placer orderfiller orderROapplication to filler
number^placer
number^filler
application
application ID
application ID

NW

New order/service
新規オーダPlacer Applications.
NA のコメントを参照－割り当て番号【生理】ORC(PA)を記述する前に ORC(NW)を記述する。
ORC(NW)
新規オーダ
ORC(PA)
親オーダ
OBR
親オーダの記述
ORC(CH)
１番目の子オーダ
OBR
１番目の子オーダの記述
ORC(CH)
２番目の子オーダ
OBR
２番目の子オーダの記述

OC

Order/service canceled
オーダキャンセル完了

Filler Applications.

OD

Order/service
discontinued
オーダ中断

Filler Applications.

OE

Order/service released
オーダ開放Filler Applications.

OF

Order/service refilled as
requested
要求通り補充オーダ済

Filler Applications.
OF は依頼者システムからの補充要求に直接応答する。

OH

Order/service held
オーダ保留

Filler Applications.

OK

Order/service accepted &OKオーダ受付&OK

Filler Applications.
NA のコメントを参照－割り当て番号

OP

Notification of order foroutside dispense
外部調剤へのオーダ通知

Placer Applications.
これらオーダ制御コードはオーダが情報提供目的とされるシステム間でオーダを通信するために使用される。例えば、通信システムの企業外部のベンダーによってオーダは実行される。通信シ
ステムでは、臨床継続性のためのオーダに関連した情報の維持が必要であるが、オーダされたサービスを実行するアクションを意図するものではない。
OP は NW の情報提供バージョンを表す。PY は RO だけの情報提供バージョンといえる。NW とRO の表注記は OP と PY それぞれにも適用できる。

OR

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

Filler Applications.

PA

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

ValueDescription

Commentのときセグメントの順序は、次の通りである
Segment
Order Control
Comment
ORC
PA
1st parent ORC
ORC

CH

OBR

1st child ORC
1st child order

ORC

CH

OBR

2nd child ORC
2nd child order

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

Previous Results with neworder/service
以前の結果

Placer Applications.
PR は ORC がオーダに組み込まれた過去の検査を含む ORU 構造の一部だと示す。
少なくとも 2 つの主要なユースケースは、過去の検査の完了結果をそのオーダとともに転送されるために必要とする。
• 診断検査室が結果（HIV 等）の確認あるいは検査（遺伝子検査等）を行う設備がない等で他の検査機関に検査を問い合わせる。
• 診断検査室が検査報告に含まれる診断コメントの自動生成のための知識ベースに結果を送る。

PY

Notification of replacement
order for outside dispense
外部調剤へのオーダ修正
通知© JAHIS 2016

Placer Applications.
OP（外部調剤へのオーダ通知）のコメントを参照。

50

ValueRE

Description
Observations/Performed
Service to follow
検査付帯情報Comment
Placer or Filler Applications.
検査付帯情報コードはオーダとともに患者固有情報を送るのに使用される。オーダ詳細セグメン
ト（例えば、OBR）の後には 1 個またはそれ以上の検査セグメント(OBX)を続けることができる。
ORU メッセージとして伝えることができるいかなる検査情報も、このメカニズムで伝えることができる。オーダとともに結果が送られる際は、サポートするためオーダの直後に結果が次にくる。
次の例は、3 個の処方オーダのためのセグメントのシーケンスを、RE コードの使用例で示す。
Segment
Order Control
Comment
MSH
PID
ORC
NW
First new order
RXO
First order segment
ORC
RXO
[ORC
OBR]
OBX
OBX
OBX
OBX

NW

ORC
RXO

NW

RE

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

HL7 のこのバージョンにおいて、結果は 1 個あるいはそれ以上の OBX セグメントとしてオーダとともに送ることができる。ただし ORC と OBR セグメントを必ずしも含む必要はない。
検査情報は ORC を使用せずに ORU メッセージを用いて伝えることができる。
ORU メッセージの OBR セグメントに含まれない情報を伝える必要が生じるときがある。この場
合、ORC が ORU メッセージに含まれていることを推奨する。
オーダ制御値RE はオーダの後に検査結果(OBX)が続くことを示すためにOMG メッセージにおいてのみ要求される。RE コードは ORU メッセージでは必要ではない。なぜなら OBR セグメントの後に検査結果(OBX)を続けることができるからである。
RF

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

Placer or Filler Applications.
RF は実施者または依頼者のどちらかによる要求を受け入れる。実施者は依頼者からの補充許可を要求することができる。依頼者システムは、補充が実施者システムによって行われるよう要求することができる。
標準的な応答は、これらに限定されないが、以下のようなものが挙げられる。実施者要求に関しては AF－補充オーダ要求承認、DF–補充オーダ要求拒否; 依頼者要求には、RE－検査付帯情報、
UF－補充不能RL
RO

Release previous hold
前回保留オーダ開放
Replacement order
修正後オーダPlacer Applications.
Placer or Filler Applications.
オーダ修正依頼は以前に依頼された 1 個以上のオーダの置き換えである。
修正されたオーダはあたかも取り消されたオーダのように扱われる。依頼されたサービスが取り換えられるかどうか、いつ修正されるかは、現場独自で決定する。
オリジナルのオーダが元の状態を保つことをサイトが要求するならば、親／子オーダ制御コードを使用する。以下の場合は、オーダ修正コードを使用しない。
修正される各オーダには RP（実施者に対するオーダ修正依頼）の ORC-1－オーダ制御値またはRU（実施者によって作成された未承認オーダ修正）を使用すること。RU は実施者によって使用され、依頼者および、または他のシステムに通知するためのものである。現場での取り決め(local
agreement)によって、ORC セグメント（RP または RU と）の後には、そのオリジナルのオーダ
詳細セグメントが続いてもよい。ORC セグメント（RP または RU を含む）の後には、RO（修正後オーダを示す）の ORC-1－オーダ制御値を持つ、ORC セグメントが続かなければならない。現場での取り決めによっては、RO 値を持つ ORC は、オーダ詳細セグメントが後に続いてもよい。
例えば、部門のアプリケーションが 2 個の OBR オーダを 3 つの異なったオーダで修正されていたと仮定して、セグメントの順序は、次の通りになる。

© JAHIS 2016

51

ValueDescription

Comment
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（要求どおりオーダ修正）となる。
Segment
ORC
OBR

Order Control
RQ

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

ORC
OBR

RQ

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

ORC
OBR

RO

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

ORC
OBR

RO

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

ORC
OBR

RO

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

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

Order/service replacerequestオーダ修正要求© JAHIS 2016

Placer Applications.
オーダ修正依頼は、以前に依頼された、1 個あるいはそれ以上のオーダの置き換えである。今後の議論のためには、RO–修正後オーダのコメントを参照

52

ValueDescription

Comment
オーダ修正要求コードは依頼者アプリケーションの要求に応じて、実施者が 1 個あるいはそれ以上の新規オーダを 1 個あるいはそれ以上の新規オーダと取り換えることを許可する。
RO の制御値を持つ ORC セグメントのオーダ番号の規則は修正型（RP または RU）によって決定される。
RU 型（すなわち実施者からの未承諾オーダ修正）のときには、実施者オーダ番号は、実施者アプ
リケーションによって通常生成される。依頼者オーダ番号は、RU のオーダ制御値つきの最初に送られた ORC の依頼者オーダ番号と全く同一である。
RP 型（すなわち別のアプリケーションから実施者へのオーダ修正要求）のときには、依頼者オーダ番号は、新規オーダのための手続きを使用して、依頼者アプリケーションによって生成される。
実施者オーダ番号は、新規オーダと同一の手順を使用して、実施者アプリケーションによって生成される。
修正シーケンスが ORU メッセージ（すなわち検査結果報告の間に）において使用されるときの、
オーダ修正に使用されるべき推奨セグメントを以下に述べる。
オーダ制御値 RO の ORC
任意の OBR セグメント（任意のオーダ詳細セグメントによって変えられる）
任意に、検査結果セグメント(OBX)が後に続くNTE セグメントは、OBR（あるいはいかなるオーダ詳細セグメント）後、あるいは、通常の ORU
メッセージにおけるのと同様に OBX セグメントの後に続けられる。

RQ

Replaced as requested
要求通りオーダ修正

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

RR

Request received
要求受付

Placer or Filler Applications.
旧バージョンとの互換性のため。現在のバージョンにおいては ACK（確認応答）の受諾に等しい。
要求受信コードはオーダメッセージが受信されて、後で処理されることを示す。すなわち、そのオーダはより正確な応答をするための処理をまだ実行していないということである。

RU

Replaced unsolicited
未承諾オーダ修正

Filler Applications.
オーダ修正依頼は以前に依頼された、1 個あるいはそれ以上のオーダの置き換えである。今後の議論のためには RO–修正後オーダのコメントを参照。
未承諾オーダ修正コードは依頼者アプリケーションから要求されることなしに実施者アプリケー
ションが別なアプリケーションに知らせることを許可する。

© JAHIS 2016

53

ValueDescription

Comment
RO の制御値を持つ ORC セグメントのオーダ番号の規則は取り換え型（RP または RU）によって決定される。
RU 型（すなわち実施者からの未承諾オーダ修正）のときには、実施者オーダ番号は実施者アプリ
ケーションによって通常生成される。依頼者オーダ番号は RU のオーダ制御値つきの最初に送られた ORC の依頼者オーダ番号と全く同一である。
RP 型（すなわち別のアプリケーションから実施者へのオーダ修正要求）のときには、依頼者オーダ番号は、新規オーダのための手続きを使用して、依頼者アプリケーションによって生成される。
実施者オーダ番号は、新規オーダと同一の手順を使用して、実施者アプリケーションによって生成される。
取り換えシーケンスが ORU メッセージ（すなわち検査結果報告の間に）において使用されるときの、オーダ修正に使用されるべき推奨セグメントを以下に述べる。
オーダ制御値 RO の ORC
任意の OBR セグメント（任意のオーダ詳細セグメントによって変えられる）
任意に、検査結果セグメント(OBX)が後に続くNTE セグメントは、OBR（あるいはいかなるオーダ詳細セグメント）後、あるいは、通常の ORU
メッセージにおけるのと同様に OBX セグメントの後に続けられる。

SC

Status changed
状態変更

Placer or Filler Applications.

SN

Send order/service
number
送信オーダ番号Placer Applications.
NA のコメントを参照－割り当て番号

SR

Response to sendorder/service status
request
送信オーダ状態要求応答

Filler Applications.

SS

Send order/service status
request
送信オーダ状態要求

Placer Applications.

UA

Unable to accept
order/service
受付オーダキャンセル

Filler Applications.
オーダ受付不可コードが使用されるのは新しいオーダを実施者が受付できないときである。受付できない理由としては患者がアレルギーを起こす薬剤の処方を要求したこと、またはそのオーダを実施するための機器が利用できないこと（例えば、オーダが記入できないなど）が考えられる。
これは MSA セグメント内で定義される通信レベルでの受付とは異なることに留意すること。

UC

Unable to cancel
オーダキャンセル不能

Filler Applications.
オーダキャンセル不能コードは依頼されたサービスが実施者によって取り消せない時点にあるとき、あるいは現場の取り決めで実施者によるキャンセルを禁止するとき使用される。このコードの使用は ORC-6－応答フラグに従う。

UD

Unable to discontinue
オーダ中断不能

Filler Applications.

UF

Unable to refill
補充不能Filler Applications.
UF は実施者システムが RF－許可補充要求／サービス要求に対して否定応答で、受信アプリケー
ションが補充要求を完了できないことを示す

UH

Unable to put on holdオーダ保留不能

Filler Applications.

UM

Unable to replace
オーダ修正不能Unlink order/service frompatient care problem orgoal
患者看護プロブレムまたはゴールからのリンクオーダ解除Filler Applications.

UN

UR
UX
XO

Unable to release
オーダ開放不能Unable to change
オーダ変更不能Change order/service© JAHIS 2016

Placer or Filler Applications.
詳細は HL7 Ver.2.5 第 12 章：患者看護を参照。

Filler Applications.
Filler Applications.
Placer Applications.

54

ValueDescription
requestオーダ変更要求

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

XR

Changed as requested
要求通りオーダ変更

Filler Applications.

XX

Order/service changed
unsolicited.
オーダ変更（未承諾）Filler Applications.

MC

Miscellaneous Charge –not associated with anorder
雑費－オーダとは関連なし

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

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

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

定義： 依頼アプリケーションのオーダ番号
第 1 成分は、個々のオーダ(たとえば、(OBR))を識別する文字列である。それは、依頼者（依頼ア
プリケーション）によって割り当てられる。それは、特定の依頼アプリケーションからのすべてのオーダの中から一意に一つのオーダを識別する。第 2 成分は依頼アプリケーションのアプリケーション
ID を含む。アプリケーション ID は、アプリケーションに一意に関連する 6 つの文字までの文字列である。ひとつの施設または相互に通信する施設のグループは、アプリケーションで一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプリケーション
ID を割り当ててもよい。2 つの成分は、共通の区切り文字によって分離される。
このように一意ではなく、真の依頼者がいくらかあいまいな 3 つの状態がある。
a) RU 取替えに続く、RO の ORC-1-オーダ制御値の場合；b) CH（子オーダ）の ORC-1-オーダ制御値の場合；
c) SN（番号を送ること）の ORC-1-オーダ制御値の場合；
ORC-2-依頼者オーダ番号がこれらの場合どのように割り当てられるかの詳細については、ORC-1オーダ制御の下のテーブルの注を参照すること。
ひとつの施設または相互に通信する施設のグループは、アプリケーションで一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプリケーション ID を割り当ててもよい。アプリケーション ID リストは、本規格の他の箇所で文書化されている、施設のマスタ辞書の 1 つになる。第三者アプリケーション（オーダの依頼者および実施者以外）が OMG と
ORG のメッセージ送受信ができるので、このフィールドの依頼アプリケーション ID は、ネットワー
ク上の送信および受信アプリケーションと同じでなくともよい（MSH セグメントにおいて述べた）。
ORC-2-依頼者オーダ番号は、OBR-2-依頼者オーダ番号と同じある。依頼者オーダ番号が ORC の中に存在していないならば、それは関連した OBR 内に存在しなければならない。その逆もまた真である。
もし両方のフィールド、すなわち ORC-2-依頼者オーダ番号および OBR-2-依頼者オーダ番号が設定されるならば、それらは同じ値でなければならない。結果が ORU メッセージで送られるとき、ORC は必要ないが、依頼者オーダ識別番号が OBR セグメント内に存在せねばならない。
これらの規則は、上位互換性のため ORC と OBR の両方の中に存在している他のフィールドにも適用する。(たとえば、数量/タイミング、親番号、オーダ依頼者、および依頼オーダ問い合わせ電話番
号)。

© JAHIS 2016

55

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

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

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

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

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

定義： オーダ依頼アプリケーションが複数セットのオーダを一緒にグループ化して後でそれらを識別できるようにする。
第1成分の文字列がすべての他のオーダグループを特定の依頼アプリケーションから一意に識別する。それは依頼アプリケーションによって割り当てられて、ORC の依頼者オーダ番号と同じシリーズでもよいが、これは必須ではない。
第 2 成分は、依頼アプリケーション ID であり、これは ORC-2-依頼者オーダ番号の第 2 成分と同じである。

ORC-5 Order Status オーダ状態 (ID) 00219
定義：オーダの状態。取りうる値については HL7 表 0038-オーダ状態を参照すること。このフィール
ドの目的は、要求された場合または状態が変更になった場合に、オーダの状態を報告することであり、オーダ自体を処理する事ではない。オーダ状態は、メッセージが送られるとき送信アプリケーションに知られていた状態を反映させる。実施者だけがこのフィールドに値を付けることができる。
HL7 表 0038 に示すオーダ状態は、HL7 表 0119-オーダ制御と同じ様な内容を含んでいるが、目的は異なる。オーダ状態は、ORC-1-オーダ制御値の SR または SC において典型的に使用される。これはオーダの状態を、要求を受けた時または当事者に随時報告するためである。

© JAHIS 201656

ORU メッセージの検査ステータス通知で使用する値については、OBR-25 項の「OBR-25 と ORC-5の組合せによる検査ステータス」を参照のこと。
HL7表 0038 - Order status オーダ状態
Value
A
CA
CM
DC
ER
HD
IP
RP
SC

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

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

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

ORC-7 Quantity/Timing 数量/タイミング (TQ) 00221
定義：（このフィールドは下位互換を保つ目的のためだけに残されている）TQ1 セグメントを参照のこと。

ORC-8 Parent 親 (EIP)00222

成分：<Placer Assigned Identifier (EI)> ^ <Filler Assigned Identifier (EI)>

定義：親子のメカニズムの関係が存在するとき子を親に関係付ける。親子のメカニズムは、ORC-1オーダ制御の注のところで述べられる。第 1 成分は、親オーダの依頼者オーダ番号を含んでいる。それは、オーダが子であるとき要求される。
第 2 成分は、親オーダの実施者オーダ番号を含んでいる。
依頼者オーダ番号と実施者オーダ番号との成分は、このフィールドの 2 つの成分の副成分として送られる。ORC-8-親は、OBR-29-親と同じである。

ORC-9

Date/Time Of Transaction トランザクション日時 (TS) 00223

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

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

ORC-10 Entered By 入力者 (XCN) 00224

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

定義： 要求をアプリケーションに実際に打鍵した人の所属氏名。それは、要求が不正確に入れられ、関連部門が要求を明らかにする必要がある場合、監査証跡となる。現場の取り決めによって、ID 番
号または名前成分は、省略されてもよい。
要求をアプリケーションに実際に打鍵した操作者の ID。

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

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

定義： 入れられた要求の精度を検証した人の所属氏名。それが使用されるのは、要求が技師によって入力され、看護婦などのより高い権威者によって検証される必要がある場合である。現場の取り決めによって、ID 番号や名前成分は、省略されてもよい。

ORC-12 Ordering Provider オーダ依頼者 (XCN) 00226

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

定義： 要求を作成することに責任がある依頼する医師などの所属氏名。ORC-12-オーダ依頼者は、
OBR-16-オーダ依頼者と同じである。
要求を作成することに責任がある依頼する医師など ID。
【生理】では必須とする。

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

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

定義： 要求を入力した人の場所(たとえば、部門、階)。それは、部門のあるサブカテゴリーを含むためサイト固有のベースに基づいて使用されてもよい複合フィールドである。たとえば、ICU4 は、4階の ICU の場所の呼称とするなど。
入力者の場所のデータ型は PL 型なので、入院の場合、<病棟コード>^<病室コード>^<ベッド番号>^^^N
外来の場合<科コード>^^^^^Cと設定することにし、person location type の指定を必須とした。
person location type には、C：診療科、D：部門、N：病棟を設定する。

ORC-14 Call Back Phone Number オーダ問い合わせ電話番号 (XTN) 00228

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

定義：要求またはオーダに関して、必要な他の情報を確認するための電話番号。ORC-14-オーダ問い
合わせ電話番号は、OBR-17-オーダ問い合わせ電話番号と同じである。

© JAHIS 2016

58

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

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

定義：変更要求が有効になった、あるいは、有効になる予定の日時。
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 オーダ制御コード理由 (CWE) 00230

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

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

ORC-17 Entering Organization 入力組織 (CWE) 00231

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

定義： 入力者がオーダを入力/修正した時に属していた組織

ORC-18 Entering Device 入力装置識別 (CWE) 00232

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

定義： オーダを入力するため使用された物理的装置(端末や PC)の識別子

ORC-19 Action By 発動者 (XCN) 00233

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

(ID)> ^ <Effective Date (TS)> ^ <Expiration Date (TS)> ^ <Professional Suffix (ST)> ^<Assigning Jurisdiction (CWE)> ^ < Assigning Agency or Department (CWE)>

定義： 対応するオーダ制御コードによって表されたイベントを発動した人の所属氏名。たとえば、オーダ制御コードが CA（オーダキャンセル依頼）であるならば、このフィールドは、オーダキャン
セルを要求した人を表す。

ORC-20 Advanced beneficiary notice code 事前保険金受給通知コード (CWE) 01310

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

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

Description
Service is subject to medical necessity procedures 医療サービスは、医学的に必要である。

2

Patient has been informed of responsibility, and agrees to pay for service 患者は支払いの義務があり，それを通知されている

3

Patient has been informed of responsibility, and asks that the payer be billed 患者は支払い責任を通知され、保険会社に請求を送るように依頼している

4

Advanced Beneficiary Notice has not been signed 患者が医療保険受取人あてに事前通告書に署名していない

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

成分： <organization name (ST)> ^ <organization name type code (IS)> ^ <ID Number (NM)> ^<check digit (NM)> ^ <code identifying the check digit scheme employed (ID)> ^ <assigningauthority (HD)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)> ^ <namerepresentation code (ID)>

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

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

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

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

ORC-23 Ordering facility phone number オーダ施設電話番号 (XTN) 01313
成分：[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)>^ <telecommunication equipment type (ID)> ^ <email address (ST)> ^ <country code (NM)> ^<area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>

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

ORC-24 Ordering provider address オーダ提供者住所 (XAD) 01314

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

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

ORC-25 Order status modifier オーダ状態変更 (CWE) 01473

成分： <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ID)> ^ <alternate identifier (ST)>^ <alternate text (ST)> ^ <name of alternate coding system (IS)> ^ <coding system version ID(ST)> ^ alternate coding system version ID (ST)> ^ <original text (ST)>

定義： このフィールドは、ORC-5 オーダ状態の変更，または、再生を記述する。定義されたオーダ
状態コードの追加のレベル特性、もしくは追加の情報を提供する為に使われる。このオーダ状態はHL7 により定義されたものとは異なり、AP により状態コードを任意に設定できる。データタイプはCWE である。
使用規則：このフィールドは ORC-5 状態が指定されていれば 使用される。

ORC-26 Advanced beneficiary notice override reason 事前保険金受給通知上書き理由 (CWE)01641
成分： <Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier(ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System
Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

定義： このフィールドは、患者が受益者注意コードにサインしない理由を含む。理由はコード化されるか或いは自由なテキスト形式で入力される。
条件：このフィールドは ORC-20 事前保険金受給通知コードの値が、通知にサインされていない場合に要求される。
例えば、ORC-20 が HL7 表 0339―事前保険金受給通知コードに 3 或いは 4 の値が入力されている
場合、または、関連する外部コード表で同様の値は入力されている場合、追加の資格或いは説明のための情報が正しい値として認められる。

ORC-27 Filler's Expected Availability Date/Time 実施者サービス可能日時 (TS) 01642
成分：<Time (DTM)> ^ <DEPRECATED-Degree of Precision (ID)>

定義： このフィールドは、実施者がサービス可能な日時を指定する。例えば、処方箋が受け取り可能或いは研究結果が可能となる場合に記述する。

ORC-28 Confidentiality Code 守秘コード (CWE) 00615

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

定義：このフィールドは、オーダを取り巻くセキュリティレベル又或いは注意度に関する情報を含む。
（例えば厳重注意、注意不要、注意など）。可能な値に関しては、 HL7 表 0177 – 守秘コード を参照のこと。特別な守秘レベルを持つデータの処理に関しては、現場特殊な交渉に委ねる。
HL7表 0177 – Confidentiality Code 守秘コード
Value
AID
EMP
ETH
HIV
PSY
R
U
UWM
V
VIP

Description
AIDS patient AIDS 患者
Employee 従業員
Alcohol/drug treatment patient アルコール／薬物中毒治療患者
HIV(+) patient HIV(+)患者
Psychiatric patient 精神医学患者
Restricted 限定
Usual control 通常管理
Unwed mother 未婚の母
Very restricted 非常に限定
Very important person or celebrity 重要人物や名士

Comment

ORC-29 Order Type オーダタイプ (CWE) 01643

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

定義： このフィールドは、オーダが入院患者にセット、あるいは外来患者にセットされ実行されるかどうかを示している。もし、このフィールドが値を持っていなければ、システムのデフォルト値がとられる。推奨値に関しては、 HL7 表 0482 – オーダタイプを参照のこと。

© JAHIS 201661

オーダの入外区分は ORC-29 で示す。O：外来あるいは、I：入院を設定する。入外区分の設定は必須である。
例：理学療法を続行するために発行されるオーダを取り消す前に、或いは地域薬局で処方箋をもらうオーダを取り消す前は、その患者は、PV1 によると入院患者だが、そのオーダ自体は外来患者に発行される場合。
HL7表 0482 – Order Type オーダタイプ
Value
I
O

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

Comment

ORC-30 Enterer Authorization Mode 承認モード入力 (CNE) 01644

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

定義：このフィールドは、 オーダを作成或いは変更する責任を持った実行者からの記録を承認する形態を示している。推奨値に関しては、 HL7 表 0483 承認モード を参照のこと。
HL7表 0483 – Authorization Mode 承認モード
Value
EL
EM
FX
IP
MA
PA
PH
RE
VC
VO

© JAHIS 2016

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

62

Comment

7.10. PID - Patient Identification Segment 患者識別セグメント
JAHIS データ交換規約 共通編 Ver.1.1「７．関連セグメント詳細」を参照のこと。

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

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

© JAHIS 2016

63

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

LEN
250
32
256

DT
CWE
ST
Varies

OPT
R
C

JPN
R
C
C

RP/#

TBL#
0471

ELEMENT NAME
Message Query Name メッセージ照会名Query Tag 照会タグ
User Parameters (in successive fields) ユーザ
パラメータ

QPD フィールド定義
QPD-1 Message Query Name メッセージ照会名 (CWE) 01375

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

定義： このフィールドは照会名を含む。これらの名前は、この仕様の機能に特定した章に指定されている。照会名に関しては、コンフォーマンス・ステートメントと一対一であり、実は、そのコンフォーマンス・ステートメントのための識別子である。サイトに特定した照会名は、文字 Z から始まる。
提案された値については、ユーザ定義のテーブル 0471－照会名参照。
使用者定義表 0471 – 照会名
Value

Description

IHE PDQ QueryIHE PDVQ QueryZS1^Order Query^JHSS0002
ZS3^Storage Commitment^JHSS0002

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

生理検査依頼照会
データ保存確認

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

QPD-3 User Parameters ユーザ・パラメータ (Varies) 01435
定義： これらの連続的なパラメータ・フィールドは、クライアントがサーバにパスする値を保持する。
クライアント・データは、一連の HL７フィールドとして存在する。QPD -3 ユーザ・パラメータから始まって、QPD セグメントの残っているフィールドは、ユーザ・パラメーター・データを伝える。
それぞれの QPD ユーザ・パラメーター・フィールドは、それぞれの名前、タイプ、オプション、および繰り返しが指定されている、コンフォーマンス・ステートメントで定義された１つのパラメータ© JAHIS 201664

に相当する。これらのパラメータが通常共に“接続される(anded)”されると知られている一方で、ユー
ザは、適切にそれぞれを理解するために、要求されたコンフォーマンス・ステートメントを注意深く調べなくてはいけない。
QSC 別形を除いて、パラメータ名は照会で述べられる必要がなく、それらは、
コンフォーマンス・ステートメントに基づいた位置にあると理解される。
それぞれのパラメータ・フィールドは、複雑な QIP および QSC タイプを含めて、どんな単一のデー
タタイプとしてでもコンフォーマンス・ステートメントに指定できる。パラメータ・フィールドは、
また、以下のセクション 5.4.5.3.1、および 5.4.5.3.2 で定義された、ソート・コントロール( SRT )フィールドあるいはセグメントグループ( ID )フィールドを含んでもよい。
QPD セグメントのパラメータ・フィールドは、コンフォーマンス・ステートメントのように同じオーダに現れる。
【生理】では QPD-1 にて推奨したメッセージ問合せ名に対応するユーザ定義パラメータを以下に示す。
QPD パラメータ仕様 – 生理検査依頼照会 (ZS1^Order Query^JHSS0002)
Field Seq
(QueryID=Znn)1

Col Name

Key/Search

Sort

MessageQuery

LEN

TYPE

Opt

705

CWE

R

Rep

Match
Op

TBL

Segment
Field Name

Service
Identifier
CodeElement Name
01375

Name
2

QueryTag

32

ST

R

3

Patient ID

256

CX

C

=

PID-3

00106

00606

4

Placer Order

22

EI

C

=

ORC-2

00216

256

CWE

C

22

EI

C

22

EI

20

Number5

Universal

OBR-4

Device ID
6

Filler Order

=

ORC-3

00217

C

OBX-18

01479

ST

C

QRF-1

00037

26

TS

C

TQ1-7

00038

26

TS

C

TQ1-7

00039

60

ST

C

ORC-5

00041

12

ID

C

‘Y

0156

QRF-6

00042

12

ID

C

Y

0158

QRF-8

00044

Number7

Equipment
instance
identifier

8

Where Subject
Filter9

When Data
Start Date/Time

10

When Data End
Date/Time

11

Other QRY
Subject Filter

12

Which
Date/Time
Qualifier13

Date/Time
Selection
Squalifier

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

1

MessageQuery

Key/Sea
rch

Sort

LEN

TYPE

Opt

705

CWE

R

Rep

Match
Op

TBL

Segment
Field Name

Service
Identifier
CodeElement Name
01375

Name
2

QueryTag

32

ST

R

3

Data UID

256

EI

R

© JAHIS 2016

65

00606
=

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

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

LEN
26
1
1
10
1
26
10
250
250
250

11
12

DT

Japan
R
R
R
R
N
N
R
R
R
R

RP/#

TS
ID
ID
ST
ID
TS
CQ
XCN
CWE
CWE

OPT
R
R
R
R
O
O
R
R
R
R

20

VR

O

O

Y

1

ID

O

O

TBL #
0106
0091
0107
0126

Y
Y
Y

0048

0108

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

QRD フィールド定義
QRD-1 Query Date/Time 照会日時 (TS) 00025

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

定義： アプリケーションプログラムによって照会を作成した日時を示す。

QRD-2 Query Format Code 照会フォーマットコード (ID) 00026
定義： 照会に対する応答のフォーマット示す。取りうるコードは HL7 表 – 0106 照会応答フォーマットを参照のこと。通常は R（診療記録用モード）を指定する。
HL7表 0106 – Query/Response Format Code 照会応答フォーマットコード
Value
D
R
T

Description
Response is in display format 応答は表示フォーマットにあるComment

Response is in record-oriented format 応答は診療記録用（レコード－オリエンテッド）フォーマットにある
Response is in tabular format 応答は表フォーマットにある

QRD-3 Query Priority 照会優先度 (ID) 00027
定義： 応答を期待する時間枠を示す。取りうるコードは HL7 表 - 0091 照会優先度を参照のこと。
D(遅延応答)はバッチ問合せ時に、ホスト側の処理の問題で即時応答が保証できないような場合に使用することが想定されているため、応答日付／時間指定遅延応答は処理や運用が複雑になる可能性がある。
HL7表 0091－Query Priority 照会優先度
Value
D

Deferred

Description

I

Immediate

Comment

遅延
即時

QRD-4 Query ID 照会 ID (ST) 00028
定義： 照会に対し一意の識別子である。照会アプリケーションによって割り当てられ、応答アプリ
ケーションによりそのままエコーバックされる。

© JAHIS 2016

66

QRD-5 Deferred Response Type 遅延応答タイプ (ID) 00029
定義： 有効値は HL7 表 – 0107 遅延応答タイプを参照すること。
QRD-3 照会優先度で記載した理由により、通常は使用しない。
HL7表 0107 – Deferred Response Type
Value
B

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

L

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

遅延応答タイプ
Comment

QRD-6 Deferred Response Date/Time 遅延応答日時 (TS) 00030

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

定義： 遅延応答の送信日時以前または以降の日時である。存在しない場合、応答は可能になった時
点で送ることができる。(QRD-5 遅延応答タイプ参照）
QRD-3 照会優先度で記載した理由により、通常は使用しない。

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

定義： 要求システムが受け入れられる最大長の応答を示す。有効応答は第 1 成分の数値である。
（単位は第 2 成分内に指定されている）。第 2 成分の有効エントリーは HL7 表 0126 – 数量制限要求を参照。デフォルトは LI(行)。
HL7表 0126 – Quantity Limited Request
Value
CH

数量制限要求Description

Comment

Characters 文字LI

Lines 行PG

Pages ページRD

Records 記録

ZO

Locally defined ローカルで定義

QRD-8 Who Subject Filter 対象人物フィルタ (XCN) 00032

成分: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)>^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source
table (IS)> ^ <assigning authority (HD)> ^ <name type code (ID)> ^ <code identifying thecheck digit scheme employed(ID)> ^ <identifier type code (IS)> ^ <assigning facility ID (HD)>Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal
ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID
type (ID)>

定義： 対象人物、あるいは誰に関する照会かを識別する。
通常の運用では次のフォーマットになる。
(患者 ID) ^ (姓) ^ (名)姓・名は半角カナ使用不可。2 バイトコードは使用可。
(注) このフィールドは繰り返し可能であるが、複数の患者を指定した場合は QRD-10 対象部門デー
タコードで指定する内容と各患者の対応が判別できなくなるため、このフィールドを用いて複数の患者を指定する場合は、QRD-10 を使用しないこととする。

QRD-9 What Subject Filter 対象フィルタ (CWE) 00033

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

定義： 要求に必要な情報の種類を記述する。有効値がトランザクション問い合わせのタイプを定義する。実施時にローカルで拡張してよい。

© JAHIS 2016

67

HL7表 0048 – What Subject Filter 対象主題フィルタ
Value
ADV

Description

Comment

Advice/diagnosis 助言／診断

APN

Nursing unit lookup (returns patients in beds, excluding empty beds) 看護
ユニットルックアップ(ベッドにいる患者を返す。空きベッドは除く)
Patient name lookup 患者名ルックアップ

APP

Physician lookup 医師ルックアップ

ARN

Nursing unit lookup (returns patients in beds, including empty beds) 看護ユ
ニットルックアップ（患者をベッドに戻す、空きベッドも含む）
Medical record number query, returns visits for a medical record number カ
ルテ番号照会、カルテ番号への受付番号を返す
Account number query, return matching visit 口座番号照会、一致した受付
番号を返す
Cancel. Used to cancel a query キャンセル. 照会キャンセルに使われる
Demographics 民勢統計 デモグラフィックス
Financial 財務
Generate new identifier 新識別子を作る
Goals ゴール
Most recent inpatient もっとも最近の入院患者
Most recent outpatient もっとも最近の来院患者
Network clock ネットワーク時計
Network status change ネットワーク状況変化
Network statistic ネットワーク統計値
Order オーダ
Other その他
Problems 問題
Procedure 手順
Result
結果

ANU

APM
APA
CAN
DEM
FIN
GID
GOL
MRI
MRO
NCK
NSC
NST
ORD
OTH
PRB
PRO
RES
RAR
RER
RDR
RGR
ROR
SAL

SBK
SBL
SOF

SOP
SSA
SSR
STA
VXI
XID

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

Pharmacy administration information 処方管理情報
Pharmacy encoded order information 処方コード化オーダ情報
Pharmacy dispense information 処方調剤情報
Pharmacy give information 処方投与情報
Pharmacy prescription information 処方箋情報
All schedule related information, including open slots, booked slots, blocked
slots すべてのスケジュール関連情報 空きスロット、予約スロット、閉塞
スロットを含む。
Booked slots on the identified schedule 識別されたスケジュール上の予約
スロット
Blocked slots on the identified schedule 識別されたスケジュール上の予約
スロット
First open slot on the identified schedule after the start date/time Openslots on the identified schedule between the begin and end of the startdate/time range 開始日時以降の識別されたスケジュール上の最初の空きスロット。
Open slots on the identified schedule between the begin and end of the startdate/time range 識別されたスケジュール上の空きスロット
Time slots available for a single appointment 単一予約に利用できるタイム
スロット
Time slots available for a recurring appointment 再予約に利用できるタイム
スロット
Status 状態
Vaccine Information ワクチン情報
Get cross-referenced identifiers クロスレファレンス識別子を入手する【生理】では、「生理検査結果照会(QRY/ORF)」は RES（結果）を指定する。

QRD-10 What Department Data Code 対象部門データコード (CWE) 00034

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

定義： テスト番号、手順番号、薬品コード、品目番号、オーダ番号等の内容を含むことが可能である。このフィールドの内容は前の QRD-9 対象フィルタの内容により決められる。このフィールドは反復区切りコードで分けられた複数の項目を含むことが出来る。

© JAHIS 201668

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

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

定義： 成分セパレータにより分けられた開始と停止値を含む。これらの値は照会をさらに規定するためのウインドウまたは範囲を示す。
QRD-10 対象部門データコードで指定する番号の範囲指定はこのフィールドで行う。

QRD-12 Query Results level 照会結果レベル (ID) 00036
定義： 結果詳細レベルをコントロールするのに使われる。取りうるコードは HL7 表 - 0108 照会結果レベルを参照のこと。HL7 V2.5 「４章 オーダエントリ」と「７章 検査報告」を参照のこと。
通常は T（すべての結果）を指定する。
HL7表 0108 – Query Results Level
Value
O
R
S
T

© JAHIS 2016

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

69

照会結果レベル
Comment

7.15. QRF - Query Filter Segment 問合せフィルタセグメント
QRF セグメントは QRD セグメントとともに使用し、問合せ内容をさらに詳細に規定する。応答では問い合わせメッセージの QRF セグメントをエコーバックする。
HL7表 – QRF – オリジナルスタイル照会フィルタ
SEQ
1
2
3
4
5

LEN
20
26
26
60
60

ST
TS
TS
ST
ST

DT

OPT
R
O
O
O
O

JPN
R
B
B
N
O

RP/#
Y

TBL#

ITEM #
00037
00038
00039
00040
00041

6

12

ID

O

C

Y

0156

00042

7

12

ID

O

O

Y

0157

00043

8

12

ID

O

O

Y

0158

00044

9

60

TQ

O

O

00694

10

10

NM

O

O

01442

Y
Y

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

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

QRF-2 When Data Start Date/Time データ開始日時 (TS) 00038
定義： このフィールドは対象となるデータの開始日時の情報を含んでいる。ここで指定した値も含む。
本項目は下位互換性のためだけに用意されている。

QRF-3 When Data End Date/Time データ終了日時 (TS) 00039
定義： このフィールドは対象となるデータの終了日時の情報を含んでいる。ここで指定した値も含む。
本項目は下位互換性のためだけに用意されている。

QRF-4 What User Qualifier ユーザクオリファイア (ST) 00040
定義： このフィールドは関心データの特性をさらに定義する識別子を含んでいる。
通常、本フィールドは使用しない。

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

QRF-6 Which Date/Time Qualifier 対象日時クオリファイア (ID) 00042
定義： このフィールドは QRF-2－対象データ開始日時と QRF-3－対象データ終了日時で参照される
日付のタイプを指定する。

© JAHIS 201670

HL7表 0156 – Which Date/Time Qualifier 対象日時クオリファイア
Value
ANY
COL
ORD
RCT
REP
SCHED

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

Comment

QRF-7 Which Date/Time Status Qualifier 日時状態クオリファイア (ID) 00043
定義： このフィールドは QRF-2－対象データ開始日時および QRF-3 対象データ終了日時により定義された日付範囲で選択した対象日時の状態を示す。

QRF-8 Date/Time Selection Qualifier 日時選択クオリファイア (ID) 00044
定義： このフィールドはその日時範囲で特定のタイプの値が指定できる。取りうる値については「HL7 表 0158-日付選択クオリファイア」を参照
HL7表 0158 – Date/Time Selection Qualifier 日時選択クオリファイア
Value
1ST
ALL
LST
REV

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

Comment

QRF-9 When Quantity/Timing Qualifier 数量/日時クオリファイア (TQ) 00694

成分：<quantity (CQ)> ^ <interval (CM)> ^ <duration> ^ <start date/time (TS)> ^ <end date/time(TS)> ^ <priority (ID)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ID)> ^ <ordersequencing>

定義： このフィールドは、照会への複数の応答を絞り込むための日時の範囲を指定する。
定義の補足として、これからの実装では「QRF-2－データ開始日時」および「QRF-3－データ終了日時」を使用不可とするべきである。

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

© JAHIS 2016

71

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

7.17. TQ1 - Timing/Quantity タイミング/数量セグメント
JAHIS データ交換規約 共通編 Ver.1.1「７．関連セグメント詳細」を参照のこと。

© JAHIS 201672

付録―１．生理データ交換規約メッセージの例
１．各ワークフロー（ａ）基本ワークフロー
オーダエントリシステムおよび患者属性管理サーバが稼動し（それらを一括して HIS と呼ぶ）
、オンライ
ン接続されているモダリティが各種データ連携を LIS と行うフローを想定する。本例では、データストレー
ジサーバは LIS に含まれる。
a-1:患者が新規に登録され、HIS から LIS へ患者情報通知を行う。
a-2:安静時 12 誘導心電図検査オーダが HIS から LIS へ通知される。
a-3:患者が検査室受付に到着する。
a-4:モダリティより LIS へ、検査予定日とステータスをキーに生理検査依頼照会を行う。
a-5:検査室に患者を呼び入れ、検査開始状態になる。
a-6:心電図検査を行い、心電図をモダリティからファイルサーバ（LIS）へ送信する。
a-7:検査終了通知をモダリティより LIS へ行う。
a-8:モダリティがデータ保存確認を LIS へ行う。
（ｂ）オーダ無し検査
患者属性のみ連携し検査を行うフローを想定する。本例では、検査ステータス連携は行われない。
b-1:患者が新規に登録され、HIS から LIS へ患者情報通知を行う（a-1 と同じ）。
b-2:患者情報照会をモダリティから LIS へ行う。
b-3:検査を行い、検査結果データをモダリティからファイルサーバ（LIS）へ送信する。
b-4:モダリティがデータ保存確認を LIS へ行う（a-8 と同じ）。
（ｃ）結果照会
他院紹介などの目的で、電子カルテシステム（HIS と呼ぶ）が LIS から検査結果データを取得することを想定する。検査データの実体を取得する場合と、URI を取得する場合がある。本例では HIS が FTP にて実体を取得することを想定している。
c-1:HIS が LIS へ検査結果照会を行う。

© JAHIS 201673

２．メッセージ使用例
規約の解釈相違によりメッセージ送受信トラブルを避けるために、前節で記述したフロー例にもとづき、
生理検査メッセージがどのように構築されるか示す。
（a-1）:患者が新規に登録され、HIS から LIS へ患者情報通知を行う。
送信メッセージ(HIS→LIS)
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

患者区分

外来患者

所属科

01

担当医

中田隆

依頼科

01

MSH|^~¥&|HIS||LIS||20150821114323||ADT^A08^ADT_A01|12345678901234500001|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
EVN||20150821114323||01<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
PV1||O|01^^^^^C||||112233^中田^隆^^^^^^^L^^^^^I|||01<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

HIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

7

メッセージ日時

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

20150821114323

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

9

メッセージ型

ADT^A08^ADT_A01

10

メッセージ制御 ID

12345678901234500001

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

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 201674

■ EVN セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド2

イベント伝送日時

20150821114323

トランザクションが入力されたシ
ステムの日時4

イベント理由コード

6

イベント発生日時

推奨値 使用者定義表 0062 イベン

01

ト理由
イベントが実際に起こった日時■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

備考

1234567890^^^^PI

必須フィールド

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

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

示コード

必須フィールド
5

患者氏名

7

生年月日

19501214

8

性別

M

11

患者住所

東京都港区新橋２－５－５13

電話番号 – 自宅^PRN^PH^^^^^^^^^03-0000-0000

姓名~フリガナ~ローマ字YYYYMMDD
第 8 成分のみ使用■ PV1 セグメント
SEQ
2

値

ELEMENT NAME
患者区分

備考
必須フィールドO

推奨値 使用者定義表 004 患者区分
入院の場合、<病棟コード>^<病室コ

3

患者指定場所

01^^^^^Cード>^<ベッド番号>^^^N
外来の場合、<所属科>^^^^^C

7

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

10

診療部門

01

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

応答メッセージ（LIS→HIS）
MSH|^~¥&|LIS||HIS||20150821114325||ACK^A08^ACK|99999999991234500001|P|2.5||||||~ISO IR87||ISO2022-1994<CR>
MSA|AA|12345678901234500001<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

HIS© JAHIS 2016

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること

75

SEQ

値

ELEMENT NAME

備考
必須フィールド

7

メッセージ日時

20150821114325

9

メッセージ型

ACK^A08^ACK

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500001

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ

1

値

ELEMENT NAME

応答コード

備考
必須フィールドAA

HL7 表 - 0008 応答コード
必須フィールド

2

メッセージ制御 ID

12345678901234500001

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 201676

（a-2）:安静時 12 誘導心電図検査オーダが HIS から LIS へ通知される。
送信メッセージ（HIS→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

患者区分

外来患者

所属科

01

担当医

中田隆

依頼科

01

オーダ制御

新規オーダ

依頼者オーダ番号201508210089

入力者

中田隆

入力場所コード

01

検査回数

1

優先度

通常

検査名

標準１２誘導心電図

MSH|^~¥&|HIS||LIS||20150821114523||OMG^O19^OMG_O19|12345678901234500002|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
PV1||O|01^^^^^C||||112233^中田^隆^^^^^^^L^^^^^I|||01<CR>
ORC|NW|201508210089|||SC||||20150821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||201508211030||R<CR>
OBR||201508210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O<CR>
ORC|PA|201508210089|||SC||||20150821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||201508211030||R<CR>
OBR||201508210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O <CR>
OBX|1|NM|9M021000000000001^体重^JC10||65.0|kg|||||F<CR>
ORC|CH|201508210090|||SC|||201508210089|20150821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C||||01||||||||||||O^外来患者オーダ^HL70482<CR>
TQ1||1|||||201508211030||R<CR>
OBR||201508210090||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O||||201508210089<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

HIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

LIS

ネットワーク全体で一意に識別可© JAHIS 2016

能であること

77

SEQ

値

ELEMENT NAME

備考
能であること必須フィールド

7

メッセージ日時

20150821114523

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

9

メッセージ型

10

メッセージ制御 ID

OMG^O19^OMG_O19

必須フィールド
必須フィールド

12345678901234500002

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

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

値

ELEMENT NAME
患者 ID リスト

備考

1234567890^^^^PI

必須フィールド

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

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

示コード

必須フィールド
5

患者氏名

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

姓名~フリガナ~ローマ字YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ PV1 セグメント
SEQ
2

値

ELEMENT NAME
患者区分

備考
必須フィールドO

推奨値 使用者定義表 004 患者区分
<病棟コード>^<病室コ
入院の場合、

3

患者指定場所

01^^^^^C

7

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

10

診療部門

01

ード>^<ベッド番号>^^^N
外来の場合、<所属科>^^^^^C
推奨値 使用者定義表 0069 診療部
門■ ORC セグメント(1)
SEQ
1

値

ELEMENT NAME
オーダ制御

備考
必須フィールド

NW

HL7 表 - 0119 オーダ制御コード
必須フィールド

2

依頼者オーダ番号

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

201508210089

る文字列
5

オーダ状態

© JAHIS 2016

HL7 表 - 0038 オーダ状態

SC

78

SEQ

値

ELEMENT NAME

備考
必須フィールド

9

トランザクション日時

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

20150821115000

始めるイベントの日付
10

入力者

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

12

オーダ発行者

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

要求をアプリケーションに実際に入力した人の所属氏名必須フィールド
要求を作成することに責任がある
依頼する医師などの所属氏名

13

入力場所

01^^^^^C

要求を入力した人が入力時に物理

17

入力組織

01

依頼科

29

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

的に居る場所■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

201508211030

9

優先度

R

備考

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

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

4

検査項目 ID

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

備考

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

依頼者

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

ORC-12 と同一

25

結果状態

O

HL7 表-0123 結果状態

■ ORC セグメント(2)SEQ

値

ELEMENT NAME

1

オーダ制御

PA

2

依頼者オーダ番号201508210089

備考
必須フィールド
HL7 表 – 0119 オーダ制御コード
必須フィールド
第 1 成分は、個々のオーダを識別す
る文字列

5

オーダ状態

HL7 表 – 0038 オーダ状態

SC

必須フィールド
9

トランザクション日時

20150821115000

ORC-1 に反映される現在の処理を始めるイベントの日付

10

入力者

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

要求をアプリケーションに実際に12

オーダ発行者

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

必須フィールド© JAHIS 201679

入力した人の所属氏名

SEQ

値

ELEMENT NAME

備考
要求を作成することに責任がある
依頼する医師などの所属氏名

13

入力場所

01^^^^^C

要求を入力した人が入力時に物理

17

入力組織

01

依頼科

29

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

的に居る場所■ TQ1 セグメント(2)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

201508211030

9

優先度

R

備考

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

値

ELEMENT NAME

備考
上位ＯＲＣに対する通番。初期値

1

セット ID – 検査要求

１、増分１。必要に応じ同一 ORC

2

セグメントに対して１から付番される通し番号（オプション）。

2

依頼者オーダ番号

必須フィールド

201508210089

ORC-2 と同一
必須フィールド

4

検査項目 ID

9A^循環器機能検査^JC10要求された試験／検査／検査セットの識別子コード16

依頼者

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

ORC-12 と同一

25

結果状態

O

HL7 表-0123 結果状態

■ OBX セグメント(2-1)
SEQ

値

ELEMENT NAME

備考
同一の OBR セグメントに対し 1 か

1

セット ID – 検査要求ら付番される OBX のシーケンス番

1号
2

結果値タイプNM

HL7 表 – 0125 値型

3

検査項目

9M021000000000001^体重^JC10

必須フィールド

5

結果値

65.0

6

単位

kg
必須フィールド

11

検査結果状態HL7 表 – 0085 検査結果状態コー

F

ド解釈■ ORC セグメント(3)
SEQ
1

値

ELEMENT NAME
オーダ制御

© JAHIS 2016

備考
必須フィールドCH

HL7 表 0119 オーダ制御コード

80

SEQ

値

ELEMENT NAME

備考
必須フィールド
第 1 成分は、個々のオーダを識別す

2

依頼者オーダ番号201508210090

5

オーダ状態

SC

HL7 表 – 0038 オーダ状態

8

親201508210089

親オーダーの ORC-2 と同一

9

トランザクション日時

る文字列

必須フィールドORC-1 に反映される現在の処理を

20150821115000

始めるイベントの日付
10

入力者

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

要求をアプリケーションに実際に入力した人の所属氏名必須フィールド12

オーダ発行者

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

要求を作成することに責任がある
依頼する医師などの所属氏名要求を入力した人が入力時に物理

13

入力場所

01^^^^^C

17

入力組織

01

29

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

的に居る場所
依頼科■ TQ1 セグメント(3)SEQ

値

ELEMENT NAME

2

数量

1

9

優先度

R

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

値

ELEMENT NAME

備考
上位ＯＲＣに対する通番。初期値

1

セット ID – 検査要求

１、増分１。必要に応じ同一 ORC

3セグメントに対して１から付番される通し番号（オプション）。

2

依頼者オーダ番号

必須フィールド

201508210090

ORC-2 と同一
必須フィールド

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

16

依頼者

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

ORC-12 と同一

25

結果状態

O

HL7 表-0123 結果状態

29

親番号

201508210089

ORC-8 と同一要求された試験／検査／検査セットの識別子コード

応答メッセージ（LIS→HIS）
MSH|^~¥&|LIS||HIS||20150821114328||ORG^O20^ORG_O20|99999999991234500002|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500002<CR><EOM>© JAHIS 201681

■ MSH セグメント
SEQ

値

ELEMENT NAME

1

フィールド区切り|

2

コード化文字^~¥&3

送信アプリケーション

LIS

5

受信アプリケーション

HIS

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

7

メッセージ日時

20150821114328

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

9

メッセージ型

ORG^O20^ORG_O20

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500002

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
応答コード

備考
必須フィールドAA

HL7 表 - 0008 応答コード
必須フィールド

2

メッセージ制御 ID

12345678901234500002

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 201682

（a-3）:患者が検査室受付に到着する。
検査ステータス通知が、Modality→LIS→HIS という流れで処理する場合、MSH セグメントは各アクタで再作成される。
送信メッセージ（LIS→HIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号201508210089

検査名

標準１２誘導心電図検査ステータス

受付(到着確認)

MSH|^~¥&|LIS||HIS||20150821115030||ORU^R01^ORU_R01|12345678901234500003|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
ORC|SC|201508210089|||IP||||20150821115020|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C|||01<CR>
OBR|1|201508210089||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||I<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

LIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

HIS

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

7

メッセージ日時

20150821115030

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

9

メッセージ型

ORU^R01^ORU_R01

10

メッセージ制御 ID

12345678901234500003

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

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994© JAHIS 201683

■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

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

患者氏名

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

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

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

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ ORC セグメント
SEQ
1

値

ELEMENT NAME

必須フィールド

SC

オーダ制御

備考
HL7 表 - 0119 オーダ制御コード
必須フィールド

2

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

201508210089

依頼者オーダ番号

る文字列
5

オーダ状態

9

トランザクション日時

HL7 表 - 0038 オーダ状態

IP

必須フィールドORC-1 に反映される現在の処理を

20150821115020

始めるイベントの日付
10112233^中田^隆^^^^^^^L^^^^^I

入力者

要求をアプリケーションに実際に入力した人の所属氏名
必須フィールド

12112233^中田^隆^^^^^^^L^^^^^I

オーダ発行者

要求を作成することに責任がある依頼する医師などの所属氏名

13

入力場所

01^^^^^C

16

オーダ制御コード理由

01

要求を入力した人が入力時に物理的に居る場所■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

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

依頼者

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

ORC-12 と同一

25

結果状態

I

HL7 表 - 0123 結果状態

© JAHIS 201684

応答メッセージ（HIS→LIS）
MSH|^~¥&|HIS||LIS||20150821115035||ACK^R01^ACK|99999999991234500003|P|2.5||||||~ISO IR87||ISO2022-1994<CR>
MSA|AA|12345678901234500003<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

HIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

LIS

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

7

メッセージ日時

20150821115035

9

メッセージ型

ACK^R01^ACK

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500003

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

応答コード

AA

2

メッセージ制御 ID

12345678901234500003

HL7 表 - 0008 応答コード
必須フィールド
通知メッセージの MSH-10 をエコ
ーバック© JAHIS 201685

（a-4）:モダリティより LIS へ、検査予定日とステータスをキーに生理検査依頼照会を行う。
送信メッセージ（Modality→LIS）
項目名

項目値

備考
検査ステータス＝IP がセットさ

検査予定日＝2015/08/21

照会条件

れた場合、LIS は受付済レコー

検査ステータス＝SC(予定)

ドを返信するものとする。

MSH|^~¥&|Modality||LIS||20150821115200||QBP^ZS1^QBP_Q11|12345678901234500005|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QPD|ZS1^Order Query^JHSS0002|Q001||||||20150821|20150821|SC|SCHED|ALL<CR>
RCP|I|99^RD|R^リアルタイム^HL70394<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

2

コード化文字^~¥&必須フィールド
ネットワーク全体で一意に識別可

3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

必須フィールド

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

7

メッセージ日時

20150821115200

9

メッセージ型

QBP^ZS1^QBP_Q11

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500005

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS1^Order Query^JHSS0002

必須フィールド

2

照会タグ

Q001

応答と照会を突合する識別子

8

When Data Start Date/Time

20150821

検査予定日時（範囲開始）

9

When Data End Date/Time

20150821

検査予定日時（範囲終了）

10

Other QRY Subject FilterSC

HL7 表 – 0038 オーダ状態

11

Which Date/Time Qualifier

12

Date/Time Selection
Qualifier

HL7 表 - 0156 対象日時クオリフ

SCHED

ァイア
HL7 表 - 0158 日時選択クオリフ

ALL

ァイア

■ RCP セグメント© JAHIS 2016

86

SEQ

値

ELEMENT NAME

備考

1

照会優先度

I

応答のためのタイムフレーム2

数量制限要求99^RD

受け入れられる応答の最大長

3

応答様式

R^リアルタイム^HL70394

応答メッセージのタイミングとグ
ルーピング

応答メッセージ（LIS→Modality）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

患者区分

外来患者

所属科

01

担当医

中田隆

依頼科

01

オーダ制御

新規オーダ

依頼者オーダ番号201508210089

入力者

中田隆

入力場所コード

診療科 (01)

検査回数

1

検査日時

2015/08/21

優先度

通常

検査名

標準１２誘導心電図

MSH|^~¥&|LIS||Modality||20150821115230||RSP^ZS2^RSP_K11|99999999991234500005|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500005<CR>
QAK|Q001|OK|ZS1^Order Query^JHSS0002|1<CR>
QPD|ZS1^Order Query^JHSS0002|Q001||||||20150821|20150821|SC|SCHED|ALL<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
PV1|1|O|01^^^^^C||||112233^中田^隆^^^^^^^L^^^^^I|||01<CR>
ORC|NW|201508210089|||SC||||20150821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C<CR>
TQ1||1|||||20150821||R<CR>
OBR|1|201508210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O<CR>
ORC|PA|201508210089|||SC||||20150821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C<CR>
TQ1||1|||||20150821||R<CR>
OBR|2|201508210089||9A^循環器機能検査^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O <CR>
OBX|1|NM|9M021000000000001^体重^JC10||65.0|kg|||||F<CR>
ORC|CH|201508210090|||SC|||201508210089|20150821115000|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C<CR>
TQ1||1|||||20150821||R<CR>
OBR|3|201508210090||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||O||||201508210089<CR><EOM>© JAHIS 201687

■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

LIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

Modality

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

7

メッセージ日時

20150821115230

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

9

メッセージ型

RSP^ZS2^RSP_K11

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500005

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994

メッセージを一意に識別する番号
または他の識別子■ MSA セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

応答コード

AA

2

メッセージ制御 ID

12345678901234500005

HL7 表 - 0008 応答コード
必須フィールド
通知メッセージの MSH-10 をエコーバック■ QAK セグメント
SEQ

値

ELEMENT NAME

備考
照会メッセージの QPD-2 と同一で

1

照会タグ

Q001

2

照会応答状態OK

3

メッセージ照会名

ZS1^Order Query^JHSS0002

4

合致データ合計ある必要がある
HL7 表 - 0208 照会応答状態
照会メッセージの QPD-1 と同一である必要がある

1■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS1^Order Query^JHSS0002

必須フィールド

2

照会タグ

Q001

応答と照会を突合する識別子

8

When Data Start Date/Time

20150821

検査予定日時（範囲開始）

9

When Data End Date/Time

20150821

検査予定日時（範囲終了）

10

Other QRY Subject FilterSC

HL7 表 0038 オーダ状態© JAHIS 2016

88

11
12

Which Date/time Qualifier
Date/Time Selection
Qualifier

HL7 表 - 0156 対象日時クオリフ

SCHED

ァイア
HL7 表 - 0158 日時選択クオリフ

ALL

ァイア

■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

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

患者氏名

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

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

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

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ PV1 セグメント
SEQ

値

ELEMENT NAME

1

セット ID – PV1

1

2

患者区分

O

3

患者所在場所

01^^^^^C

備考
必須フィールド
推奨値 使用者定義表 004 患者区分
入院の場合、<病棟コード>^<病室コード>^<ベッド番号>^^^N
外来の場合、<所属科>^^^^^C

7

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

病院サービス

01

推奨値 使用者定義表 0069 診療部
門■ ORC セグメント(1)
SEQ
1

値

ELEMENT NAME
オーダ制御

備考
必須フィールド

NW

HL7 表 - 0119 オーダ制御コード
必須フィールド

2

依頼者オーダ番号201508210089

5

オーダ状態

SC

第 1 成分は、個々のオーダを識別する文字列
HL7 表 - 0038 オーダ状態
必須フィールド

9

トランザクション日時

20150821115000

ORC-1 に反映される現在の処理を始めるイベントの日付

10

入力者

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

要求をアプリケーションに実際に

12

依頼者

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

要求を作成することに責任がある

入力した人の氏名必須フィールド
依頼する医師などの氏名© JAHIS 2016

89

13

入力場所

要求を入力した人が入力時に物理01^^^^^C

的に居る場所■ TQ1 セグメント(1)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20150821

9

優先度

R

備考
検査予定日時推奨値 使用者定義表 0485 拡張優
先度コード■ OBR セグメント(1)SEQ

値

ELEMENT NAME

備考

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

必須フィールドORC-2 と同一

4

検査項目 ID

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

必須フィールド

16

依頼者

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

ORC-12 と同一

25

結果状態

O

HL7 表 - 0038 オーダ状態

検査分類の識別子コード■ ORC セグメント(2)SEQ

値

ELEMENT NAME

1

オーダ制御

PA

2

依頼者オーダ番号201508210089

備考
必須フィールド
HL7 表 – 0119 オーダ制御コード
必須フィールド
第 1 成分は、個々のオーダを識別す
る文字列

5

オーダ状態

HL7 表 – 0038 オーダ状態

SC

必須フィールド
9

トランザクション日時

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

20150821115000

始めるイベントの日付
10

入力者

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

要求をアプリケーションに実際に

12

依頼者

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

要求を作成することに責任がある

入力した人の氏名必須フィールド
依頼する医師などの氏名

13

入力場所

要求を入力した人が入力時に物理01^^^^^C

的に居る場所■ TQ1 セグメント(2)SEQ

値

ELEMENT NAME

2

数量

1

7

開始日時

20150821

9

優先度

R

© JAHIS 2016

備考
検査予定日時推奨値 使用者定義表 0485 拡張優
先度コード

90

■ OBR セグメント(2)SEQ

値

ELEMENT NAME

備考

1

セット ID – 検査要求

2

2

依頼者オーダ番号201508210089

必須フィールド

4

検査項目 ID

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

必須フィールド

16

依頼者

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

ORC-12 と同一

25

結果状態

O

HL7 表 - 0038 オーダ状態

ORC-2 と同一
検査分類の識別子コード■ OBX セグメント(2-1)
SEQ

値

ELEMENT NAME

備考

1

セット ID

1

2

値型

NM

HL7 表 – 0125 値型

3

検査項目 ID

9M021000000000001^体重^JC10

必須フィールド

5

検査値

65.0

6

単位

kg

11

検査結果状態F

必須フィールド
HL7 表 – 0085 検査結果状態コー
ド解釈■ ORC セグメント(3)
SEQ
1

値

ELEMENT NAME
オーダ制御

備考
必須フィールドCH

HL7 表 – 0119 オーダ制御コード
必須フィールド

2

依頼者オーダ番号

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

201508210090

る文字列
5

オーダ状態

SC

HL7 表 – 0038 オーダ状態

8

親201508210089

親オーダーの ORC-2 と同一

9

トランザクション日時

20150821115000

必須フィールドORC-1 に反映される現在の処理を始めるイベントの日付
10

入力者

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

要求をアプリケーションに実際に入力した人の氏名必須フィールド

12

依頼者

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

要求を作成することに責任がある
依頼する医師などの氏名

13

入力場所

要求を入力した人が入力時に物理01^^^^^C

的に居る場所■ TQ1 セグメント(3)SEQ

値

ELEMENT NAME

備考

2

数量

1

7

開始日時

20150821

検査予定日時9

優先度

R

推奨値 使用者定義表 0485 拡張優© JAHIS 201691

先度コード■ OBR セグメント(3)SEQ

値

ELEMENT NAME

備考

1

セット ID – 検査要求

3

2

依頼者オーダ番号201508210090

必須フィールド

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

必須フィールド

16

依頼者

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

ORC-12 と同一

25

結果状態

O

HL7 表 - 0038 オーダ状態

29

親番号

201508210089

ORC-8 と同一

© JAHIS 2016

ORC-2 と同一

92

検査種別の識別子コード

（a-5）:検査室に患者を呼び入れ、検査開始状態になる。
検査ステータス通知が、Modality→LIS→HIS という流れで処理する場合、MSH セグメントは各アクタで再作成される。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号201508210089

検査名

標準１２誘導心電図検査ステータス

検査中

MSH|^~¥&|Modality||LIS||20150821115135||ORU^R01^ORU_R01|12345678901234500004|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
ORC|SC|201508210089|||IP||||20150821115120|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C|||01<CR>
OBR|1|201508210089||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||S<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

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

7

メッセージ日時

20150821115135

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

9

メッセージ型

ORU^R01^ORU_R01

10

メッセージ制御 ID

12345678901234500004

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

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ PID セグメント© JAHIS 2016

93

SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

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

患者氏名

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

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

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

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ ORC セグメント
SEQ

値

ELEMENT NAME

1

オーダ制御

SC

2

依頼者オーダ番号201508210089

備考
必須フィールド
HL7 表 - 0119 オーダ制御コード
必須フィールド
第 1 成分は、個々のオーダを識別する文字列
HL7 表 - 0038 オーダ状態

5

オーダ状態

IP

9

トランザクション日時

20150821115120

必須フィールドORC-1 に反映される現在の処理を始めるイベントの日付
10

入力者

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

要求をアプリケーションに実際に入力した人の所属氏名必須フィールド

12

依頼者

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

要求を作成することに責任がある
依頼する医師などの所属氏名

13

入力場所

01^^^^^C

16

オーダ制御コード理由

01

要求を入力した人が入力時に物理的に居る場所■ OBR セグメント
SEQ

値

ELEMENT NAME

備考

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

必須フィールド

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

必須フィールド

16

依頼者

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

ORC-12 と同一

25

結果状態

S

HL7 表 - 0123 結果状態

ORC-2 と同一検査種別の識別子コード

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20150821115140||ACK^R01^ACK|99999999991234500004|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500004<CR>© JAHIS 201694

<EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

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

7

メッセージ日時

9

メッセージ型

20150821115140

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

ACK^R01^ACK

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500004

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

応答コード

AA

2

メッセージ制御 ID

12345678901234500004

HL7 表 - 0008 応答コード
必須フィールド
通知メッセージの MSH-10 をエコ
ーバック© JAHIS 201695

（a-6）:心電図検査を行い、心電図をモダリティからファイルサーバ（LIS）へ送信する。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号201508210089

検査名

標準１２誘導心電図

検査日時2010/09/01 12:34:56

測定日時

2010/09/01 12:34:56

MFER データ（メッセージ参照）

付帯情報データ（メッセージ参照）

DataUID

0123420150102132532123

HL7 CDA R2

MSH|^~¥&|Modality||LIS||20150821115300||ORU^R01^ORU_R01|12345678901234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|201508210089||9A110^標準１２誘導心電図^JC10|||20100901123456|||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥
HL7 CDA R2をBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub..¥X0D0A¥
MFERデータをBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||R|||20100901123456<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||0123420150102132532123||||||R|||20100901123456<CR><EOM>※本例で OBX-5(結果値)は FTP で結果ファイルを転送した場合のアップロード先ルート以下相対パス■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS© JAHIS 2016

ネットワーク全体で一意に識別可能であること
ネットワーク全体で一意に識別可能
であること

96

SEQ

値

ELEMENT NAME

備考
必須フィールド

7

メッセージ日時

20150821115300

9

メッセージ型

ORU^R01^ORU_R01

送信システムがメッセージを作成した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500006

メッセージを一意に識別する番号または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

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

値

ELEMENT NAME
患者 ID リスト

備考

1234567890^^^^PI

必須フィールド

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

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

示コード>

必須フィールド
5

患者氏名

姓名~フリガナ~ローマ字7

生年月日19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

備考
必須フィールド
必須フィールド
要求された試験／検査／検査セットの識別子コード7

検査日時20100901123456

16

依頼者

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

25

結果状態

F

存在すれば必須
HL7 表 - 0123 結果状態

■ OBX セグメント(1)SEQ

値

ELEMENT NAME

備考

1

セット ID

1

2

値型

ED

3

検査項目 ID

MIME^MIMEPackage^JHSS0001

必須フィールド^multipart^x-hl7-cda-level-one^A^

必須フィールド5

検査値

MIME-Version: 1.0¥X0D0A¥

HL7 CDA R2 と MFER データをそContent-Type: multipart/mixed;

れぞれ Base64 エンコードしたテキ© JAHIS 2016

必須フィールド
HL7 表 - 0125 値型

97

boundary="HL7-CDA-boundary"¥X0D0A¥

ストを MIME 形式でパッケージ化

Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type:application/x-hl7-cda-level-one+xml¥X0D0A¥

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZ
GluZz0idXRmLTgiPz4NCjw/eG1sLXN0eW
xlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy
ZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24g
eG1sbnM9InVybjpobDctb3JnOnYzIiB4bW
xuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥
X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgR
UNHICAgICAgIBceTklIT04gS09IREVOXkVDR
1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALB
gH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUE
Y9MC4wNAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥

必須フィールド
HL7 表 - 0085 検査結果状態コー

11

検査結果状態

R

14

検査日時

20100901123456

ド解釈
存在すれば必須■ OBX セグメント(2)SEQ

値

ELEMENT NAME

備考

1

セット ID

3

2

値型

ST

必須フィールド

3

検査項目 ID

DUID^DataUID^JHSS0001

必須フィールド

5

検査値0123420150102132532123

必須フィールド

11

検査結果状態R

HL7 表 - 0125 値型

必須フィールド
HL7 表 - 0085 検査結果状態コー
ド解釈
14

検査日時

20100901123456

存在すれば必須

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20150821115310||ACK^R01^ACK|99999999991234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500006<CR><EOM>© JAHIS 201698

■ MSH セグメント
SEQ

値

ELEMENT NAME

1

フィールド区切り|

2

コード化文字^~¥&3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

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

7

メッセージ日時

20150821115310

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

9

ACK^R01^ACK

メッセージ型

必須フィールド
必須フィールド

メッセージ制御 ID

1099999999991234500006

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ

値

ELEMENT NAME

1

備考
必須フィールドAA

応答コード

HL7 表 - 0008 応答コード
必須フィールド

メッセージ制御 ID

2

通知メッセージの MSH-10 をエコ

12345678901234500006

ーバック（a-7）:検査終了通知をモダリティより LIS へ行う。
検査ステータス通知が、Modality→LIS→HIS という流れで処理する場合、MSH セグメントは各アクタで再作成される。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号201508210089

検査名

標準１２誘導心電図検査ステータス

検査終了© JAHIS 201699

MSH|^~¥&|Modality||LIS||20150821115400||ORU^R01^ORU_R01|12345678901234500007|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
ORC|SC|201508210089|||CM||||20150821114325|112233^中田^隆^^^^^^^L^^^^^I||112233^中田^隆^^^^^^^L^^^^^I|01^^^^^C|||01<CR>
OBR|1|201508210089||9A110^標準１２誘導心電図^JC10||||||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

Modality

ネットワーク全体で一意に識別可能

5

受信アプリケーション

LIS

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

7

メッセージ日時

20150821115400

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

9

メッセージ型

ORU^R01^ORU_R01

10

メッセージ制御 ID

12345678901234500007

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

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

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

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

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

患者氏名

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

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

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

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ ORC セグメント
SEQ

値

ELEMENT NAME

備考

1

オーダ制御

SC

必須フィールド

2

依頼者オーダ番号201508210089

必須フィールド© JAHIS 2016

HL7 表 - 0119 オーダ制御コード100

第 1 成分は、個々のオーダを識別す
る文字列
5

オーダ状態

HL7 表 - 0038 オーダ状態

CM

必須フィールド
9

トランザクション日時

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

20150821115120

始めるイベントの日付
10

入力者

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

要求をアプリケーションに実際に入力した人の氏名必須フィールド

12

依頼者

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

要求を作成することに責任がある依頼する医師などの氏名

13

入力場所

01^^^^^C

16

オーダ制御コード理由

01

要求を入力した人が入力時に物理的に居る場所■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

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

依頼者

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

ORC-12 と同一

25

結果状態

F

HL7 表 - 0123 結果状態

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20150821115410||ACK^R01^ACK|99999999991234500007|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500007<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

7

メッセージ日時

20150821115410

ネットワーク全体で一意に識別可能であることネットワーク全体で一意に識別可能であること必須フィールド
送信システムがメッセージを作成
した日時

9

メッセージ型

ACK^R01^ACK

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500007

メッセージを一意に識別する番号
または他の識別子© JAHIS 2016

101

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME

備考
必須フィールドAA

応答コード

HL7 表 - 0008 応答コード
必須フィールド

2

メッセージ制御 ID

通知メッセージの MSH-10 をエコ

12345678901234500007

ーバック（a-8）:モダリティがデータ保存確認を LIS へ行う。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

DataUID = 23546161312446732

確認条件

MSH|^~¥&|Modality||LIS||20150821115500||QBP^ZS3^QBP_Q11|12345678901234500008|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QPD|ZS3^Storage Commitment^JHSS0002|Q002|23546161312446732<CR>
RCP|I|99^RD|R^リアルタイム^HL70394<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

Modality

ネットワーク全体で一意に識別可

5

受信アプリケーション

LIS

7

メッセージ日時

20150821115500

能であることネットワーク全体で一意に識別可能であること必須フィールド
送信システムがメッセージを作成
した日時

9

メッセージ型

QBP^ZS3^QBP_Q11

必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500008

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ QPD セグメント
SEQ
1

ELEMENT NAME
メッセージ 照会名

© JAHIS 2016

値
ZS3^Storage Commitment^JHSS0002

102

備考
必須フィールド

2

照会タグ

Q002

応答と照会を突合する識別子

3

データ UID

23546161312446732

検索条件■ RCP セグメント
SEQ

値

ELEMENT NAME

備考

1

照会優先度

I

応答のためのタイムフレーム2

数量制限要求99^RD

受け入れられる応答の最大長

3

応答様式

R^リアルタイム^HL70394

応答メッセージのタイミングとグ
ルーピング

応答メッセージ（LIS→Modality）
項目名
データ保存確認

項目値

備考

成功

データ保存コミット

MSH|^~¥&|LIS||Modality||20150821115510||RSP^ZS4^RSP_K11|99999999991234500008|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500008<CR>
QAK|Q002|OK|ZS3^Storage Commitment^JHSS0002|1<CR>
QPD|ZS3^Storage Commitment^JHSS0002|Q002|23546161312446732<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

1

フィールド区切り|

2

コード化文字^~¥&3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

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

7

メッセージ日時

20150821115510

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

9

メッセージ型

RSP^ZS4^RSP_K11

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500008

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
応答コード

備考
必須フィールドAA

HL7 表 - 0008 応答コード
必須フィールド

2

メッセージ制御 ID

12345678901234500008

通知メッセージの MSH-10 をエコ
ーバック© JAHIS 2016

103

■ QAK セグメント
SEQ

値

ELEMENT NAME

備考
確認メッセージの QPD-2 と同一で

1

照会タグ

Q002

2

照会応答状態OK

3

メッセージ照会名

ZS3^Storage Commitment^JHSS0002

4

合致データ合計1ある必要がある
HL7 表 - 0208 照会応答状態■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS3^Storage Commitment^JHSS0002

必須フィールド

2

照会タグ

Q002

応答と照会を突合する識別子

3

データ UID

23546161312446732

検索条件（b-1）:患者が新規に登録され、HIS から LIS へ患者情報通知を行う（a-1 と同じ）。
JAHIS データ交換規約 共通編 Ver.1.1「付録‐1 メッセージ例」を参照のこと。
（b-2）:患者情報照会をモダリティから LIS へ行う。
JAHIS データ交換規約 共通編 Ver.1.1「付録‐1 メッセージ例」を参照のこと。
（b-3）:検査を行い、検査結果データをモダリティからファイルサーバ(LIS)へ送信する。
本例は、モダリティから LIS へ結果送信する例である。LIS から HIS へ結果送信する場合は OBR-3 に部門側の値をセットする。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

検査名

標準１２誘導心電図

検査日時2010/09/01 12:34:56

測定日時

2010/09/01 12:34:56

MFER データ（メッセージ参照）

付帯情報データ（メッセージ参照）

DataUID

0123420150102132532123

値があれば必須

HL7 CDA R2

MSH|^~¥&|Modality||LIS||20150821115300||ORU^R01^ORU_R01|12345678901234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ© JAHIS 2016104^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|||9A110^標準１２誘導心電図^JC10|||20100901123456|||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥
HL7 CDA R2をBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥X0D0A¥
MFERデータをBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||R|||19970205131051<CR>
OBX|2|ST|DUID^DataUID^JHSS0001|1|0123420150102132532123||||||R|||19970205131051<CR><EOM>※本例で OBX-5(結果値)は FTP で結果ファイルを転送した場合のアップロード先ルート以下相対パス■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

Modality

5

受信アプリケーション

LIS

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

7

メッセージ日時

20150821115300

9

メッセージ型

ORU^R01^ORU_R01

送信システムがメッセージを作成
した日時
必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500006

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

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

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

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

患者氏名

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

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

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

7

生年月日

195012148

性別

M© JAHIS 2016

YYYYMMDD

105

11

患者住所

13

電話番号 – 自宅^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

2

依頼者オーダ番号4

検査項目 ID

備考

1
必須フィールド
9A110^標準１２誘導心電図^JC10要求された試験／検査／検査セットの識別子コード7

検査日時20100901123456

16

依頼者

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

25

結果状態

F

値があれば必須
HL7 表-0123 結果状態

■ OBX セグメント(1)SEQ

値

ELEMENT NAME

備考

1

セット ID

1

2

値型

ED

必須フィールド

3

検査項目 ID

MIME^MIMEPackage^JHSS0001

必須フィールド

HL7 表 - 0125 値型^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed;boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type:application/x-hl7-cda-level-one+xml¥X0D0A¥

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZ
GluZz0idXRmLTgiPz4NCjw/eG1sLXN0eW
xlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy

5

検査値

ZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgI

必須フィールドCAJCT8+DQo8RUNHT2JzZXJ2YXRpb24g

HL7 CDA R2 と MFER データをそ

eG1sbnM9InVybjpobDctb3JnOnYzIiB4bW

れぞれ Base64 エンコードしたテキ

xuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥

ストを MIME 形式でパッケージ化

X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgR
UNHICAgICAgIBceTklIT04gS09IREVOXkVDR
1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALB
gH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUE
Y9MC4wNAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥© JAHIS 2016106

--HL7-CDA-boundary¥X0D0A¥

必須フィールド
11

検査結果状態HL7 表 - 0085 検査結果状態コー

R

ド解釈
14

検査日時

20100901123456

存在すれば必須■ OBX セグメント(2)SEQ

値

ELEMENT NAME

備考

1

セット ID

3

2

検査値タイプ

ST

3

検査項目

DUID^DataUID^JHSS0001

必須フィールド

4

サブ ID

1

条件付フィールド

5

結果値0123420150102132532123

必須フィールド

11

検査結果状態R

HL7 表 - 0085 検査結果状態コー

必須フィールド
HL7 表 - 0125 値型

必須フィールド
ド解釈
14

測定日時

20100901123456

値があれば必須

応答メッセージ（LIS→Modality）
MSH|^~¥&|LIS||Modality||20150821115310||ACK^R01^ACK|99999999991234500006|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500006<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

LIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

Modality

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

7

メッセージ日時

20150821115310

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

9

メッセージ型

10

メッセージ制御 ID

ACK^R01^ACK

必須フィールド
必須フィールド

99999999991234500006

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント© JAHIS 2016

107

SEQ

値

ELEMENT NAME

備考
必須フィールド

1

応答コード

AA

2

メッセージ制御 ID

12345678901234500006

HL7 表- 0008 応答コード
必須フィールド
通知メッセージの MSH-10 をエコーバック（b-4）:モダリティがデータ保存確認を LIS へ行う（a-8 と同じ）。
送信メッセージ（Modality→LIS）
項目名

項目値

備考

DataUID = 23546161312446732

確認条件

MSH|^~¥&|Modality||LIS||20150821115500||QBP^ZS3^QBP_Q11|12345678901234500008|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QPD|ZS3^Storage Commitment^JHSS0002|Q002|23546161312446732<CR>
RCP|I|99^RD|R^リアルタイム^HL70394<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

Modality

ネットワーク全体で一意に識別可

5

受信アプリケーション

LIS

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

7

メッセージ日時

9

メッセージ型

20150821115500

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

QBP^ZS3^QBP_Q11

必須フィールド
必須フィールド

10

メッセージ制御 ID

12345678901234500008

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS3^Storage Commitment^JHSS0002

必須フィールド

2

照会タグ

Q002

応答と照会を突合する識別子

3

データ UID

23546161312446732

検索条件■ RCP セグメント© JAHIS 2016

108

SEQ

値

ELEMENT NAME

備考

1

照会優先度

I

応答のためのタイムフレーム2

数量制限要求99^RD

受け入れられる応答の最大長

3

応答様式

R^リアルタイム^HL70394

応答メッセージのタイミングとグ
ルーピング

応答メッセージ（LIS→Modality）
項目名
データ保存確認

項目値

備考

成功

MSH|^~¥&|LIS||Modality||20150821115510||RSP^ZS4^RSP_K11|99999999991234500008|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234500008<CR>
QAK|Q002|OK|ZS3^Storage Commitment^JHSS0002|1<CR>
QPD|ZS3^Storage Commitment^JHSS0002|Q002|23546161312446732<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

2

コード化文字^~¥&必須フィールド
ネットワーク全体で一意に識別可

3

送信アプリケーション

LIS

5

受信アプリケーション

Modality

必須フィールド

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

7

メッセージ日時

20150821115510

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

9

メッセージ型

RSP^ZS4^RSP_K11

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234500008

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1

値

ELEMENT NAME
応答コード

備考
必須フィールドAA

HL7 表- 0008 応答コード
必須フィールド

2

メッセージ制御 ID

12345678901234500008

通知メッセージの MSH-10 をエコーバック■ QAK セグメント© JAHIS 2016

109

SEQ

値

ELEMENT NAME

備考
確認メッセージの QPD-2 と同一で

1

照会タグ

Q002

2

照会応答状態OK

3

メッセージ照会名

ZS3^Storage Commitment^JHSS0002

4

合致データ合計1ある必要がある
HL7 表 - 0208 照会応答状態■ QPD セグメント
SEQ

値

ELEMENT NAME

備考

1

メッセージ 照会名

ZS3^Storage Commitment^JHSS0002

必須フィールド

2

照会タグ

Q002

応答と照会を突合する識別子

3

データ UID

23546161312446732

検索条件（c-1）:HIS が LIS へ検査結果照会を行う。
送信メッセージ（HIS→LIS）
項目名

項目値

備考

患者 ID = 1234567890

照会条件

依頼者オーダ番号=0123456789

MSH|^~¥&|HIS||LIS||20150821120000||QRY^R02^QRY_R02|12345678901234600000|P|2.5||||||~ISO
IR87||ISO 2022-1994<CR>
QRD|20150821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|0123456789<CR>
QRF|EKG||||CM<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

備考

1

フィールド区切り|

必須フィールド

2

コード化文字^~¥&必須フィールド3

送信アプリケーション

HIS

ネットワーク全体で一意に識別可

5

受信アプリケーション

7

メッセージ日時

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

20150821120000

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

9

メッセージ型

QRY^R02^QRY_R02

10

メッセージ制御 ID

12345678901234600000

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

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ QRD セグメント© JAHIS 2016

110

SEQ

値

ELEMENT NAME

1

照会日時

20150821120000

2

照会フォーマットコード

R

備考
必須フィールド
照会を作成した日時
必須フィールド
HL7 表 - 0106 照会応答フォーマ
ット

3

照会優先度

I

4

照会 ID

OSQ0158207

数量制限請求

999^RD

必須フィールド
HL7 表 - 0091 照会優先度
必須フィールド
照会に対し一意の識別子
必須フィールド
必須フィールド

8

対象人物フィルタ

対象人物、あるいは誰に関する照会

1234567890^東京^太郎

かを識別(患者 ID)^(姓)^(名)9

対象フィルタRES

必須フィールド

10

対象部門データコード

0123456789

依頼者オーダ番号

HL7 表 - 0048 対象主題フィルタ■ QRF セグメント
SEQ

値

ELEMENT NAME

備考
必須フィールド

1

対象場所フィルタ

EKG

問合せが関連する部門、システム、
サブシステムを識別

他の QRY 対象フィルタ5

照会条件に検査ステータスを指定

CMしたい場合は CM(検査終了)固定

応答メッセージ（LIS→HIS）
項目名

項目値

備考

患者 ID

1234567890

患者氏名

東京太郎

性別

男

生年月日

1950/12/14

患者住所〒105-0004 東京都港区新橋２－５－５

電話番号 – 自宅

03-0000-0000

依頼者オーダ番号201508210089

検査名

標準１２誘導心電図

検査日時2010/09/01 12:34:56

測定日時

2010/09/01 12:34:56

MFER データ（メッセージ参照）

付帯情報データ（メッセージ参照）

HL7 CDA R2

MSH|^~¥&|LIS||HIS||20150821120010||ORF^R04^ORF_R04|99999999991234600001|P|2.5||||||~ISO IR87||ISO 2022-1994<CR>
MSA|AA|12345678901234600000<CR>
QRD|20150821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|0123456789<CR>© JAHIS 2016111

PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|201508210089||9A110^標準１２誘導心電図^JC10|||20100901123456|||||||||112233^中田^隆^^^^^^^L^^^^^I|||||||||F<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥
HL7 CDA R2をBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥X0D0A¥
MFERデータをBase64エンコード--HL7-CDA-boundary¥X0D0A¥
したテキストContent-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||R|||20100901123456<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||0123420150102132532123||||||R|||20100901123456<CR><EOM>■ MSH セグメント
SEQ

値

ELEMENT NAME

1

フィールド区切り|

2

コード化文字^~¥&3

送信アプリケーション

LIS

5

受信アプリケーション

HIS

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

7

メッセージ日時

20150821120010

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

9

メッセージ型ORF^R04^ORF_R04

必須フィールド
必須フィールド

10

メッセージ制御 ID

99999999991234600001

メッセージを一意に識別する番号
または他の識別子

11

処理 ID

P

必須フィールド

12

バージョン ID

2.5

必須フィールド

18

文字セット~ISO IR87

必須フィールド

20

代替文字セット操作法

ISO 2022-1994■ MSA セグメント
SEQ
1
2

値

ELEMENT NAME
応答コード

AA

メッセージ制御 ID

12345678901234600000

備考
アプリケーション受諾。
確認メッセージの MSH-10 をエコーバック。

■ QRD セグメント
SEQ
1

値

ELEMENT NAME
照会日時

© JAHIS 2016

20150821120000

112

備考
必須フィールド
照会を作成した日時

必須フィールド
2

照会フォーマットコード

HL7 表 - 0106 照会応答フォーマ

R

ット
3

照会優先度

I

4

照会 ID

OSQ0158207

数量制限請求

999^RD

必須フィールド
HL7 表 - 0091 照会優先度
必須フィールド
照会に対し一意の識別子
必須フィールド
必須フィールド

8

対象人物フィルタ

1234567890^東京^太郎

対象人物、あるいは誰に関する照会
かを識別(患者 ID)^(姓)^(名)9

対象フィルタRES

必須フィールド

10

対象部門データコード

0123456789

依頼者オーダ番号

HL7 表 - 0048 対象主題フィルタ■ PID セグメント
SEQ
3

値

ELEMENT NAME
患者 ID リスト

1234567890^^^^PI

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

患者氏名

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

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

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

7

生年月日

19501214

8

性別

M

11

患者住所

13

電話番号 – 自宅

YYYYMMDD^^^^105-0004^^H^東京都港区新橋２－５－５^PRN^PH^^^^^^^^^03-0000-0000■ OBR セグメント
SEQ

値

ELEMENT NAME

1

セット ID - 検査要求

1

2

依頼者オーダ番号201508210089

備考
必須フィールドORC-2 と同一
必須フィールド

4

検査項目 ID

9A110^標準１２誘導心電図^JC10

7

検査日時

20100901123456

16

依頼者

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

ORC-12 と同一

25

結果状態

F

HL7 表-0123 結果状態要求された試験／検査／検査セットの識別子コード■ OBX セグメント(1)SEQ

値

ELEMENT NAME

1

セット ID

1

2

値型

ED

© JAHIS 2016

備考
必須フィールド
HL7 表 - 0125 値型

113

3

検査項目 ID

MIME^MIMEPackage^JHSS0001

必須フィールド^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed;boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type:application/x-hl7-cda-level-one+xml¥X0D0A¥

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZ
GluZz0idXRmLTgiPz4NCjw/eG1sLXN0eW
xlc2hlZXQgdHlwZT0idGV4dC94c2wiIGhy
ZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24g
5

検査値

eG1sbnM9InVybjpobDctb3JnOnYzIiB4bW
xuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥
X0D0A¥

必須フィールド
HL7 CDA R2 と MFER データをそれぞれ Base64 エンコードしたテキ
ストを MIME 形式でパッケージ化--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgR
UNHICAgICAgIBceTklIT04gS09IREVOXkVDR
1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALB
gH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUE
Y9MC4wNAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥

必須フィールド
11

検査結果状態HL7 表 - 0085 検査結果状態コー

R

ド解釈
14

検査日時

20100901123456

存在すれば必須■ OBX セグメント(2)SEQ

値

ELEMENT NAME

1

セット ID

3

2

値型

ST

3

検査項目 ID

DUID^DataUID^JHSS0001

5

検査値

0123420150102132532123

備考
必須フィールド
HL7 表 - 0125 値型
必須フィールド
必須フィールド
必須フィールド

11

検査結果状態R

HL7 表 - 0085 検査結果状態コー

14

検査日時

20100901123456

存在すれば必須

ド解釈

該当検査が無く、“ゼロ件”である旨応答する場合© JAHIS 2016114

リクエストされた条件に対する結果がゼロ件であった場合、OBR-25（結果状態）の値に”Z”（No record ofthis patient(Used only on queries)）をセットする。この場合、応答メッセージ例は以下となる。
MSH|^~¥&|LIS||HIS||20150821120010||ORF^R04^ORF_R04|99999999991234600001|P|2.5||||||~ISO R87||
ISO 2022-1994<CR>
MSA|AA|12345678901234600000<CR>
QRD|20150821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|0123456789<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|||""|||||||||||||||||||||Z<CR><EOM>

該当検査が複数あった場合
リクエストされた条件に対する結果が複数件あった場合（条件が患者 ID のみであった場合など）、OBR
以下を繰り返す。OBR-1（セット ID）はインクリメントされる。特にことわりが無ければ、OBR セグメン
トは以下となる。
MSH|^~¥&|LIS||HIS||20150821120010||ORF^R04^ORF_R04|99999999991234600001|P|2.5||||||~ISO R87||
ISO 2022-1994<CR>
MSA|AA|12345678901234600000<CR>
QRD|20150821120000|R|I|OSQ015820|||999^RD|1234567890^東京^太郎|RES|""<CR>
PID|||1234567890^^^^PI||東京^太郎^^^^^L^I~トウキョウ^タロウ^^^^^L^P~TOKYO^TARO^^^^^L^A||19501214|M|||^^^^105-0004^^H^東京都港区新橋２－５－５||^PRN^PH^^^^^^^^^03-0000-0000<CR>
OBR|1|201508210010||9A110^標準１２誘導心電図^JC10|||20150901100034|||||||||112234^新橋^一郎^^^^^^^L^^^^^I||||||||||F<CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjw/eG1sLXN0eWxlc2hlZXQgdHlwZT0idGV4
dC94c2wiIGhyZWY9Ik5paG9uS29oZGVuLnhzbCINCiAgICAJCT8+DQo8RUNHT2JzZXJ2YXRpb24geG1sbnM9InVy
bjpobDctb3JnOnYzIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTIgbGVhZHMgRUNHICAgICAgIBceTklIT04gS09IREVOXkVDR1ZpZXdeMDEtMDQtMDQ2AQEBAgMBBAALBgH9AgAAAAwGAPfiBAAAESlMUEY9MTAwIERFRj1PTiBCRUY9NTBeSHVtIGZpbHRlciBIUEY9MC4w
NAoBAA0IAAAAAAAAAAAOCgAAAAAAAAApxBDwQ10d4QWIX5hHid9hH...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||R|||20150901100034<CR>
OBX|2|ST|DUID^DataUID^JHSS0001|1|201509010000232||||||R|||20150901100034<CR>
OBR|2|201508210020||9A110^標準１２誘導心電図^JC10|||20150908114325|||||||||112233^中田^隆^^^^^^^L^^^^^I||||||||||F <CR>
OBX|1|ED|MIME^MIMEPackage^JHSS0001||^multipart^x-hl7-cda-level-one^A^
MIME-Version: 1.0¥X0D0A¥
Content-Type: multipart/mixed; boundary="HL7-CDA-boundary"¥X0D0A¥
Content-Transfer-Encoding: Base64¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/x-hl7-cda-level-one+xml¥X0D0A¥
PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0
L3hzbCIgaHJlZj0iRnVrdWRhX2UxMi54c2wiPz4KPEVDR09ic2VydmF0aW9uIHhtbG5zPSJ1cm46aGw3LW9yZzp2
MyIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAyL...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥
Content-Type: application/mwf¥X0D0A¥
QCBNRlIgU3RhbmRhcmQgMTJsZWFkcyBFQ0cAAAAAAAAAAAsEAfoH0AwEAPcTEAoBAA0BAAQEAAATiAUEAAAACAYEAAAAAQgBAT8ABAkCAAE/AQQJAgACPwIECQIAAz8DBAkCAAQ/BAQJAgAFPwUECQIABj8GBAkCAAc/BwQJAgAIEQVE
cmlmdAEBAAMFQVNDSUkWCFJFU1QtRUNHFx1GVUtVREEgREVOU0hJXkZDUC...¥X0D0A¥--HL7-CDA-boundary¥X0D0A¥||||||R|||20150908114325<CR>
OBX|2|ST|DUID^DataUID^JHSS0001||201509080000542||||||R|||20150908114325<CR><EOM>© JAHIS 2016115

３．心電図等の波形情報と検査結果情報の記述
３．１．MFER 波形のリンク情報をメッセージに記述する例
心電計などの小型の医療機器では、簡易な通信機能のみ実装されているに過ぎない。また、本規約ではMFER ファイル等結果データの送信プロトコルは規定しないが、結果データをリンク情報から別途取得する
手法は、小規模システムではより複雑となるケースもある。したがって、結果データは MIME パッケージ
として HL7 メッセージに埋め込む方法を推奨するが、下位互換のためにリンク情報を使用する方法例を記載する。本例では、心電図結果の自動解析所見と主な測定値は XML で記述し、心電図波形結果は MFER
記述して各々リンク情報を送信する。
OBX|1|RP|MFER^MFER ファイル
^JHSS0001||/MFEROut/00005_000001000_20100901105057451.mwf||||||R|||20100901123456<CR>
OBX|2|RP|XML^付帯情報ファイル^JHSS0001||/MFEROut/00005_000001000_20100901105057451.xm||||||R|||20100901123456<CR>

３．２． 自動測定結果の記述例
計測値を HL7 メッセージに埋め込む例を以下に示す。
OBX|7|NM|8867-4^Heart rate^LN^2.16.840.1.113883.6.1||67|bpm|||||F<CR>
OBX|8|NM|8625-6^PR interval^LN^2.16.840.1.113883.6.1||180|ms|||||F<CR>
OBX|9|NM|8633-0^QRS duration^LN^2.16.840.1.113883.6.1||94|ms|||||F<CR>
OBX|10|NM|8634-8^QT interval^LN^2.16.840.1.113883.6.1||398|ms|||||F<CR>
OBX|11|NM|8626-4^P wave axis^LN^2.16.840.1.113883.6.1||38|deg|||||F<CR>
OBX|12|NM|8632-2^QRS axis^LN^2.16.840.1.113883.6.1||30|deg|||||F<CR>
OBX|13|NM|8638-9^T wave axis^LN^2.16.840.1.113883.6.1||20|deg|||||F<CR>
OBX|14|NM|10040-4^S wave amplitude in lead V1^LN^2.16.840.1.113883.6.1||1.500|mV|||||F<CR>
OBX|15|NM|9995-2^R wave amplitude in lead V5^LN^2.16.840.1.113883.6.1||1.605|mV|||||F<CR>© JAHIS 2016116

付録―２．作成者名簿作成者（社名五十音順）
日高 浩敦

三栄メディシス（株）

森 誠人（株）ソフトウェア・サービス中田 英男

日本電気（株）木村 雅彦

日本アイ・ビー・エム（株）

中野 誠

日本光電工業（株）

平井 正明

日本光電工業（株）

藤咲 喜丈

日本光電工業（株）

吉村 尚郎

日本光電工業（株）

小林 聡

フクダ電子（株）

山田 剛

フクダ電子（株）

下邨 雅一

富士通（株）

窪田 成重

富士通（株）© JAHIS 2016

117

日付
2007/08
2013/04

バージョン
Ver. 1.0
Ver.2.0

2016/12

Ver.3.0C

改定履歴
内容
初版
・患者情報照会メッセージを QBP/RSP に変更した。
・生理検査依頼照会を QBP/RSP に変更した。
・データ保存確認 QBP/RSP を追加した。
・ORU/ACK メッセージにおいて、ADT^A04 を廃止した。
・サンプル電文を見直した。
・誤字や誤表現を修正した。
・JAHIS データ交換規約 共通編 Ver.1.1 に記載された内容と同一の場合は、その記載内容を参照するようにした。
・他データ交換規約について外部有識者からの指摘事項を踏まえ、各所見直した。
・親子オーダについての記述方法を明記した。
・OBX-5 において、CDA の記述方法を HL7 原文に従い修正した。
・サンプル電文を見直した。
・誤字や誤表現を修正した。

（JAHIS 標準 16-005）

2016 年 12 月発行

JAHIS 生理検査データ交換規約 Ver.3.0C
発行元 一般社団法人 保健医療福祉情報システム工業会〒105-0004 東京都港区新橋 2 丁目 5 番 5 号（新橋 2 丁目ＭＴビル 5 階）
電話 03-3506-8010

FAX 03-3506-8070（無断複写・転載を禁ず）© JAHIS 2016

118