ＪＡＨＩＳ標準００２−００

J

平 成 ９ 年 度

事 業 報 告 書

JapaneseA

医療情報交換仕様

Association of

H
Healthcare

JAHIS
臨床検査データ交換規約
Ver. 1.0

I
Information

S
Systems Industry

平成10年6月
保健医療福祉情報システム工業会
臨床検査システム委員会

JAHIS 臨 床 検 査 デ ー タ 交 換 規 約 Ver. 1.0
ま

え

が

き

1993年、(財)医療情報システム開発センター(MEDIS-DC)臨床検査データ交換標準化協議会により｢臨床検査データ交換規約(暫定版)｣が発表された。その後、約1年間で30件以上におよぶ使用実績を見た。しかしながら、幾多の課題も見受けられた。
そこで保健医療福祉情報システム工業会(JAHIS)臨床検査センターシステム専門委員会では、その使用経験に基づき、課題や要望を抽出整理した。その結果、課題の一部は、仕様の解釈が不十分なことに起因していると考えられた。そこで平成6年度に、課題の共通認識と解決方法・注意点などを討議した結果、円滑な導入を図るため｢臨床検査データ交換規約(暫定版)利用ガイ
ド｣をまとめ、発表した。
平成7年度より課題の根本的解決と医療情報の標準化動向に沿った臨床検査データ交換規約の検討にはいり、標準化動向の調査学習をすすめた。平成8年度に臨床検査システムホスト接続
WGと共同でDRAFTバージョンを発表し、意見収集を行った。平成9年度、関係諸先生方の多数のご意見やHL7をはじめ関連規約との調整をはかり｢JAHIS臨床検査データ交換規約Ver.1.0｣をまとめるに至った。本規約は、医療情報の標準化動向を見極めながら臨床検査のみならず保健
医療福祉情報システム全体のデータ交換体系に留意し、次世代かつワールドワイドに通用するものとし、院内オーダリングや病医院−臨床検査センター間をはじめ、さまざまな医療関連施設相互間に適用できるよう検討し、まとめたものである。
本規約が医療資源の有効利用、保健医療福祉サービスの連携・向上を目指す医療情報標準化とデータ交換円滑化に多少とも貢献できれば幸いです。
保健医療福祉情報システム工業会
臨床検査システム委員会

1998年6月

＜＜

告知事項

＞＞

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

Copyright©1998 JAHIS保健医療福祉情報システム工業会
Copyright©1998 日本医療情報学会MML/MERIT-9研究会

目

次

1．

はじめに

1

2．

HL7概要

2

3．

主な用語

3

4．

臨床検査依頼・臨床検査結果メッセージ構文

44．1

HL7メッセージについて

44．2

臨床検査依頼44．3

臨床検査結果54．4

臨床検査依頼ORM・臨床検査結果ORUの例

6

関連情報詳細85．1

検査項目コードについて

85．2

材料・採取部位コードについて

9

5．3

メッセージ区切り文字

11

5．4

データ型

12

5．5

数量/タイミング定義

23

5．6

検査結果コメントの扱い

28

セグメント詳細

32

6．1

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

32

6．2

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

35

6．3

PID 患者識別セグメント

36

6．4

PV1

来院情報セグメント

39

6．5

AL1

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

44

6．6

ORC

共通オーダーセグメント

45

6．7

OBR

検査要求セグメント

56

6．8

OBX 検査結果セグメント

63

医療情報交換規約運用指針MERIT−9での扱い

69

5．

6．

7．

1. はじめに
今日、医療は独りのドクターがすべての医療行為や患者情報を掌握した時代から、医師とコメディカルとのチーム医療、病診連携、中央検査室や検査センター、遠隔診断、地域医療、在宅医療へと変貌しつつある。これに対応して、医療にかかわる情報は自己完結型から広域化・共有化する必要がある。このための情報システム基盤は、データベースとネットワークである。その情報が共有化されるためには、ある約束ごとで、客観的に記述され、記録伝達されなければならない。この約束ごとが、標準・規格と呼ばれるもので、工業界では日本工業規格JISに代表される。近年まで、医療分野では個別のカルテが中心であった
ため、標準化について具体的検討があまり進まなかった。しかしながら、先に述べたように医療環境が変化し、分業化と連携やインフォームドコンセントが進むにつれ、標準化と客観化の重要性がより認識されるようになった。また、システムメーカーに於ても、一社ですべての業務システムをカバーすることは困難となってきており、マルチベンダー化が進んでいる。ここでも効率的なシステム開発のため、標準化が必須となっている。このように医療情報の標準化は、患者中心の医療や効率的な医療を進めるにあたって、重要な位置を占めるものである。
臨床検査の分野では、いち早く標準化の取り組みがおこなわれている。臨床検査そのものの標準化は1985年より日本臨床検査標準協議会JCCLS(Japan Committee for Clinical Laboratory Standards)が設立され、検査方法や精度管理を中心に信頼される検査データが流通することを目的として活動している。
検査項目コードについては、日本臨床病理学会で1962年より長年にわたり臨床検査項目分類コードを発表してきたが、1990年にコンピュータで使用する事を前提とした大改訂を行い、第8回改訂として発表した。さらに第8回改訂の問題点や新規項目などを追加し、結果識別コードも組み込んだ第9回改訂を1994年に発表し、1997年の第10回改訂にいたっている。
臨床検査データのシステム間でのやり取りについては、1993 年医療情報システム開発センター
MEDIS-DC臨床検査データ交換標準化協議会より暫定規約｢臨床検査データ交換規約(暫定版)｣が発表された。さらに保健医療福祉情報システム工業会ではその利用ガイドを作成してきた。しかしながら、その暫定規約は当時の汎用機やオフコンで稼動している臨床検査システムですぐ対応可能な規約とし、国際情勢
や医療情報システム動向を踏まえた規約については以後の検討とした。その意味で暫定版であった。
保健医療福祉情報システム工業会臨床検査システム委員会では、医療情報の標準化動向を見極めながら、臨床検査のみならず保健医療情報システム全体のデータ交換体系に留意し、院内オーダリングや病医院−
臨床検査センター間をはじめ、さまざまな医療関連施設間相互に適用できる、次世代かつワールドワイドに通用する臨床検査データ交換規約の検討を進めた。
作業は、まず病院・医院ほか保健医療関連施設(臨床検査センターを含む)間で発生する、将来を見越した、検査依託業務に関する情報要素を抽出し、つぎに情報要素をASTM E-1238及びHL7と対比し原案検討の基本資料とした。それをもとに各情報フィールドの意味付けや定義を明確にするとともにアプリケーシ
ョン層の検討を進めた。また、これまでの検討結果をHL7 Ver2.3に適用し、HL7 Ver2.3に準拠する形で日本の実情を考慮した仕様となるよう検討した。HL7仕様で不都合な部分は浜松医大木村教授のご尽力により米国HL7に仕様変更と了承を取付け、Ver2.3仕様で｢JAHIS 臨床検査データ交換規約 Ver. 1.0｣としてまとめるにいたった。これにより、暫定版では定義されなかった検体数やアレルギーの情報などを反映することが可能となり、またセット検査や負荷試験の個々の検査を詳細にオーダーできるようになった。
したがって本規約はHL7 Ver2.3から、第4章オーダーや第7章検査報告を中心に、第2章コントロールや第3章患者管理より、臨床検査に関係する部分をとりまとめ、国内における運用を鑑み、関連する情報を追加したものである。関係団体や諸先生方の一方ならぬご協力に感謝いたします。

Copyright©1998 JAHIS V1.0

1

JHLDEX10.DOC 00/09/21

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

Copyright©1998 JAHIS V1.0

2

JHLDEX10.DOC 00/09/21

待されます。また、Merit−9を始め関連情報分野で本規約が引用されております。

Copyright©1998 JAHIS V1.0

3

JHLDEX10.DOC 00/09/21

3. 主な用語
トリガーイベントTrigger Event： メッセージの交換を始めるきっかけとなる事象をトリガーイベントという。HL7は、実際のヘルスケア現場でのシステム間データ通信の必要性に応じた事象を受けて書かれている。例えば、｢患者が入院｣というトリガーイベントは、その患者についての情報を幾つかの他のシステムに伝送する必要を引き起こすであろう。それらメッセージ型とトリガーイベ
ントコードは一対多の関係である。
メッセージMessage： 1つのメッセージは、システム間で転送されるデータの意味のある最小単位である。これは定義された順序のセグメントの集合からなる。各々のメッセージはその目的を定義するメッセージタイプを持つ。例えば、ADT(入退転)メッセージタイプはあるシステムから別なシステムに患者の入退転データの一部を伝送するために使用される。各々のメッセージに含まれる3文字のコードがそのタイプを識別する。
セグメントSegment(record)： セグメントはメッセージの1つの側面について記述するもので、データ要素(フィールド)の論理的集合体である。各々のセグメントはセグメントIDと呼ばれる3文字のコードで識別される。メッセージ中のセグメントは必要なものと任意のものとある。それらはメッ
セージ中一回だけ出現する場合と繰り返しが許される場合とある。たとえば、単一のオーダー関
連情報はOBRセグメントとして送られ、検査関連情報は別のOBXセグメントとして送られることがある。
フィールドField： 診断名などといったセグメント中の一つの意味付けされた属性であり、フィールドには基本属性をさらに詳細に記したデータ成分の集合を含むことがある。
フィールド成分Field components： フィールドへの入力要素として、成分という識別可能な部分を含むことがある。たとえば患者名は、姓、名、ミドルネーム(イニシャル)として記録されるが、それぞれの要素は別個のエンティティーであり、成分区切り文字により分離される。成分はさらに副成分で構成される場合もある。
メッセージ区切り文字Message Delimiters： メッセージを構成するにあたっては、定義された文字が使用される。それらは、セグメントターミネータ、フィールドセパレータ、成分セパレータ、副成分セパレータ、反復セパレータ、そしてエスケープ文字である。
依頼者Placer(Requestor)： 検査群を依頼(要求)する人あるいは部門。 たとえば、検体検査、X線、バ
イタル・サインなどを依頼する医師、実施者、病院、または病棟部門など。
実施者Filler(Producer)： 依頼・要求された検査を実施する(オーダーに応える)人または部門のことである。診断部門、臨床部門、その患者についての検査結果を報告する看護提供者を含む。臨床検査
室は検体検査の実施者(検査オーダーに応える人)であり、看護部門はバイタルサイン観察などの実施者(バイタルサインの測定を依頼するオーダーに応える人)である。
検査群(バッテリー)Battery： 単一名と単一コード番号で識別される1個以上の検査を含む検査集合であり、構成要素である検査を依頼・検索するのに使用する手短な単位として扱われる。バイタルサ
イン、電解質、入院時検査、産科用超音波などはすべて検査群の例である。通常、バイタルサイ
ンは、拡張期血圧、収縮期血圧、脈拍、呼吸数など。電解質は通常、Na+、K+、Cl-、HCO3-。入院時検査は血液、電解質、生化学、尿検査など。(HL7の目的を満足するには、検査群の要素も検査群になり得ることに注意する)。産科用超音波は、従来の計測結果および所見から成るセット
であり、そのすべては、要求者に返される時、個別の 結果 として返される。集合に関する数学法則と同様、単一検査も検査群とすることができる。検査群という用語は、本仕様では、｢プロファイル｣あるいは｢パネル｣と同義である。検査群内の個々の検査要素は、1つの生理学系(たとえば肝機能検査法)の特性を反映してもよいし、様々な異なる生理学系の特性を反映してもよい。

Copyright©1998 JAHIS V1.0

4

JHLDEX10.DOC 00/09/21

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

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

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

4.2 臨床検査依頼
臨床検査の依頼時には一般オーダーメッセージ(ORM)を用い、その場合のセグメントと構文規則は以下のとおりである。

ORM 一般オーダーメッセージ(臨床検査依頼
一般オーダーメッセージ 臨床検査依頼)
臨床検査依頼ORM

General Order Message

MSH[ {NTE} ]PID[ {NTE} ][ PV1[ PV2 ] ][ { AL1 } ]
{
ORC
OBR
[ { NTE } ][{OBX[ { NTE } ]}]}Message Header
Notes and Comments (for Header)
Patient Identification
Notes and Comments (for Patient ID)
Patient Visit
Patient Visit 2
Allergy

注:Common Order
Observation Request
Notes and Comments (for OBR)
Observation/Result
Notes and Comments (for Results)[ ]は省略可能、{ }は繰返し可能をを示す。

MSHはオーダーの出力単位(メッセージ)に一つ必須である。
PIDは1患者の一連のオーダーに1個必須である。オーダーがまとめて伝送される場合MSHがオーダーの区切りとなる。

Copyright©1998 JAHIS V1.0

5

JHLDEX10.DOC 00/09/21

ORCは1患者の個々の詳細オーダー(OBR)毎に1個必須である。ただし、1オーダー多項目検査の場合ORCの冗長なしに対応するため、OBRに続くOBXで個別の検査項目指示することも可能である。
ORCは検査材料単位や検査グループ単位に用いることが望ましい。例えば1オーダーで検査
材料が血液と尿の複数材料を扱う場合、血液を用いる検査で一つのORCとOBRで検査グループを表現し続くOBXで個々の検査項目を、尿を用いる検査で一つのORCとOBRで検査グ
ループを表現し続くOBXで個々の検査項目を指示する。またOBRで多項目検査の内容が不明確な場合、OBXで個々の検査項目を指示することも可能である。例えばOBRで肝炎セッ
ト、OBXでGOT,GPT,HBs抗体や、OBRで100g糖負荷試験、OBXで血糖前値,血糖30分値など。
検体検査の検査項目コード(OBR-4/OBX-3)は日本臨床病理学会臨床検査項目分類コードでコーディングされたものを用いる。
検査材料や部位(OBR-15)は日本臨床病理学会臨床検査分類コード材料コードを用いる。
OBXは検査結果セグメントであるが、依頼の際に検査に必要な臨床データを知らせる目的でも利用できるものとする。例えば身長、体重、月経周期など。

4.3 臨床検査結果
臨床検査結果報告時には検査結果メッセージ(ORU)を用い、その場合のセグメントと構文規則は以下のとおりである。

ORU - 検査結果メッセージ
ORU

Observational Results

MSH
{
PID
[ { NTE } ][ PV1 ]{[ ORC ]OBR
[ { NTE } ][{OBX[ { NTE } ]}]}}Message Header

注:

Patient Identification
Notes and comments( for PID)
Patient Visit
Order common
Observations Report ID
Notes and comments( for OBR)
Observation/Result
Notes and comments( for OBX)

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

MSHは検査結果の出力単位に先頭に一つ必要である。
PIDは1患者の一連の検査結果に1個必須である。検査結果がまとめて伝送される場合、PID
が患者毎の区切りとなる。
OBRは検査依頼の情報とともに検査の状況や実施者の情報をセットして通知するため必須である。

Copyright©1998 JAHIS V1.0

6

JHLDEX10.DOC 00/09/21

検体検査の検査項目コード(OBR-4/OBX-3)は日本臨床病理学会臨床検査項目分類コード
でコーディングされたものを用いる。
OBXは臨床検査報告の最少単位即ち個々の検査結果や検査診断情報毎に1個使用する。
個々の検査結果に対する検査所見などのコメントは検査項目ID接尾辞をもったOBXで扱うことを推奨する。
ORCは必要ない限り省略することを薦める。

4.4 臨床検査依頼ORM・検査結果
・検査結果ORUの例の例
臨床検査依頼・検査結果
HL7 V2.3 による臨床検査依頼送信ORMメッセージの例
SeagaiaからLABへV2.3仕様の日本語を含む検査依頼メッセージmn123を5/23に訓練として送信。
MSH|^~\&||Seagaia||LAB|19970523||ORM^O01|mn123|T|2.3||||||~JIS X 0208|JP|JIS X 0202
このメッセージはMerit-9の検査依頼例であることを依頼側が注釈。
NTE||P|Merit-9 Example Order
患者氏名は大塚太郎、男、1950年5月23日生、従業員番号OPC-001、患者IDPID001である。
PID||OPC-001|PID001||OTSUKA^TARO^^^^L^A~大塚^太郎^^^^L^I~おおつか^たろう^^^^L^P||19500523|M
患者さんは外来で第一内科にかかっており主治医は大塚二郎先生である。
PV1||O|第一内科||||^大塚^二郎^^^^L^I
中程度の発疹を1965.1.1に起こしたことがありピリン系薬物アレルギーと認められる。
AL1|1|DA|^ピリン系薬物|MO|発疹|19650101
大塚二郎先生は5/23 9:30に心電図と生化学肝セット(GOT,GPT,LDH-ISO)および糖負荷試験(前,30分,60分,120分)を依頼、オーダー番号はそれぞれ0523001,0523002,0523003でありそのグループ番号は0523001である。オー
ダー先は心電図は心電図検査室、検体検査はOALである。検体は5月23日に採取され生化学は血清検体として1本、糖負荷試験は前値,30分,60分,120分のヘパリン血漿検体4本である。
ORC|NW|0523001||0523001|||||199705230930
OBR||0523001||9A100^心電図^JC9||19970523||||||||||^大塚^二郎^^^^L^I||||||||EC
ORC|NW|0523002||0523001|||||199705230930
OBR||0523002||^生化学肝set^L||19970523|19970523||||||||023|^大塚^二郎^^^^L^I||||||||OAL|||||||||||||1
OBX||NM|3B0350000023272^GOT^JC9|||||||||||||||D
OBX||NM|3B0450000023272^GPT^JC9|||||||||||||||D
OBX||NM|3B0550000023233^LDH-ISO^JC9|||||||||||||||D
ORC|NW|0523003||0523001|||||199705230930
OBR||0523003||^OGTT^L||19970523|19970523||||||||022^ヘパリン|^大塚^二郎^^^^L^I||||||||OAL|||||||||||||4
OBX||NM|3D0101000022272^血糖前値^JC9|||||||||||||||D
OBX||NM|3D0101030022272^血糖30M^JC9|||||||||||||||D
OBX||NM|3D0101060022272^血糖60M^JC9|||||||||||||||D
OBX||NM|3D0101120022272^血糖120M^JC9|||||||||||||||D

HL7 V2.3 による臨床検査結果ORUメッセージの例
LABからSeagaiaへV2.3仕様の日本語を含む検査結果メッセージmn256を5/25に訓練として送信。
MSH|^~\&||LAB||Seagaia|19970525||ORU^R01|mn256|T|2.3||||||~JIS X 0208|JP|JIS X 0202
このメッセージはMerit-9の検査結果例であることを実施者側が注釈。
NTE||L|Merit-9 Example Result
患者氏名は大塚太郎、男、1950年5月23日生、従業員番号OPC-001、患者IDPID001である。
PID||OPC-001|PID001||OTSUKA^TARO^^^^L^A~大塚^太郎^^^^L^I~おおつか^たろう^^^^L^P||19500523|M
大塚二郎先生の5/23依頼、オーダー番号0523001の心電図は5/23 10:00に測定され、大塚三郎先生の所見で重大な
左心房収縮期異常と最終報告として報告された。
OBR||0523001||9A100^心電図^JC9||19970523|199705231000|||||||||^大塚^二郎^^^^L^I||||||||EC|F|||||||^大塚三郎
OBX||TX|9A100&IMP^心電図所見^JC9||左心房収縮期異常|||AA|||F
生化学1本と糖負荷試験4本の検体は検査所OALで5/24に受領され技師太郎検査技師により測定された。結果はGOT 50U
基準値6-28 正常母集団からみて高値である。GPT 5U 3-9 基準値内、LDH-ISOは分画でそれぞれ10,30,20,40%であった。同様に血糖値はOALの技師二郎検査技師によって測定され80,150,100,60mg/dlですべて基準値内であった。検査料はそれぞれ1000円と2000円である。
OBR||0523002|123456701^OAL|^生化学肝set^L||19970523|19970523|||||||19970524|023|^大塚^二郎^^^^L^I|||||||1000^YEN|OAL|F|||||||||^技師太郎|||1
OBX||NM|3B035000002327201^GOT^JC9||50|U|6-28|H||N|F||||OAL
OBX||NM|3B045000002327201^GPT^JC9||5|U|3-9| ||N|F||||OAL

Copyright©1998 JAHIS V1.0

7

JHLDEX10.DOC 00/09/21

OBX||ST|3B055000002323300^LDH-ISO^JC9||||||||F||||OAL
OBX||NM|3B055000002323351^LDH1^JC9||10|%|||||F||||OAL
OBX||NM|3B055000002323352^LDH2^JC9||30|%|||||F||||OAL
OBX||NM|3B055000002323353^LDH3^JC9||20|%|||||F||||OAL
OBX||NM|3B055000002323354^LDH4^JC9||40|%|||||F||||OAL
OBR||0523003|123456702^OAL|^OGTT^L||19970523|19970523|||||||19970524|022^ヘパリン|^大塚^二郎^^^^L^I|||||||2000^YEN|OAL|F|||||||||^技師二郎|||4
OBX||NM|3D010100002227201^血糖前値^JC9||80|mg/dl|60-100| ||N|F||||OAL
OBX||NM|3D010103002227201^血糖30M^JC9||150|mg/dl|90-200| ||N|F||||OAL
OBX||NM|3D010106002227201^血糖60M^JC9||100|mg/dl|80-160| ||N|F||||OAL
OBX||NM|3D010112002227201^血糖120M^JC9||60|mg/dl|50-100| ||N|F||||OAL

3日間朝心電図をとるオーダー ORM message:
MSH|...
PID|...
ORC|NW|A226677^PC||946281^PC||N|3^QAM||198801121132|P123^AQITANE^ELLINORE^""^""^""^MD|||4EAST<CR>
OBR||||9A100^EKG REPORT^JC9||||||||||||P030^SMITH^MARTIN^""^""^""^MD|||||||||||3^QAM<CR>

患者特有の臨床情報を伴った検査依頼の例 クレアチニンクリアランスのための身長体重の報告
MSH|...
PID|...
ORC|NW|...
// New order.
OBR||P42^PC||8A020000098271^Creatinine Clearance^JC9|...
OBX||ST|1010.1^Body Weight||62|kg<CR>
OBX||ST|1010.3^Height||190|cm<CR>
ORC|NW|...
// Next order.
...

Copyright©1998 JAHIS V1.0

8

JHLDEX10.DOC 00/09/21

5. 関連情報詳細
5.1 検査項目コードについて
OBR-4,OBX-3には下記で定義された検査項目コードを使用するものとする。
日本臨床病理学会 臨床検査項目分類コード第10回改訂第1版(JLAC10)1997.10
臨床検査項目分類コード 基本コード体系(１) 分析物コード:検査対象物質、例外として反応名を適用の場合がある。
[例]白血球、アレルゲン特異IgE、潜血反応、ZTT、心電図検査(２) 識別コード:分析物コードを検査内容によって細分する必要がある場合使用。
[例]負荷試験時間、ウイルスの分類、アレルゲンの分類、薬剤感受性(３) 材料コード:同一項目における検査材料の別を分類する。
[例]001尿、004蓄尿、018全血、022血漿、023血清(４) 測定法コード:同一項目における測定法の別を分類する。
[例]ラジオイムノアッセイ二抗体法、紫外吸光度法、嫌気性培養(５) 結果識別コード:結果表現の含意するところを明示する。
[例]共通コード 01定量値、11判定、28クレアチニン補正値
固有コード 3B025 CKアイソザイム：51 BB、52 MB、53 MM、54 アルブミン
検 査 項 目 コ ー ディ ン グ 例
分析物
識別
材料
測定法
結果識別

単 純 ヘ ル ペ ス

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

5F190
1430
023
041
141
151
05
51
52

髄液単純ヘルペスCF抗体価：
5F190−1430−041−141−05(希釈倍率)
血清単純ヘルペス中和抗体価：
5F190−1430−023−151−51(HSV‑1抗原)
5F190−1430−023−151−52(HSV‑2抗原)

臨床検査項目分類コードの利用
臨床検査項目分類コードは5つの基本コードを組合せ、実際の検査項目コードとして使用する。検査依頼時では結果識別コードを除く15桁で表現され、結果報告時ではさらに結果識別コードが追加され17桁で表現される。
検査項目コードと検査材料の関連
検査項目コード中に材料が設定されているが、これはあくまで一つの検査項目測定系を示す
ものである。したがって、検査データを扱うシステムでは検査項目フィールドと検査材料フィールドを別に持つべきである。HL7−OBR/OBXで用いる場合、検査項目フィールドにはオーダーする検査項目を示すコード(すなわち商品コードのような性格)、検査材料フィールドには実際に提出する材料コードを設定する。
検査項目コード事例集
臨床検査項目分類コードを実際に組み合わせ検査項目コードを付番するのは様々な解釈もあり容易ではない。そこで一般に使用されている検査項目について付番したものを公表準備中である。(日本臨床病理学会ホームページ http://www.alles.co.jp/~jscp1/を参照)

Copyright©1998 JAHIS V1.0

9

JHLDEX10.DOC 00/09/21

5.2 検査材料・部位コードについて
OBR-15では下記で定められた材料コードを使用するものとする。
日本臨床病理学会

臨床検査項目分類コード

材料コード

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

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

Copyright©1998 JAHIS V1.0

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

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

10

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

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

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

⇒
⇒
⇒
⇒

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

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

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

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

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

コード

400
405
410
415
420
425
430
435

450
455

460
465
470
480
485

500
510
515

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

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

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

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

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

コード

材料名

11

コード

材料名

JHLDEX10.DOC 00/09/21

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

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

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

Delimiter values区切文字の値
区切文字の値

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

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

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

Copyright©1998 JAHIS V1.0

12

JHLDEX10.DOC 00/09/21

5.4 Data types データ型
図 2-2.
Data type
Alphanumeric
ST
TX
FT
Numerical
CQ
MO
NM
SI
SN
Identifier
ID
IS

Data Type Name

Notes/Format

StringText data
Formatted text
Composite quantity with units
Money
Numeric
Sequence ID
Structured numericHD

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

EI

Entity identifier

RP

Reference pointerPL

Person locationPT
Date/Time
DT
TM
TS
Code ValuesCE

HL7 data types(抜粋抜粋)
抜粋<quantity (NM)> ^ <units (CE)><quantity (NM)> ^ <denomination (ID)><comparator> ^ <num1 (NM)> ^ <separator/suffix> ^ <num2 (NM)>Processing type<namespace ID (IS)> ^ <universal ID (ST)> ^ <universal ID type (ID)>Used only as part of EI and other data types.
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^<universal ID type (ID)><pointer (ST) > ^ < application ID (HD)> ^ <type of data (ID)> ^ <subtype(ID)><point of care (IS )> ^ <room (IS )> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS )> ^ <person location type (IS)> ^ <building (IS )> ^ <floor(IS )> ^ <location description (ST)><processing ID (ID)> ^ <processing mode (ID)>

Date
Time
Time stamp

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

Coded element<identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate
identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system(ST)><identifier (ID)> ^ <formatted text (FT)> ^ <name of coding system (ST)> ^<alternate identifier (ID)> ^ <alternate formatted text (FT)> ^ <name ofalternate coding system (ST)><ID number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit
scheme employed (ID)> ^ < assigning authority (HD)><ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme
employed (ID)> ^ < assigning authority (HD) )> ^ <identifier type code (IS)>^ < assigning facility (HD)<ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle
initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)>^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority(HD)> ^ <name type code (ID)> ^ <identifier check digit (ST)> ^ <code
identifying the check digit scheme employed (ID)> ^ <identifier type code(IS)> ^ <assigning facility (HD)>CF

Coded element with formatted
valuesCK

Composite ID with check digit

CX

Extended composite ID withcheck digit

XCN

Extended composite ID
number and name

Generic
CM

Composite

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

Demographics
XAD

Extended address<street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state orprovince (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type(ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^<census tract (IS)><family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^<suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD)(ST)> ^ <name type code (ID) ><organization name (ST)> ^ <organization name type code (IS)> ^ <ID
number (NM)> ^ <check digit (NM)> ^ <code identifying the check digit
scheme employed (ID)> ^ <assigning authority (HD)> ^ <identifier type code(IS)> ^ <assigning facility ID (HD)>[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^<telecommunication use code (ID)> ^ <telecommunication equipment type(ID)> ^ <email address (ST)> ^ <country code (NM)> ^ <area/city code (NM)>^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)>

XPN

Extended person nameXON

Extended composite nameand ID number fororganizations

XTN

Extended telecommunications
numberCopyright©1998 JAHIS V1.0

13

JHLDEX10.DOC 00/09/21

Waveform
CD

Channel definition

MA

Multiplexed array

NA

Numeric array

ED

Encapsulated data

Records
PPN

Time Series:
TQ

For waveform data only, see Chapter 7, Section 7.15.3. <channel identifier(*)> ^ <channel number (NM)> & <channel name (ST)>> ^ <electrode names(*) > ^ <channel sensitivity/units (*) > ^ <calibration parameters (*)> ^<sampling frequency (NM)> ^ <minimum/maximum data values (*)>
For waveform data only, see Chapter 7, Section 7.15.2. <sample 1 fromchannel 1 (NM)> ^ <sample 1 from channel 2 (NM)> ^ <sample 1 fromchannel 3 (NM)> ...~<sample 2 from channel 1 (NM)> ^ <sample 2 fromchannel 2 (NM)> ^ <sample 2 from channel 3 (NM)> ...~
For waveform data only, see Chapter 7, Section 7.15.1. <value1 (NM)> ^<value2 (NM)> ^ <value3 (NM)> ^ <value4 (NM)> ^ ...
Supports ASCII MIME-encoding of binary data. <source application (HD) >^ <main type of data (ID)> ^ <data subtype (ID)> ^ <encoding (ID)> ^ <data(ST)>

Performing person timestamp:<ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle
initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)>^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority(HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code
identifying the check digit scheme employed (ID )> ^ <identifier type code(IS)> ^ <assigning facility (HD)> ^ < date/time action performed (TS)>Timing/quantity

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

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

Data types データ型解説(抜粋
データ型解説 抜粋)
抜粋
ST

文字列データ
文字列データは、左詰めにされこれに空白がうしろに続いてもよい。任意の表示可能な(印刷可能な)ASCII文字(20から7Eまでの16進値)である。例：|almost any data at all|

TX

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

FT

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

CQ

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

Copyright©1998 JAHIS V1.0

14

JHLDEX10.DOC 00/09/21

MO

金額
Components: <quantity (NM)> ^ <denomination (ID)>
第1成分は数量で金額を表わし、第2成分はその数量を表す際の貨幣単位である。貨幣単位成分の値はISO-4217に指定されている。貨幣単位を指定しない場合、MSH-17国コードを使用しデフォルトを決定する。例：|99.50^USD|ここでUSDは、米国ドルを表すISO 4217コードである。

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

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

ID

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

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

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

Copyright©1998 JAHIS V1.0

15

JHLDEX10.DOC 00/09/21

テーブル0301−汎用−汎用IDタイプ
テーブル−汎用 タイプ
Value
DNS
GUID
HCD
HL7
ISO
L、M、N
ランダム

UUID
x400
x500

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

例：
1.2.34.4.1.5.1.5.1,1.13143143.131.3131.1^ISO
14344.14144321.4122344.14434.654^GUID
falcon.iupui.edu^DNS
40C983F09183B0295822009258A3290582^RANDOM
LAB1
Local use only: an HD that looks like an IS data type.
PathLab^UCF.UC^L
is itself

A locally defined HD in which the middle component

structured. This can be considered the combination of'PathLab' with the locally defined UID system "L".
LAB1^1.2.3.3.4.6.7^ISO An HD with an ISO "Object Identifier" as a suffix,
and alocally defined system name.
^1.2.344.24.1.1.3^ISO

An HD consisting only of an ISO UID.

EI エンティティ識別名
Components: <entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID (ST)> ^ < universal ID
type (ID)> S)
エンティティ識別名は、識別子の指定されたシリーズ内の与えられたエンティティを定義する。
指定されたシリーズ、すなわち割り当て権限は、成分2〜4によって定義される。割り当て権限
は階層的指名者データ型(HD)である。しかし、それは3つの個別の成分としてEIデータ型の中で定義され、これは通常単一の成分として定義されるのと異なる。これはいくつかの既存のデータ分野の成分としてのEIの使用と下位互換性を維持するためである。そうでなければ、成分
2〜4はセクション2.8.18｢HD階層的指名者｣の中で定義される。階層的指名者は、与えられた
HL7導入を通じて一意的である。
第1成分、エンティティ識別名は、識別子のシリーズ内で一意的であるよう定義され、割当て権限によって作成され、これは階層的指名者によって定義され成分2〜4で表わされる。
RP 参照ポインタ
Components: <pointerポインタ (ST) > ^ < application IDアプリケーションID (HD)> ^ <type of
dataデータの型 (ID)> ^ <subtypeサブタイプ (ID)>
このデータ型は、別のシステムに保存されているデータの情報を伝送する。このデータ型には、そのシステムに保存されているデータを一意に識別する参照ポインタ、そのシステムの識別、およびデータの型が含まれる。
ポインタ： データを保存するシステムが割り当てる一意なキー。そのキーはSTデータ型
であり、データを識別しそのデータにアクセスするのに使う。
アプリケーションID： HDデータ型でありデータを保存するシステムの一意な名前。依頼者(または実施者)アプリケーションIDに同じ。アプリケーションIDは扱うHL7メッセージシス
テムを通じて一意でなければならない。参照されるデータのタイプはテーブル0191に示される。
テーブル 0191 – 参照されるデータのタイプ
Value
Image
Audio
Application

Description
Image data (HL7 v 2.3)
Audio data (HL7 v 2.3)
Other application data, typically uninterpreted binary data

(HL7 v 2.3)

サブタイプは、参照されるデータのタイプのための書式を宣言するのので、HL7テーブル0291−参照されるデータのサブタイプを参照すること。

Copyright©1998 JAHIS V1.0

16

JHLDEX10.DOC 00/09/21

テーブル 0291 - Subtype of referenced data
Value
TIFF
PICT
DICOM
FAX
JOT
BASIC
Octet-stream
PostScript
JPEG
GIF
HTML
RTF

Description
TIFF image data
PICT format image data
Digital Imaging and Communications in Medicine
Facsimile data
Electronic ink data (Jot 1.0 standard)
ISDN PCM audio data
Uninterpreted binary data
PostScript program
Joint Photographic Experts Group
Graphics Interchange Format
Hypertext Markup Language
Rich Text Format

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

処理タイプ
Components: <processing ID (ID)> ^ <processing mode (ID)>
このデータ型は、HL7アプリケーションがHL7メッセージの処理をするべきか否か示す。
処理IDで、メッセージが生成、訓練あるいはシステムデバッギングかどうか定義する値。有効な値については｢HL7テーブル0103−処理ID｣を参照すること。処理モ−ドで、メッセージが文書累積の処理あるいはイニシャルロ−ドの一部かどうか定義する。有効な値については｢HL7テーブル0207−処理モ−ド｣を参照すること。

DT

日付
常に書式YYYYLLDDで表記、桁数により精度が規定される。

例：|19880704|

TM 時間
24時間表記法による、書式HHMM[SS[.SSSS]][+/-ZZZZ]を常に使用する。表記する桁数で精度が規定される。秒指定(SS)はオプションである。存在しない場合、分までの精度と解釈される。
小数の秒指定は同様にオプションである。小数の秒は、秒より高い精度の時間を必要とする場
合に送信される。分、時間、またはそれ以上の時間単位を小数で表記することはできない。発信者の時間帯は、万国標準時(以前はグリニッジ標準時として知られていた)からのオフセットとしてオプションで送られることがある。発信者の時間帯が特定のTMフィールドに存在しな
いが、MSHセグメントの日時フィールドの一部として含まれる場合は、MSH値がデフォルトの時間帯として使われる。それ以外の場合、その時間は発信者の現地時間を参照するものと解釈される。真夜中は0000と表記する。 例：|235959+1130| 1 second before midnight in a time zone eleven and half hours ahead of Universal
Coordinated Time (i.e., east of Greenwich).
|0800| Eight AM, local time of the sender.
|093544.2312| 44.2312 seconds after Nine thirty-five AM, local time of sender.
TS タイム・スタンプ
日付と時間を含む、イベントの正確な時間から成る。書式はつぎのようである。
YYYYLLDD[HHMM[SS[.SSSS]]][+/-ZZZZ]^<精度>
タイム・スタンプの日付部は日付フィールドの規則に従う。時間部は時間フィールドの規則に従う。表記する桁数により精度が規定される。すなわち、誕生日として使われるとき、HHMM

Copyright©1998 JAHIS V1.0

17

JHLDEX10.DOC 00/09/21

部が省略されれば日付であり、HHMM部を0000とすると、まさに明けようとしているその日の真夜中(0時0分)になる。HL7コード化規則の中で使われる特定のデータ表記はISO8824-1987(E)との互換性がある。オプションの精度は下位互換性のためにあり、その日時の精度を示す(Y = 年、L = 月、D = 日、H = 時間、M = 分、S = 秒)。例:|17760704010159-0600| 1:01:59 on July 4, 1776 in the Eastern Standard Time zone.
|17760704010159-0500| 1:01:59 on July 4, 1776 in the Eastern Daylight Saving Time zone.
|198807050000| Midnight of the night extending from July 4 to July 5, 1988 in the local time zone of
the sender.
|198807050000^D| Same as prior example, but precision extends only to the day. Could be used for abirthdate.(＝|19880705|)
HL7規格では、すべてのシステムが日常的に時間帯オフセットを送るよう強く推奨するが、強制はしない。HL7システムではすべて時間帯オフセット受け入れる必要があるが、その実装はアプリケーションに任される。多くのアプリケーションの場合、関心ある時間はその発信者の現地時間である。たとえば、東部標準時間帯にあるアプリケーションが12月11日午後11:00に
サンフランシスコで入院が発生したという通知を受けた場合、その入院を12月12日ではなくて(現地時間の)12月11日に発生したものとして扱うのがよい。
この規則における例外は、臨床システムが、互いに近くに存在しながら時間帯の異なる複数の病院で収集された患者データを処理する場合である。そのようなアプリケーションは、そのデータを共通の表記に変換することがある。同じような問題は、サマータイムとの切り替え時にも発生する。HL7は、情報の送信時に時間帯情報を含めるようにすることで対応する。しかし、ここで検討した処理のどちらを受信システムが採用するかは指定しない。
CM 複合フィールド
他の有意データ・フィールドと組合せるフィールド。それぞれの部分は成分と呼ばれる。CM
フィールドの特定成分は、そのフィールド記述の範囲内で定義される。その他個別に識別される複合フィールドもあり、それについては以下に記述する。このデータ型の使用は発展的に解消し、独自のデータ型を新たに作成する予定である。
HL7フィールドの成分そのものが成分を含むHL7データ型である場合、その区切り文字は一ラ
ンク下位に落とされる。したがって、CEデータ型として示された成分は、<識別子&テキスト&コーディング方式名>としてコード化すべきである。HL7区切り文字は再帰的でないので、成分を含むHL7データ型は副成分となりえないことに注意。このレベルの詳細情報が必要な場
合、HL7データ型の各成分は、別々の副成分としてコード化することができる。この例に関しては、タイミング/数量データ型のオーダーシーケンス化成分にある実施者オーダー番号のコ
ード化方式を参照のこと。
CE コード化値
Components: <identifier識別子 (ST)> ^ <textテキスト (ST)> ^ <name of coding systemコーディン
グ方式名 (ST)> ^ <alternate identifier代替識別子 (ST)> ^ <alternate text代替テキスト (ST)> ^<name of alternate coding system代替コーディング方式名 (ST)>例：|54.21^Laparoscopy^I9^42112^^AS4||F-11380^CREATININE^I9^2148-5^CREATININE^LN|
このデータ型は、コード、およびそのコードと関連するテキストを送る。この型は、次に述べる通り、代替成分を含め6個の成分を持つ：
識別子： 後ろの<text>によって参照される項目を一意に識別する文字列(コード)。異なる
コーディング・スキーマでは、異なる要素を持つ。
テキスト： 問題としている項目の名前または記述。たとえば、心筋梗塞とかX線撮影所見など。そのデータ型は文字列(ST)である。
コーディング方式名： コーディング方式には一意な識別子が割り当てられる。この成分は、識別子成分内で使われているコーディング・スキーマを識別するのに役立つ。識別子成分とコーディング方式名成分の組合せは、データに対して一意なコードである。ここに指定されるコーディング方式の例は、ICD-9、ICD-10、SNOMEDなどである。各方式には一意な識別文字列が与えられる。ここにHL7テーブルを使用する場合、HL7テーブル番号をnnnnとしHL7nnnnとして定義する。
代替成分： 3つの代替成分は、上記と同様、代替方式または現地コーディング方式を定義するためにある。代替テキスト成分が存在せず、代替識別子が存在すると、代替テキストはテ
キスト成分と同じであると解釈される。代替コーディング方式成分が存在しない場合、それはCopyright©1998 JAHIS V1.0

18

JHLDEX10.DOC 00/09/21

ローカル定義の方式であると解釈される。
注記： このデータ型では2組の等価コードを表現しているが、それはCE型フィールドの反復とは意味が違っている。反復を用いる場合は、いくつかの明瞭なコード(明瞭な意味を持つコード)を送信するのが普通である。
CF

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

CK チェック・ディジット付き複合ID
Components:<ID number ID番号 (NM)> ^ <check digitチェックデジット (NM)> ^ <code
identifying the check digit scheme employedチェックデジット方式 (ID)> ^ < assigning authority割
当権限者(HD)>
このデータ型は、たとえばPID-3-患者ID(内部ID)など、通常チェック・ディジットを含むフィールドで使われる。現場で、あるCKフィールドにチェック・ディジットを使っていない場合、第2、第3成分はNullである。
このデータ型のチェックデジットは、メッセージ処理システムが追加生成するわけではない。
それは、送信アプリケーション内で使われる識別番号に含まれる。送信アプリケーションが識別番号内にチェックデジットを含まない場合、この成分はnullとすべきである。
チェックディジット方式は、テーブル0061 − チェックディジット方式で定義する。
テーブル0061
テーブル
値
M10
M11

チェックディジットスキーマ
記述
Mod 10 アルゴリズム
Mod 11 アルゴリズム

例： |128952^6^M11^ADT01|
Mod10チェック・ディジットを計算するためのアルゴリズムは以下の通り
あなたが識別子=12345を持つと仮定する。右側から数えて奇数桁、つまり531を考える。この数を2倍して1062を得る。右から数えて偶数桁、すなわち42を取り、これに1062を付けたして421062を得る。この数字の6桁すべてを加算して15を得る。15の次に大きい10の倍数からこの数を減ずる、つまり20-15により5を得る。これがMod10である。401の場合のMod10チェック・
ディジットは0である；9999の場合は4である；99999999の場合は7である。
Mod11チェック・ディジットを計算するためのアルゴリズムは以下の通り
用語
d = 1の位から始まり、以降10の位、100の位、．．．と続く各位の数字
w = 1の位から始まり、以降10の位、100の位、．．．と続く各位の重み。Wの値は2、3、4、5、6、7、2、3、4、5、6、7、．．．と続く(6桁単位で繰り返す)
c = チェック・ディジット
計算(ステップ1) m = 1の位から開始し、それぞれの位について計算した(d * w)の合計
d = 1の位から最高桁の位までの各桁の数字
w = 1の位から始まり、6桁単位で繰り返す2から7までの各桁の重み(ステップ2) c1 = m mod 11(ステップ3) c1 =0の場合はc1 =1に置き換える。
(ステップ4) c =(11−c1) mod 10
例: if the number is 1234567, then the mod 11 check digit = 6

Copyright©1998 JAHIS V1.0

19

JHLDEX10.DOC 00/09/21

計算は以下の通り
m =(7*2)+(6*3)+(5*4)+(4*5)+(3*6)+(2*7)+(1*2)= 14 + 18 + 20 + 20 + 18 + 14 + 2= 106
c1 = 106 mod 11=7
c = (11-c1) mod 10= 4 mod 10= 4
上記以外のチェック・ディジットは、現地双方の取り決めにより使うことができる。
CX

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

Description
アメリカン・エキスプレス
勘定番号
出生登録番号
ダイナーズクラブ・カード
運転免許証番号
医師番号
ディスカバー・カード
従業員番号
雇用者番号
保証人内部ID
保証人外部ID
マスターカード

Value
MA
MC
MR
PI
PN
PT
RR
SS
UPIN
VS
VN
XX

Description
メディケイド番号
メディケア番号
医療記録番号
患者内部ID
個人番号
患者外部ID
鉄道退職番号
社会保障番号
メディケア/HCFAの汎用医師ID
ビザ
訪問回数
組織ID

XCN

拡張複合IDと名前
Components: <ID numberID番号 (ST)> ^ <family name姓 (ST)> ^ <given name名 (ST)> ^ <middle
initial or nameミドルネーム (ST)> ^ <suffix接尾辞 (e.g., JR or III) (ST)> ^ <prefix接頭辞 (e.g.,DR) (ST)> ^ <degree学位 (e.g., MD) (ST)> ^ <source tableソーステーブル (IS)> ^ <assigningauthority割当て権限者 (HD)> ^ <name type code名前タイプコード(ID)> ^ <identifier check digit
チェックデジット (ST)> ^ <code identifying the check digit scheme employedチェックデジット方式 (ID )> ^ <identifier type code識別タイプコード (IS)> ^ <assigning facility割当て施設 (HD)>
コード値およびテキスト名により人物を識別するフィールド。第1成分は、第8の成分で示されるテーブルに従ったIDである。第2成分から第7成分は人物名を表すPNフィールドである。第8成分は、第1成分で使われるソース・テーブルを指定する。特定の現場では、それぞれの現場でIDまたは名前を省略することができる。名前タイプコードについては、XPN−拡張人名を参照。識別タイプコードは使用者定義テーブル0203−識別子タイプ｣を参照すること。
例: |12372^RIGGINS^JOHN^""^""^""^MD^ADT1||12372||^RIGGINS^JOHN^""^""^""^MD||1234567＾Smith＾John＾J＾III＾DR＾PHD＾ADT01＾＾L＾4＾M11＾MR|

XAD

拡張住所
Components: <street address町名 (ST)> ^ <other designation他の表示 (ST)> ^ <city都市 (ST)> ^<state or province州あるいはプロビンス (ST)> ^ <zip or postal code ZIPあるいは郵便番号(ST)>Copyright©1998 JAHIS V1.0

20

JHLDEX10.DOC 00/09/21

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

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

Description
Alias Name 別名
Legal Name 法律名前
Display Name 表示名称
Maiden Name 旧姓Adopted Name 養子名

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

XON

Description
Ideographic (i.e., Kanji) 表意文字(漢字)Alphabetic (i.e., Default or some single-byte) シングルバイト英数字
Phonetic (i.e., ASCII, Katakana, Hiragana, etc) 表音文字(ASCII,仮名)拡張複合組織IDと名称
Components: <organization name組織名 (ST)> ^ <organization name type code組織の名前タイプ(IS)> ^ <ID Number ID番号 (NM)> ^ <check digitチェックデジット (NM)> ^ <code identifying
the check digit scheme employedチェックデジット方式 (ID)> ^ <assigning authority割当て権限者(HD)> ^ <identifier type code識別子タイプ (IS)> ^ <assigning facility ID割当て施設ID (HD)>
例：|HL7 Health Center＾L＾6＾M11＾HCFA|
組織の名前タイプで、法的な名前、表示する名前などを表わす。
使用者定義テーブル0204組織の名前タイプ
組織の名前タイプ
使用者定義テーブル
Value
A
L
D
SL

XTN

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

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

Copyright©1998 JAHIS V1.0

Description
主要な自宅番号21

JHLDEX10.DOC 00/09/21

Value
ORN
WPN
VHN
ASN
EMR
NET
BPN

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

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

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

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

チャネル定義Components: <channel identifier (<channel number (NM)> & <channel name (ST)>) > ^ <electrodenames (CM)> ^ <channel sensitivity/units (CM)> ^ <calibration parameters (CM)> ^ <sampling
frequency (NM)> ^ <minimum/maximum data values (CM)>ディジタル波形データを標識付けするために、このデータ型を使用する。

MA 多重化された配列
Components: <sample 1 from channel 1 (NM)> ^ <sample 1 from channel 2 (NM)> ^ <sample 1 fromchannel 3 (NM)> ...~<sample 2 from channel 1
このデータ型はチャンネルマルチプレックスの波形データ(例えばアナログディジタル変換器
または他のデジタル信号源からのデジタル化された値)を表現する。
NA 数値の配列
このデータ型は一連(配列)の数値を表わすために使用され、各々はNMデータ型をである。
ED

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

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

MIMEインターネット標準のRFC1521により、Base64を以下のように定義する。24ビットの入力グループ(3つのオクテット)を横切って左から右に進むので、各6ビットのグループは印刷可
能な64文字の配列としてを使用する。指標によって参照された文字が、コード化された文字列

Copyright©1998 JAHIS V1.0

22

JHLDEX10.DOC 00/09/21

に置かれる。これらの文字は、HL7テーブル0290−MIME base64コード化文字に示され、普遍的に表現可能なように選択される。
24ビット未満がデータの終わりで入力グループにおいて利用可能な場合、特別の処理を実行する。十分なコーディング量はデータの終わりで常に完成される。24入力ビット未満が入力グループにおいて利用可能な場合、6ビット・グループの整数を形成するために、右側にゼロビッ
トを付け加える。
入力データのない出力フィールド文字は文字｢=｣に設定される。コード化された出力はすべて
オクテットの整数であるので、次の場合だけが発生する：(1)入力の最終量は24ビットの不可欠な倍数である；ここで、コード化された出力の最終単位
は｢=｣のパディングなしの4文字の不可欠な倍数になる、(2)入力の最終量はちょうど8ビットである；ここで、コード化された出力の最終単位は2つの｢=｣パッド文字が後続する2文字になる。あるいは、(3)入力の最終量はちょうど16ビットである；ここで、コード化された出力の最終単位は1つの｢=｣パッド文字が後続する3文字になる。
テーブル 0290 - MIME base64 コード化文字
Value/Code
0A
1B
2C
3D
4E
5F
6G
7H
8I
9J
10 K
11 L
12 M
13 N
14 O
15 P
16 Q

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

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

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

コード化されたオクテットが、なんらかのコーディング方法によって解釈され、それが暗黙のものかまたは表わされたデータ型で指定されるものを超えるとき(例えば目的地アプリケーシ
ョン上の、16ビットあるいは32ビット・二進法の語の中のそれらのオーダリング)、それは目的地アプリケーションによって決定され、この規格の範囲外である。
ソースアプリケーションから目的地アプリケーションまで送信されるべきデータを構成する
表示可能なASCII文字。もしコード化された二進数であれば、セクション2.8.14.2｢データのタ
イプ｣によってコード化される。
PPN−

タイムスタンプを実行する人
Components: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name(ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^<source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit(ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^<assigning facility (HD)> ^ < date/time action performed (TS)>
このデータ型はTSデータ型につながれたXCNデータ型と等価なものであり、誰がいつアクションを実行したかを記録するために使用する。ヌルでない場合、実行者およびタイムスタンプの両方の値が設定されねばならない。

TQ

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

Copyright©1998 JAHIS V1.0

23

JHLDEX10.DOC 00/09/21

5.5 QUANTITY/TIMING (TQ) DEFINITION

数量/タイミング定義
数量 タイミング定義

Components: <quantity数量 (CQ)> ^ <interval時間間隔 (CM)> ^ <duration継続時間 (ST)> ^<start date/time開始日時 (TS)> ^ <end date/time終了日時 (TS)> ^ <priority優先度 (ST)> ^<condition条件 (ST)> ^ <textテキスト (TX)> ^ <conjunction連結 (ST)> ^ <order sequencingオー
ダーシーケンス化(CM)>
定義： 数量/タイミング(ORC-7,OBR-27)は、オーダーセグメントによって述べられたサービス
がいつ，どのような頻度で行なわれるかを規定する手段を与える。それは、繰り返しを持つことができる複合多重成分フィールドである。すなわち複数回の数量/タイミング指定が、反復区切文字で分離されて表現される。数量/タイミング指定の成分を、以下に述べる。
Quantity component 数量成分 (CQ)
副成分： <数量&単位>
定義： 各々のサービス間隔で供給される必要があるサービスの量。たとえば2つの血液培養が4時間毎に得られるとすれば、数量が2である。もし3ユニットの血液が血液型を調べクロスマッチされるならば、数量は3である。デフォルト値は1である。単位が要求される時、後ろの成分で限定するものによって明示され加えられる。
Interval component 時間間隔成分 (CM)
Subcomponents: <繰り返しパターン&明確な時間間隔>
定義：繰り返されるサービスの時間間隔を決める。デフォルトは1回のみである。第1副成分は繰り返しパターンである。第2副成分はパターンが実行される明確な時間である。
Repeat pattern繰り返しパターン
使用者定義テーブル 4001 - Repeat pattern 繰り返しパターン
Q<integer>SQ<integer>MQ<integer>HQ<integer>DQ<integer>W
Q<integer>LQ<integer>J<day#>every <integer> seconds秒毎
every <integer> minutes分毎
every <integer> hours時間毎
every <integer> days日毎
every <integer> weeks週毎
every <integer> months (Lunar cycle)月毎
特定の曜日に繰り返す。Jはフランス語のjour(day)から。もし<整数>がないならば、繰り返しレートは1と仮定する。日付の番号は、1=月曜日
から7=日曜日までカウントする。それゆえQ2J2は第2火曜日毎、Q1J6
は、土曜日毎を意味する。
BID
1日2回、施設が決めた時刻(たとえば、9AM-4PM)
TID
1日3回、施設が決めた時刻(たとえば、9AM-4PM-9PM)
QID
1日4回、施設が決めた時刻(たとえば、9AM-11AM-4PM-9PM)xID
1日“x” 回、施設が決めた時刻、Xは数字5より大。(例えば5ID=一日5回、8ID=一日8回)
注：上記の4つの指定はいずれもそのQ<整数>H対応と同等ではない。たとえばQIDは、Q6Hではない。前者は不等間隔に置かれる；後者は等間隔に置かれる。
QAM
朝に、施設が決めた時刻に。
QSHIFT
3回の8時間シフトの各々の間で、施設が決めた時刻に。
QOD
隔日(Q2Dと同じ)
QHS
毎日就寝前に。
QPM
夕方、施設が決めた時刻に。
C
サービスの提供は連続的に初めの時刻から終わりの時刻まで
U <spec>スペック) 将来使用のため。<スペック>がUNIXのクローンで定義された
時間隔仕様である場合。
PRN
必要に応じて与えられる。
PRNxxx
xxxがなんらかの頻度コード(たとえば、(PRNQ6H))；必要に応じて頻度
期間にわたって与えられる。
Once
一度だけ。これは、この成分がnullである時、デフォルトである。

Explicit time interval subcomponent明確な時間間隔の副成分
定義： 次の書式において、第1副成分のコードによって参照された実際の時刻を明確にリストする：HHMM,HHMM,HHMM,...。この第2副成分は、実際の投薬時刻が施設内で変化する場合
等、第1副成分を明らかにするために使用される。オーダーの期間が1日を超えるならば、この新しい副成分が実際に役立つのは次の場合に限る。すなわち同じ投薬時刻がオーダーの各々の日に対して発生する場合である。オーダーの実際の開始時刻(数量/タイミングフィールドの第4副成分によって与えられる)が、リストの最初の明確な時刻の後であるならば、最初の投薬は、Copyright©1998 JAHIS V1.0

24

JHLDEX10.DOC 00/09/21

開始時刻の後の最初の明確な時刻とする。患者が明確な時間の異なったセットを持っている場
所へ移動する場合、現在のオーダーは、変更された明確な時間を示している新しい数量/タイ
ミングフィールドで更新される。
時刻は hhmm、就寝時は HS、食事に関係したタイミングは xCy で記述される。
x：A 前、P 後、I 間、 y：M 朝食、D 昼食、V 夕食
Ex: 数量/タイミングフィールドの第2成分：...^QID&0230,0830,1430,2030^...
1日3回食後 ^TID&PC
Duration component継続時間成分
定義： サービスが開始された後で、サービスがどのくらい長く続くかを示す。デフォルトは、
INDEF(不定)である。この成分は、以下の通りにコード化される：
S<integer>
M<integer>
H<integer>
D<integer>
W<integer>
L<integer>
X<integer>

=
=
=
=
=
=
=

T<integer>

=

INDEF

=

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

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

=
=
=
=
=
=
=

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

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

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

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

=
=
=
=
=
=

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

オーダーの連続指定の場合、これらの値は、先行オーダーから後に続くオーダー全部に対してタイミングの重要性を規定する。優先度成分を反復する場合はスペースで区切る。

Copyright©1998 JAHIS V1.0

25

JHLDEX10.DOC 00/09/21

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

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

第10成分が存在する場合、第7成分(条件成分)は、依頼のさいに表示されるテキスト 注記 とみなされる。すなわちシステムは、このテキストをシーケンス化指定の一部として解釈することはない。

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

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

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

2, 3

依頼者オーダー番号

必須/オプション: 2つの副成分を使用する；何故なら依頼者オーダー番号は2つ

Copyright©1998 JAHIS V1.0

26

JHLDEX10.DOC 00/09/21

Subcomponent

Contains

4, 5

実施者オーダー番号6

シーケンス状態値

7

最大繰り返し数

8,9

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

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

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

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

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

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

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

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

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

4つの子オーダーから成るグループを循環的に繰り返すには次のように処理が実行される。:
1番目の子オーダーのORC−4−数量/タイミングは、この子オーダーが、他のオーダーが終了したかどうかとは無関係に、1度実行されることを示す。
この子オーダーが2回目に実行されるのは、4番目のオーダーが終了してからである。

Copyright©1998 JAHIS V1.0

27

JHLDEX10.DOC 00/09/21

このスキームにより、下記情報を追跡することができる：
親オーダーのレベルで返答すべきオーダー・グループ全体の状態。
対応する子オーダーの状態をフォローすることによって、IVオーダーそれぞれの状態。
個別のオーダー例：同じグループのオーダーは、その数量/タイミング・フィールド内のデー
タによってのみ連携させることで、4つのオーダー(共通の親のない)を1グループとして送ることができる。この場合HL7では、グループ全体のオーダー状態をまとめて伝送する便利な手段がないので、4つのオーダーの個々の状態を別々に伝送するしかない。
オーダー状態の継承
キャンセル/中断/保留オーダー制御イベント：
ここでは、指定された先行オーダーが通常通り実行されることを想定している。したがって、
先行オーダーのキャンセル(あるいは中断、保留)は、後続の関連オーダーすべてを取り消す(あるいは中断する、保留する)ことを意味する。
参照されているオーダーが取り消された(あるいは中止、保留された)場合、今回のオーダーはそれと同じ状態を継承する。
保留の場合、先行オーダーの保留を解除することは、その該当オーダーも解除するという意味である。(したがって、そのオーダーは第10成分内の指定にしたがって実行することができる。)

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

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

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

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

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

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

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

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

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

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

Copyright©1998 JAHIS V1.0

28

JHLDEX10.DOC 00/09/21

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

Observation ID suffices

検査項目接尾辞

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

Suffix
IMP
REC
CNP
MED
ANT
DEV
SER

Type
CE
CE
CE
CE
CE
CE
ST

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

GDT
MDT
TCM
ADT

TX or FTTX or FTTX or FTTX or FT

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

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

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

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

Copyright©1998 JAHIS V1.0

29

JHLDEX10.DOC 00/09/21

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

Copyright©1998 JAHIS V1.0

30

JHLDEX10.DOC 00/09/21

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

Copyright©1998 JAHIS V1.0

31

JHLDEX10.DOC 00/09/21

Percent predicted after drug 投薬後推測率(APP)
投薬後の推測率は、基本単位コードへ接尾辞｢APP｣を適用することで識別される――
活量にAS4コードを使用して94010．1&APPとなる。

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

Copyright©1998 JAHIS V1.0

内容
ペーススパイク
SASマーカー
感知マーカー
ビートマーカーetc

32

JHLDEX10.DOC 00/09/21

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

LEN
1
4
180
180
180
180
26
40
7
20
3
8
15
180
2
2
2
6
60
16

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

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

RP/#

Y/3

図 2-8.

MSH attributes

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

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

Optionality
R required
O optional
C conditional on the trigger event or on some other field(s)X not used with this trigger event
B left in for backward compatibility with previous versions of HL7
RepetitionN- no repetitionY- the field may repeat an indefinite or site determined number of times(integer)- the field may repeat up to the number of times specified in the integer

MSHフィールド定義
フィールド定義
MSH-1 Field separator フィールド区切文字 (ST) 00001
定義： セグメントIDと最初の実フィールド(MSH-2-コード化文字)間のセパレーター。そのようなセパレータとしての他に、残りのメッセージでセパレータとして使う文字を定義する。
推奨値は | である。
MSH-2 Encoding characters コード化文字 (ST) 00002
定義： 次の順番で並べられた4文字、つまり、成分セパレータ、反復セパレータ、エスケー
プ文字、副成分セパレータ。推奨値は ^~\& である。メッセージ区切文字の解説を参照。
MSH-3 Sending application 送信アプリケーション (HD) 00003
定義： 送信アプリケーションを識別するために用いる。
MSH-4 Sending facility 送信施設 (HD) 00004
定義： 送信元施設を区別するため送信側の施設コードや略称などをセットする。
MSH-5 Receiving application 受信アプリケーション (HD) 00005
定義： 受信アプリケーションを識別するために用いる。
MSH-6 Receiving facility 受信施設 (HD) 00006
定義： 受信先施設を区別するため受信側の施設コードや略称などをセットする。

Copyright©1998 JAHIS V1.0

33

JHLDEX10.DOC 00/09/21

MSH-7 Date/time of message メッセージ日時 (TS) 00007
定義： 送信システムがメッセージを作成した日時。時間帯を指定した場合、それはメッセー
ジ全体でデフォルトの時間帯として使われる。
MSH-8 Security セキュリティ (ST) 00008
定義： セキュリティの実装に関する情報であるが、その使用法は未定である。
MSH-9 Message type メッセージ型 (CM)00009

Components: <message type (ID)> ^ <trigger event (ID)>

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

Description
Order message オーダーメッセージ
Observ result/unsolicited 検査結果

テーブル 0003
Value
O01
R01
W01

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

Description
ORM - Order message

オーダーメッセージ
ORU - Unsolicited transmission of an observation

検査結果転送ORU - Waveform result, unsolicited transmission of requested information

波形型結果転送

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

Components: <processing ID (ID)> ^<processing mode (ID)>

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

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

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

Description
Archive
Restore from archive
Initial load
Not present (the default, meaning current

processing)

MSH-12 Version ID バージョンID (ID) 00012
定義： 受信システムは、バージョンIDを認識しメッセージが確実に解釈されるようにする。
省略されている場合 2.3とみなす。
テーブル 0104 - Version ID
Value

Description

2.3

HL7 Release 2.3

1997

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

Copyright©1998 JAHIS V1.0

34

JHLDEX10.DOC 00/09/21

MSH-16 Application acknowledgment type アプリケーション肯定応答型 (ID) 00016
定義： このメッセージに応答してアプリケーション肯定応答を返すことが要求される条件を定義する。拡張肯定応答モードで要求される。取りうる値をテーブル0155に示す。
テーブル 0155 - Accept/application acknowledgment conditions アプリケーション肯定応答型
Value
AL
NE
ER
SU
注記：

Description
Always 常に
Never 決してない
Error/reject conditions only エラー/リジェクト状態のみ
Successful completion only 正常終了時のみ

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

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

Value

Description
The printable 7-bit ASCII character set .

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

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

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

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

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

8859/6

The printable characters from the ISO 8859/6 Character set

8859/7

The printable characters from the ISO 8859/7 Character set

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

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

JAS2020

A subset of ISO2020 used for most Kanji transmissions

JIS X 0202

ISO 2022 with escape sequences for Kanji

JIS X 0201-1976

Code for Information Exchange

JIS X 0208-1997

Code for the Japanese Graphic Character set for information interchange

JIS X 0212-1990

Code of the supplementary Japanese Graphic Character set for information interchange

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

異なる文字セットの反復はデータ型PNとXPNのみに適用される。本フィールドの指定がない
もしくは反復の第一成分がNullの場合はsingle-byte character set (ASCII (ISO IR-6))が適用される。本フィールドが出現し第一成分が特定される場合この文字セットがメッセージのデフォル
ト文字セットとなる。これはシングルバイト文字セットでなければならない。 (例えば ISO-IR
6, ISO-IR 13, ISO-IR 14, ISO-IR 100, etc.) 第二第三成分は代替文字セットが使用できダブルバ
イト文字セットも含まれる。 (例えば JIS X 0208) デフォルト文字セットは常にシングルバ
イト文字セットであり、ISO-IR 6 (ISO 646) or ISO-IR 14 (JIS X 0201-1976)の G0 域である。
半角カタカナは全てのフィールドで使用しないようにすること。漢字を使用する場合~JIS
X0208-1997が一般的で、さらにJIS補助漢字を使用する場合続けて~JIS X0212-1990とする。
MSH-19 Principal language of message 主要言語 (CE) 00693
定義： メッセージの主要言語を定義する。コードはISO 639を使用。
MSH-20 Escape sequence エスケープシーケンス (CE)
定義： 文字セットを切り替えるためのエスケープシーケンス方式を定義する。テーブル211
で示されるエスケープシーケンスを用いる。JIS X0202またはISO 2022。

Copyright©1998 JAHIS V1.0

35

JHLDEX10.DOC 00/09/21

6.2 NTE - notes and comments segment

注釈コメントセグメント

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

NTE attributes

SEQ

LEN

DT

1

4

SI

O

00096

ELEMENT NAME
Set ID - NTE セットID-NTE

2

8

ID

O

00097

Source of Comment コメント発生源

3

64k

FT

O

00098

Comment コメント

Y

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

Description
Ancillary (filler) department is source of comment

P

Orderer (placer) is source of commentO

Other system is source of comment

実施者がコメント発生源である依頼者がコメント発生源である

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

NTE-3 Comment コメント (FT) 00098
定義: 先行するセグメントに従属するコメント。

Copyright©1998 JAHIS V1.0

36

JHLDEX10.DOC 00/09/21

6.3 PID - patient identification segment

患者識別セグメント

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

LEN
4
16
20
12
48*n
48
26
1
48
1
106
4
40
40
60
1
3
20
16
25
20
3
60
2
2
4
60
80
26
1

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

図 3-2.

PID attributes

OPT

RP/#

R

Y
Y
Y

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

R

Y
Y
Y
Y

Y

PID属性
属性

ELEMENT NAME
Set ID - Patient ID セットID−患者ID
Patient ID (External ID) 患者ID(外部ID)
Patient ID (Internal ID) 患者ID(内部ID)
Alternate Patient ID - PID 代替患者ID
Patient Name 患者氏名
Mother's Maiden Name 母親の旧姓
Date/Time of Birth 生年月日
Sex 性別Patient Alias 患者別名
Race 人種
Patient Address 患者住所
County Code 郡コード
Phone Number - Home 電話番号−自宅
Phone Number - Business 電話番号−勤務先
Primary Language 言語−患者
Marital Status 婚姻状況
Religion 宗教
Patient Account Number 患者会計番号
SSN Number - Patient SSN番号−患者
Driver's Lic Num - Patient 運転免許証番号−患者
Mother's Identifier 母親の識別子
Ethnic Group 人種のグループ
Birth Place 誕生場所
Multiple Birth Indicator 多胎児誕生標識
Birth Order 誕生順序
Citizenship 市民権
Veterans Military Status 退役軍人状況
Nationality 国籍
Patient Death Date and Time 患者死亡日時
Patient Death Indicator 患者死亡識別PIDフィールド定義
フィールド定義
PID-1 Set ID - patient ID セットID−患者ID (SI) 00104
定義：セグメントの反復が許されるメッセージについては、反復を識別するためにセットID
フィールドが使用される。例えば、交換及び照会のトランザクションは、セットID値1、2、3、などの多数のPIDセグメントを持つことができる。
PID-2 Patient ID (external ID) 患者ID(外部ID) (CK) 00105
定義：患者がオフィスなどの外部の別の施設からきていればその施設のIDなどをここに表現する。これは多数の異種の会社や施設が共有することができるIDとなる。
PID-3 Patient ID (internal ID 患者ID(内部ID) (CX) 00106
定義：患者を一意的に識別するため施設によって使用されるID(たとえば患者IDやカルテ番号、
請求書番号など)
ORMメッセージを使用せず伝票による検査依頼で本フィールドに該当する情報が得られない
場合、ラボ側により付番されるIDを代入し付番組織を明示する。
PID-4 Alternate patient ID - PID 代替患者ID (ST) 00107
定義：第3のIDが患者を識別するために必要とされるかもしれない。例えば訪問番号、訪問期
日あるいは社会保障番号を含んでいる。患者IDとカルテ番号を併用するようなばあい従とな
るIDはこのフィールドを使用する。

Copyright©1998 JAHIS V1.0

37

JHLDEX10.DOC 00/09/21

PID-5 Patient name 患者氏名 (XPN) 00108
成分: <family name姓 (ST)> ^ <given name名 (ST)> ^ <middle initial or name (ST)> ^ <suffix(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code名前
タイプ (ID) > ^ <name representation code名前表示(ID)>テーブル 0200 - Name type 名前タイプコード
Value
A
L
D
M
C

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

テーブル 4000 – name representation code 名前表示コード
Value
I
A
P

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

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

PID-9 Patient alias 患者の別名 (XPN)

Description
Female女性
Male男性
Otherその他
Unknown未知

00112

PID-10 Race 人種 (IS) 00113
定義：患者の同意を得て使用することができる。
PID-11 Patient address 患者住所 (XAD)
定義：患者の現住所。
PID-12 County code 郡コード (IS)
定義：患者の郡コード。

00114

00115

PID-13 Phone number - home 電話番号−自宅 (XTN)

00116

PID-14 Phone number - business 電話番号−勤務先 (XTN)
PID-15 Primary language 言語−患者 (CE)
定義：患者の主要な言語。

Copyright©1998 JAHIS V1.0

00117

00118

38

JHLDEX10.DOC 00/09/21

PID-16 Marital status 婚姻状況 (IS)00119

使用者定義テーブル 0002 - Marital status婚姻状況
婚姻状況
Value

PID-17 Religion 宗教 (IS)A

Description
Separated 別居

DDivorced 離婚

M

Married 既婚

SSingle 未婚

W

Widowed 死別

00120

PID-18 Patient account number 患者会計番号 (CX) 00121
定義：料金、支払いなどがすべて記録される勘定によって割り当てられる数字。患者の会計を識別するために使用される。
PID-19 SSN number - patient SSN番号−患者 (ST)
定義：患者の社会保障番号。

00122

PID-20 Driver's license number - patient 患者の運転免許証番号 (CM)00123

成分：〈免許証番号〉＾〈発行の州、地方、国〉。

定義：患者の運転免許証番号。いくつかのサイトは、患者を識別する一意的な番号としてこれを使用してもよい。第2の成分のデフォルトは患者が登録されている州である。
PID-21 Mother's identifier 母親の識別子 (CX) 00124
定義：例えば新生児用にリンク・フィールドとして使用される。典型的に、患者IDあるいは会計番号が使用されるかもしれない。
PID-22 Ethnic group 人種のグループ (IS) 00125
定義：患者の民族的起源を定義する。
PID-23 Birth place 誕生場所 (ST) 00126
定義：患者の誕生の場所を示す。
PID-24 Multiple birth indicator多胎児誕生標識 (ID) 00127
定義：患者が多胎児の一人であったかどうか示す。Y/Nインジケータを使用。
PID-25 Birth order 誕生順序 (NM) 00128
定義：患者が多胎児の一人であった場合、誕生順序を示す値。
PID-26 Citizenship 市民権 (IS) 00129
定義：患者の市民権の国を示す。推奨値として、使用者定義テーブル0171−国コード又はISO3166を参照すること。
PID-27 Veterans military status 退役軍人の状況 (CE)00130

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

00740

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

Copyright©1998 JAHIS V1.0

39

JHLDEX10.DOC 00/09/21

6.4 PV1 - patient visit segment

来院情報セグメント

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

LEN
4
1
12
2
20
12
60
60
60
3
12
2
2
3
2
2
60
2
15
50
2
2
2
2
8
12
3
2
1
8
10
12
12
1
8
3
25
2
2
1
2
12
12
26
26
12
12
12
12
20
1
60

DT
SI
IS
PL
IS
CX
PL
XCN
XCN
XCN
IS
PL
IS
IS
IS
IS
IS
XCN
IS
CK
CM
IS
IS
IS
IS
DT
NM
NM
IS
IS
DT
IS
NM
NM
IS
DT
IS
IS
IS
IS
IS
IS
PL
PL
TS
TS
NM
NM
NM
NM
CX
IS
XCN

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

RP/#

Y
Y
Y

Y
Y

Y

Y
Y
Y
Y

Y

PV1 attributes

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

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

PV1フィールド定義
フィールド定義

Copyright©1998 JAHIS V1.0

40

JHLDEX10.DOC 00/09/21

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

Description
Emergency 救急
Inpatient 入院患者
Outpatient 外来患者
Preadmit 予備入院
Recurring Patient 再来院患者
Obstetrics 産科
Checkup 人間ドック

PV1-3 Assigned patient location 患者所在場所 (PL)00133

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

定義：病院、診療科、病棟、病室、ベッド等を表現する。新規の場所は最初に割当てた場所、あるいは患者の移動先の場所である。トランザクションの取消しや、退院の場合、現在の部屋番号をこのフィールド表現する。
注：PLデータ型のフィールドは値の第5の成分(ベッド状況)が存在する場合、それは、PV1-40の値に取って代わる。

使用者定義テーブル 0116 - Bed status
Value
C

Description
Closed 閉鎖

HHousekeepingO

OccupiedU

Unoccupied

K

ContaminatedI

Isolated

清掃

使用
空き
汚染

隔離

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

Description
Accident 事故
Emergency 救急
Labor and Delivery
Routine 通常

陣痛および出産

PV1-5 Pre-admit number 仮入院番号 (CX) 00135
定義：患者の仮入院番号を一意的に識別する。システムでは、仮入院番号を請求番号として患者が入院した後も使用し続けることもできる。
PV1-6 Prior patient location 患者の以前の所在 (PL) 00136
定義：新患であればここはNULLである。患者が転院されていれば、それは以前の患者所在を含んでいる。
PV1-7 Attending doctor 主治医 (XCN) 00137
定義：主治医の情報で、複数の名前やIDを持つ場合もある。
PV1-8 Referring doctor 紹介医師 (XCN) 00138
定義：紹介医師の情報で、複数の名前やIDを持つ場合もある。
PV1-9 Consulting doctor コンサルティング医師 (XCN)
定義：コンサルティング医師の情報。

Copyright©1998 JAHIS V1.0

41

00139

JHLDEX10.DOC 00/09/21

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

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

PV1-16 VIP indicator VIP標識 (IS) 00146
定義：VIPのタイプを識別する使用者定義コード。
PV1-17 Admitting doctor 入院時医師 (XCN) 00147
定義：入院時の医師の情報、複数の名前やIDのこともある。
PV1-18 Patient type 患者タイプ (IS) 00148
定義：患者のタイプを示すサイト特定の値。
PV1-19 Visit number 来院回数 (CK) 00149
定義：患者の各来院に割り当てられた一意的な数。
PV1-20 Financial class 財務クラス (CM) 00150
定義：診療報酬の源を識別する目的で患者に割り当てられた、主要な財務のクラス。
PV1-21 Charge price indicator 有償価格標識 (IS) 00151
定義：部屋およびベッドの料金にどの価格表を使用するか決めるために使用されるコード。
PV1-22 Courtesy code 優待コード (IS) 00152
定義：患者が特定の優待を受けるかどうか示すコード。
PV1-23 Credit rating 信用格付け (IS) 00153
定義：過去の信用経験を決定する使用者定義コード。
PV1-24 Contract code 契約コード (IS) 00154
定義：会計残高を決済するための施設および保証人による契約のタイプを識別する。

Copyright©1998 JAHIS V1.0

42

JHLDEX10.DOC 00/09/21

PV1-25 Contract effective date 契約有効日付 (DT)
定義：契約が始まる日付。

00155

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

00160

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

00162

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

00163

PV1-34 Delete account indicator 会計削除標識 (IS) 00164
定義：会計がファイルから削除されたこと及びその理由を示す。
PV1-35 Delete account date 会計削除日付 (DT) 00165
定義：会計がファイルから削除された日付。
PV1-36 Discharge disposition 退院処置 (IS) 00166
定義：退院(つまり、帰宅；期限満了；など)の時の患者の処置。
PV1-37 Discharged to location 退院先 (IS) 00167
定義：患者の退院先の施設を示す。
PV1-38 Diet type 給食タイプ (IS) 00168
定義：患者用の特別の給食タイプを示す。
PV1-39 Servicing facility サービス施設 (IS) 00169
定義：複数の施設環境の中でこの来院が関係している施設を示す。
PV1-40 Bed status ベッド状況 (IS) 00170
定義：下位互換のためののみ使用。PLデータ型の第5成分状況を使用すること。
PV1-41 Account status 会計状況 (IS)
定義：会計状況

00171

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

00174

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

Copyright©1998 JAHIS V1.0

00175

43

JHLDEX10.DOC 00/09/21

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

00177

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

00176

00178
00179

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

Description
Account Level 会計
Visit Level 来院

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

Copyright©1998 JAHIS V1.0

44

JHLDEX10.DOC 00/09/21

6.5 AL1 - patient allergy information segment

患者アレルギー情報

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

LEN
4
2
60
2
15
8

DT
SI
IS
CE
IS
ST
DT

OPT
R

図 3-6.

AL1 attributes

ITEM#
00203
00204
00205
00206
00207
00208

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

RP/#

R

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

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

AL1-3 Allergy code/mnemonic/description アレルギーコード/記憶法/記述 (CE) 00205
定義：一意的に、特別のアレルギーを識別する。この要素は、ある外部かつ標準のコード化するシステム(それは識別されねばならない)に一致させたり、あるいは、局所的な記述、主に文章の記述あるいは記憶法の記述によっても良い。
AL1-4 Allergy severity アレルギー重症度 (IS) 00206
定義：アレルギー(重度、中程度、軽度など)の一般的な重症度を示す。テーブル128参照。
使用者定義テーブル 0128 - Allergy severity アレルギー重症度

Value

Description

SV
MO
MI

Severe重度
Moderate 中程度
Mild
軽度

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

Copyright©1998 JAHIS V1.0

45

JHLDEX10.DOC 00/09/21

共通オーダーセグメント

6.6 ORC - common order segment

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

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)残りの、未実施の子は要求の結果として取り消される。
図 4-1.
SEQ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

LEN
2
22
22
22
2
1
200
200
26
120
120
120
80
40
26
200
60
60
120

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

Copyright©1998 JAHIS V1.0

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

RP/#

Y/2

ORC attributes
ITEM#
00215
00216
00217
00218
00219
00220
00221
00222
00223
00224
00225
00226
00227
00228
00229
00230
00231
00232
00233

ORCの属性の属性

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

46

JHLDEX10.DOC 00/09/21

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

Value
NW
OK
UA

Description
New order 新規オーダー
Order accepted & OK オーダー受付 & OK
Unable to Accept Order 受付オーダーキャンセル

Originator2
P
F
F

Field Note3
I
I
n

CA
OC
CR
UC

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

P
F
F
F

a

DC
OD
DR
UD

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

P
F
F
F

HD
OH
UH
HR

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

P
F
F
F

RL
OE
OR
UR

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

P
F
F
F

RP
RU
RO
RQ
UM

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

P
F
P,F
F
F

e,d,h
f,d,h
g,d,h,ld,e,g,hPA
CH

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

F
F,P

I
i

XO

Change order request

Copyright©1998 JAHIS V1.0bcP

オーダー変更要求47

JHLDEX10.DOC 00/09/21

Value1XX
UX
XR

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

Originator2
F
F
F

Field Note3

DE
RE
RR
SR
SS
SC
SN
NA
CN

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

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

l
l
m

RF
AF
DF
FU
OF
UF

Refill order request 補充オーダー要求
Order refill request approval 補充オーダー要求承認
Order refill request denied 補充要求オーダー拒否
Order refilled, unsolicited オーダー補充済、非要求
Order refilled as requested オーダー補充済、
Unable to refill 補充不可

F, P
P
P
F
F
F

o
p
q
r
s
t

j
k

注記:
1

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

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

3

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

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

Copyright©1998 JAHIS V1.0

RU and RO usage (example)

Order Control
RU

Comment
1st replaced ORC

48

JHLDEX10.DOC 00/09/21

Segment
OBR

Order Control

Comment
1st replaced order's detail segment

ORC
OBR

RU

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

ORC
OBR

RO

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

ORC
OBR

RO

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

ORC
OBR

RO

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

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

RQ and RO usage (example)

Order Control
RQ

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

ORC
OBR

RQ

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

ORC
OBR

RO

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

ORC
OBR

RO

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

ORC
OBR

RO

3rd replacement ORC
3rd replacement order's detail segmente)

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

Copyright©1998 JAHIS V1.0

49

JHLDEX10.DOC 00/09/21

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

Example of two child orders

Segment
ORC
ORC
OBR

Order Control
PA
CH

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

ORC
OBR

CH

2nd child ORC
2nd child order

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

MSH
PID
ORC
RXO

Order Control

RE usage (example)
Comment

NW

First new orderFirst order segment

ORC
RXO
[ORC
OBR]
OBX
OBX
OBX
OBX

NW

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

ORC
RXO

NW

RE

3rd order
3rd order segment

HL7のこのバージョンにおいて、結果は、1個以上のOBXセグメントとしてオーダーと共に送ることができる。但し、ORCとOBRセグメントを必ずしも含む必要はない。
検査情報は、ORCを使用せずに、ORUメッセージを用いて伝えることができる。

Copyright©1998 JAHIS V1.0

50

JHLDEX10.DOC 00/09/21

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

Code

From

ORC-2-Placer Order Number

ORC-3-Filler Order NumberSNfiller application

placer order number^filler application ID

null

NA

other application

placer order number^filler application ID

filler order number^filler application ID

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

Copyright©1998 JAHIS V1.0

51

JHLDEX10.DOC 00/09/21

NAのORC-1-オーダー制御値、最近割り当てられたORC-2-依頼者オーダー番号、およびORC-3-実施者オーダー番号(SN値を持つORCから)を含む。
注： 新しいORC‑2‑依頼者オーダー番号は、依頼者のアプリケーションIDを持っている。
Code
From
SN
filler applicationNAother application

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

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

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

From

ORC-2-Placer Order Number

other application to the filler

placer order number^placer application ID

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

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

Copyright©1998 JAHIS V1.0

Patient unknown to the provider
Patient never under provider care
Patient no longer under provider care
Patient has requested refill too soon
Medication never prescribed for the patient

52

JHLDEX10.DOC 00/09/21

AF
AG

Patient should contact provider first
Refill not appropriater)FU
FUは依頼者に対して､実施者が補充を患者の要求によるオーダーに対して発行したことを通知する｡.
s) OF
OFは補充に対する依頼者システムの要求に直接応答する｡
t) UF
UFは実施者システムが許可補充要求に対してアプリケーションレベル拒否を示す｡
ORC-2 Placer order number 依頼者オーダー番号 ( EI) 00216
定義：依頼アプリケーションのオーダー番号
第1成分は、個々のオーダー(たとえば、(OBR))を識別する15文字までの文字列である。それは、依頼者(依頼アプリケーション)によって割り当てられる。それは、特定の依頼アプリケー
ションからのすべてのオーダーの中から一意に一つのオーダーを識別する。第2成分は依頼ア
プリケーションのアプリケーションIDを含む。アプリケーションIDは、アプリケーションに一意に関連する6つの文字までの文字列である。ひとつの施設または相互に通信する施設のグ
ループは、アプリケーションで一意のリストを確立すべきである。リストは潜在的な依頼者と2つの成分は、実施者であってもよく、
そして一意なアプリケーションIDを割り当ててもよい。
共通の区切り文字によって分離される。
このように一意ではなく、真の依頼者がいくらかあいまいな3つの状態がある。
a) RU取替えに続く、ROのORC-1-オーダー制御値の場合；b) CH(子オーダー)のORC-1-オーダー制御値の場合；
c) SN(番号を送ること)のORC-1-オーダー制御値の場合；
ORC-2-依頼者オーダー番号がこれらの場合どのように割り当てられるかの詳細については、
ORC-1-オーダー制御の下のテーブルの注を参照すること。
ひとつの施設または相互に通信する施設のグループは、アプリケーションで一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプリケ
ーションIDを割り当ててもよい。アプリケーションIDリストは、本規格の他の箇所で文書化されている、施設のマスタ辞書の1つになる。第三者アプリケーション(オーダーの依頼者および実施者以外)がORMとORRのメッセージ送受信ができるので、このフィールドの依頼アプリ
ケーションIDは、ネットワーク上の送信および受信アプリケーションと同じでなくともよい(MSHセグメントにおいて述べた)。
ORC-2-依頼者オーダー番号は、OBR-2-依頼者オーダー番号と同じある。依頼者オーダー番
号がORCの中に存在していないならば、それは関連したOBR内に存在しなければならない。
その逆もまた真である。もし両方のフィールド、すなわちORC-2-依頼者オーダー番号およびOBR-2-依頼者オーダー番号が設定されるならば、それらは同じ値でなければならない。結果がORUメッセージで送られるとき、ORCは必要ないが、依頼者オーダー識別番号がOBRセグ
メント内に存在せねばならない。
これらの規則は、上位互換性のためORCとOBRの両方の中に存在している他のフィールドにも適用する。(たとえば、数量/タイミング、親番号、オーダー依頼者、および依頼コールバ
ック用電話番号)。
ORC-3 Filler order number 実施者オーダー番号 ( EI) 00217
定義： 実施アプリケーションに関連したオーダー番号。その第1成分は、オーダー詳述セグメ
ントを識別する15文字の文字列である(例 OBR)。それは、オーダー実施(受け取る)アプリケ
ーションによって割り当てられる。この文字列は、特定の実施アプリケーション(例 臨床検査)の他のオーダーから、そのオーダー(オーダー詳細セグメントにおいて明示されるように)を、一意に識別せねばならない。一意性は長時間にわたって持続しなければならない。
第2成分は、実施アプリケーションIDを含んでいる。実施アプリケーションIDは、6文字までの文字列であり、アプリケーションをネットワーク上の他のアプリケーションから識別する。
実施者オーダー番号の第2成分は、オーダーの実際の実施者を常に識別する。
ある施設または相互通信施設グループは、アプリケーションの一意のリストを確立すべきである。リストは潜在的な依頼者と実施者であってもよく、そして一意なアプリケーションIDを割り当ててもよい。アプリケーションIDリストは、本規格の他の箇所で文書化されている、

Copyright©1998 JAHIS V1.0

53

JHLDEX10.DOC 00/09/21

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

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

ORC-6 Response flag 応答フラグ (ID) 00220
定義：これによって依頼者(送信)アプリケーションは、実施者から返されるべき情報の量を決定できる。要求されたレベルの応答は、即時には可能ではないかもしれない、しかし、それがCopyright©1998 JAHIS V1.0

54

JHLDEX10.DOC 00/09/21

可能なときは、実施者(受信)アプリケーションは、情報を送らなければならない。フィールドがnullであるとき、フィールドのデフォルト値はDである。取りうる値についてはテーブル
0121-応答フラグを参照のこと。
テーブル 0121 - Response flag
Value
E
R
D
F
N

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

ORC-7 Quantity/timing 数量/タイミング (TQ) 00221
定義：優先度、数量、頻度およびアトミックサービスのタイミングを決定する。オーダーセグ
メントは、アトミックサービスを記述するものとして考えられる必要がある。それは、第4.4
節において詳細に定義される複合フィールドである。
たとえば、OBRセグメントが血液の単位を記述するとし、このフィールドによって三つの単位が毎朝続けて与えられるように要求する。この場合ORC-7-数量/タイミングは『1-XQAM＾X3』である。ORC-7-数量/タイミングは、OBR-27-数量/タイミングと同じである。
ORC-8 Parent 親 (CM)00222

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

定義：親子のメカニズムの関係が存在するとき子を親に関係付ける。親子のメカニズムは、
ORC-1-オーダー制御の注のところで述べられる。第1成分は、親オーダーの依頼者オーダー番号を含んでいる。それは、オーダーが子であるとき要求される。
第2成分は、親オーダーの実施者オーダー番号を含んでいる。
依頼者オーダー番号と実施者オーダー番号との成分は、このフィールドの2つの成分の副成分として送られる。ORC-8-親は、OBR-29-親と同じである。
ORC-9 トランザクション日時 Date/time of transaction (TS) 00223
定義： このトランザクションがオーダーアプリケーションに入る日時。新規オーダーを作成するメッセージの場合は、これは、オーダーが入れられた日付および時間である。
たとえば、キャンセルなどの他のメッセージの場合は、このトランザクションが送信アプリ
ケーションに入る日時である。この日付と時間は、現在のトランザクションのためのもので、オリジナルのオーダーへの訂正のための『取り換え』た時刻ではない。同様に、このセグメン
トのORC-10-入力者、ORC-11-検証者、およびORC-13-入力の場所も現在のトランザクションに関連づけられ、オリジナルのオーダーに関連づけてはいない。
ORC-10 入力者 Entered by (XCN) 00224
定義： 要求をアプリケーションに実際に打鍵した人の所属氏名。それは、要求が不正確に入れられ、関連部門が要求を明らかにする必要がある場合、監査証跡となる。現場の取り決めによって、ID 番号または名前成分は、省略されてもよい。
ORC-11 Verified by 検証者 (XCN) 00225
定義： 入れられた要求の精度を検証した人の所属氏名。それが使用されるのは、要求が技師によって入力され、看護婦などのより高い権威者によって検証される必要がある場合である。
現場の取り決めによって、ID 番号や名前成分は、省略されてもよい。
ORC-12 Ordering provider オーダー依頼者 (XCN) 00226
定義： 要求を作成することに責任がある依頼する医師などの所属氏名。ORC-12-オーダー依頼者は、OBR-16-オーダー依頼者と同じである。
ORC-13 Enterer's location 入力者の場所 (PL) 00227
定義： 要求を入力した人の場所(たとえば、部門、階)。それは、部門のあるサブカテゴリーを含むためサイト固有のベースに基づいて使用されてもよい複合フィールドである。たとえば、
ICU4は、4階のICUの場所の呼称とするなど。

Copyright©1998 JAHIS V1.0

55

JHLDEX10.DOC 00/09/21

ORC-14 Call back phone number コールバック用電話番号 (XTN) 00228
定義： 要求またはオーダーに関して、必要な他の情報を確認するための電話番号。ORC-14コールバック用電話番号は、OBR-17-オーダーコールバック用電話番号と同じである。
ORC-15 Order effective date/time オーダー有効の日時 (TS) 00229
定義： 変更要求が有効になった、あるいは、有効になる予定の日時。
ORC-9-トランザクション(日時)が、ORC-15-オーダー ［訳注：原文はORC-16-オーダーとなっているが、明らかな間違いのため修正した］有効日時の後またはそれに等しくなっているなら
ば、ORCおよびその下のセグメントにおけるデータ値はこの日時に有効になった。
ORC-9-トランザクション 日時がORC-15-オーダー有効日時より前ならば、ORCおよびその下位セグメントのデータ値は、オーダー有効日時に有効になるよう計画される。
有効ORC-15-オーダー有効日時が空白にしておかれるならば、その値は、ORC-9-トランザク
ション日時と等しいと仮定される。また、トランザクション日時が空白であるならばMSH-7メッセージと等しいと仮定される。
ORC-15-オーダー有効日時(同じORCセグメントのオーダー制御コードイベントのために)が、ORC-7-数量/タイミングと異なる場合は、ORC-15-オーダー有効日時が優先する。一例として
ORCイベントが実施者への連続オーダーに対する中断要求であり、かつオーダー有効日時がORC-7-数量/タイミング終了日時の前にあるならば、オーダー有効日時が優先する。ORCの中で識別されたオーダーが子を持っているならば、開始しなかった子は取り消される必要があ
る；プロセスに子がいるならば、それは中断される必要がある；子が中断できる点を超えて前進しているならば、その状態は影響されない。
ORC-16 Order control code reason オーダー制御コード理由 (CE) 00230
定義： オーダー制御コード(テーブル0119)によって述べたオーダーイベントの理由の説明。
コード化したあるいはテキスト形式のどちらでもよい。オーダー特定のセグメント(たとえば、
RXO、ORO、OBR)の後のNTEは、その特定のセグメントのためにコメントとなる。もうひとつ、オーダー制御コード理由の目的には、そのオーダーイベントの理由を拡張することがある。
ORC-1-オーダー制御がNWであるときは、ORC-16-オーダー制御コード理由に、普通は値を設定しない。ただし、設定できないわけではない。取り消されたオーダーのときには、たとえば、このフィールドは、一般的に、キャンセルの理由を説明するために使用される。
良く実証されたアレルギーのために医者からの処方オーダーをキャンセルした調剤システ
ムは、このフィールドでアレルギーの事実が多分報告される。
それが薬理相互作用のためにこのオーダーをキャンセルしたならば、このフィールドは、相互作用物質の少なくとも名称(およびコード、必要とするならば)となる。文章で相互作用、および相互作用の激しさの程度を述べる。
ORC-17 Entering organization 入力組織 (CE) 00231
定義： 入力者がオーダーを入力/修正した時に属していた組織
ORC-18 Entering device 入力装置識別 (CE) 00232
定義： オーダーを入力するため使用された物理的装置(端末やPC)の識別子
ORC-19 Action by 発動者 (XCN) 00233
定義： 対応するオーダー制御コードによって表されたイベントを発動した人の所属氏名。たとえば、オーダー制御コードがCA(オーダーキャンセル依頼)であるならば、このフィールドは、
オーダーキャンセルを要求した人を表す。

Copyright©1998 JAHIS V1.0

56

JHLDEX10.DOC 00/09/21

6.7 OBR - observation request segment

検査要求セグメント

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

LEN
4
75
75
200
2
26
26
26
20
60
1
60
300
26
300
80

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

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

Copyright©1998 JAHIS V1.0

RP/#

Y

Y

図 4-8.

OBR attributes

ITEM #
00237
00216
00217
00238
00239
00240
00241
00242
00243
00244
00245
00246
00247
00248
00249
00226

ELEMENT NAME
Set ID - Observation Request ID設定 − 検査要求
Placer Order Number 依頼者オーダー番号
Filler Order Number + 実施者オーダー番号
Universal Service ID 検査項目群ID
Priority 優先度
Requested Date/time 要求日時
Observation Date/Time # 検査/採取日時
Observation End Date/Time # 検査/採取終了日時
Collection Volume * 採取量
Collector Identifier * 採取者識別子
Specimen Action Code * 検体処置コード
Danger Code 危険(検体)コード
Relevant Clinical Info. 関連臨床情報
Specimen Received Date/Time * 検体受理日時
Specimen Source * 検体採取元
Ordering Provider 依頼者

57

OBR属性
属性

JHLDEX10.DOC 00/09/21

17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

40
60
60
60
60
26
40
10
1
200
200
150
150
20
300
200
200
200
200
26
4
60
200
60
30
1
200

XTN
ST
ST
ST
ST
TS
CM
ID
ID
CM
TQ
XCN
CM
ID
CE
CM
CM
CM
CM
TS
NM
CE
CE
CE
ID
ID
CE

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

Y/2

Y
Y/5

Y
Y
Y
Y

Y
Y

Y

00250
00251
00252
00253
00254
00255
00256
00257
00258
00259
00221
00260
00261
00262
00263
00264
00265
00266
00267
00268
01028
01029
01030
01031
01032
01033
01034

Order Callback Phone Number ｵｰﾀﾞｰｺｰﾙﾊﾞｯｸ用電話番号
Placer field 1 依頼者フィールド1
Placer field 2 依頼者フィールド2
Filler Field 1 + 実施者フィールド1
Filler Field 2 + 実施者フィールド2
Results Rpt/Status Chng – Date/Time + 結果報告/状態変更-日時
Charge to Practice + 課金
Diagnostic Serv Sect ID 診断部門IDResult Status + 結果状態
Parent Result + 親結果
Quantity/Timing 数量/タイミング
Result Copies To 結果配布先
Parent Number * 親番号Transportation Mode 患者移動モード
Reason for Study 検査理由
Principal Result Interpreter + 結果判定責任者
Assistant Result Interpreter + 結果判定アシスタント
Technician + 医療技術者
Transcriptionist + 口述記録者
Scheduled Date/Time + 予定日時
Number of Sample Containers * 検体容器数
Transport Logistics of Collected Sample * 採取検体搬送
Collector's Comment * 採取者コメント
Transport Arrangement Responsibility 搬送調整者
Transport Arranged 搬送調整結果
Escort Required 随行者要否
Planned Patient Transport Comment 患者搬送コメント

OBRフィールド定義
フィールド定義
OBR-1 Set ID - observation request セットID-OBR (SI) 00237
定義： 最初の送信オーダーには通し番号1が割り当てられ、2番目のオーダーには通し番号2が割り当てられるものとする。3番目以降同様。
OBR-2 Placer order number 依頼者オーダー番号 ( EI) 00216
定義： ORC−2−依頼者オーダー番号に同じ。依頼側検体番号など。
第1成分は最大15文字の文字列で個々のOBRを識別する。これは依頼者(依頼アプリケーション)によって割り当てられ、ある依頼アプリケーションから送信されるすべてのオーダーの中から特定のオーダーを一意に識別する。アプリケーションIDは最大6文字の文字列で、特定のアプリケーションと一意に結び付けられている。
OBR-3 Filler order number 実施者オーダー番号 ( EI) 00217
定義： オーダーおよびその関連する検査に対する永久的な識別子。ラボ側検体番号など
第1成分は個々のOBRを識別する文字列である。これは実施(受信)アプリケーションによって割り当てられ、ある実施アプリケーション(たとえば臨床生理検査室)からのすべてのオーダーの中から特定のオーダーを一意に識別する。第2成分は実施アプリケーションIDである。OBR−3−実施者オーダー番号はORC−3と同一である。
OBR-4 Universal service ID 検査項目群ID (CE) 00238
定義： 要求された検査/試験/セットの識別子コード。このコードは、ローカル・コードまたは 汎用 コードのいずれか、もしくはその両方を基準に設定できる。 汎用 手順による識別子を使用することが望ましい。
個々の検査項目を指示する場合は日本臨床病理学会臨床検査項目分類コードでコーディング
した使用。検査項目コードについてを参照。
個々の検査項目をOBXセグメントで指定する場合は、検査分野や検査セットを設定する。その場合コードや名称は施設固有である旨をコード体系Lで明示する。例：C123^生化学^L。
OBR-5 Priority 優先度 (ID) 00239
定義： 使用せず。以前の優先度はOBR−27−数量/タイミングの第6成分で指示する。

Copyright©1998 JAHIS V1.0

58

JHLDEX10.DOC 00/09/21

OBR-6 Requested date/time 要求日時 (TS)
定義： 検査を依頼した日時

00240

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

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

OBR-12 Danger code 危険(検体)コード (CE) 00535
定義： 危険であることが知られている、あるいは疑われる患者・検体を示すコードかテキス
ト、あるいはその両方(たとえば陽性結核患者、肝炎患者の血液などの感染情報)。コードとテキストのどちらかあるいはいずれも指定しない場合がある。

Copyright©1998 JAHIS V1.0

59

JHLDEX10.DOC 00/09/21

OBR-13 Relevant clinical information 関連臨床情報 (ST) 00247
定義： このフィールドには、患者あるいは検体に関する追加臨床情報が記述される。このフィールドは、検査診断が要求された場合、疑われる病状や臨床所見を報告するのに使用する。
たとえば、血中ガスの二酸化炭素量、パップ試験時の月経周期、および検査診断に影響を及ぼすその他の条件を報告する場合など。
ただし、オーダーセグメントの直後に一連のOBXセグメントを追加することで、より構造化された形式でこの種の情報を送ることが可能である。したがって、身体情報(身長・体重やバ
イタルサインなど)、検査情報、投薬情報などはOBXセグメントを利用することを推奨する。
OBR-14 Specimen received date/time 検体受領日時 (TS) 00248
定義： 検体を必要とする検査の場合、診断サービスの実際のログイン時間/検体受領日時。
OBR-15 Specimen source 検体採取元(検査材料) (CM) 00249
成分:<検体採取元名あるいはコード(CE)>＾<添加剤(TX)>＾<フリーテキスト(TX)>＾<部位(CE)>＾<部位修飾子(CE)>＾<採取方法修飾子(CE)>定義： 検体の採取部位や医療サービスの対象となる部位や検査材料を示す。検体採取後の検体検査では実際の提出材料を示すこと。日本臨床病理学会臨床検査項目分類コード材料の使用を推奨する(5.2 材料・採取部位コードについてを参照)。検査項目が材料を暗黙に指定している場合は指示不要である。
第1成分には、検体採取元名あるいはコード(CEデータ型成分と同様)が記述される。(検査名により検体採取元名が類推できる場合でも、検体採取元名を指定した方がよいことがある。たとえば血液培養−心臓血液)第2成分には、適用可能な場合、ヘパリン、EDTA(すなわちシュウ酸塩)など、検体に加える添加剤を記述する。
第3成分はフリーテキストで、オーダーの一部として採取法を指定する場合にその採取法を記述する。採取法が理論上検査結果となる場合はOBX結果セグメントを使用すべきである。
第4成分は検体を採取する部位を指定する。第5成分は部位修飾子である。たとえば、検体採取
部位が 対肘窩(anticubital fossa) で、部位修飾子が 右 。成分はCE型で副成分よりなる。
第6成分は検体採取における扱いを示し、値は、F-凍結、R-冷蔵、空白-室温を用いる。
OBR-16 Ordering provider 依頼者 (XCN) 00226
定義： 検査依頼者のID。IDコードあるいは名前、またはその両方を指定できる。これはORC−12−依頼者と同じである。検査依頼医師をセットする。
OBR-17 Order callback phone number オーダーコールバック用電話番 (XTN) 00250
号定義： 状態あるいは結果を標準フォーマットで報告するさいの電話番号。可能であれば、
内線または呼出番号(あるいはその両方)も併せて指定する。
OBR-18 Placer field #1 依頼者フィールド＃1 (ST) 00251
定義： 依頼者フィールド＃1。依頼者によって送られたテキストは、結果と共に返される。
OBR-19 Placer field #2 依頼者フィールド＃2 (ST)
定義： 依頼者フィールド＃1に類似。

00252

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

00254

OBR-22 Results rpt/status chng - date/time 結果報告/状態変更−日時 (TS) 00255
定義： 結果の報告日時、あるいは状態の変更日時。このフィールドでは、結果を報告書に書込み・発行した日時を示す。あるいはオーダー状態に定義にされたような状態が入力・変更された日時を示す。通常、依頼側は最後に結果を受信した日時(前回更新日)より後で報告された
結果だけ入力すべきである。(電文発信日ではない)
OBR-23 Charge to practice 課金 (CM) 00256
定義： 適用可能な場合には、実施検査についてオーダー本体に課せられる金額。第1成分には金額(実施者が知っている場合)を指定する。第2成分には課金コード(実施者が知っている場

Copyright©1998 JAHIS V1.0

60

JHLDEX10.DOC 00/09/21

合)を指定する(結果専用)。
OBR-24 Diagnostic serv sect ID 診断サービス部門ID (ID) 00257
定義： 診断を実施した診断サービス部門。検査が外部サービスによって実施された場合、そのサービスのIDがここに記録される。採りうる値については、テーブル0074−診断サービス
科ID−を参照のこと。外注先検査センターをセットする。
テーブル 0074 - Diagnostic service section ID
Value
AU
BG
BLB
CUS
CTH
CT
CH
CP
EC
EN
HM
ICU
IMM
LAB
MB
MCB
MYC
NMS
NMR
NRS

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

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

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

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

OBR-26 Parent result 親結果 (CM) 00259
成分: <OBX-3-observation identifier of parent result> ^ <OBX-4-sub-ID of parent result> ^<OBX-5-observation results from parent (CE)>
定義： このフィールドは他のタイプ(たとえば毒物学)との連携を可能にするために定義される。この重要な情報は、OBR-29-親番号の情報と組み合わせて、このオーダーに関する親結果のOBXセグメントを一意に識別する。親結果内のOBXセグメント値は、この検査セットが報告する生物や化学種を示す。たとえば、現在の検査セットが感受性試験である場合、親結果の一意なOBXは、この感受性試験の対象となる生物である。親結果内の生物名が最終的に決定される前にいくつか変遷をたどることがあるので、この間接的な連係を使用するとよい。
第3成分には直接親結果の微生物名を記録する。この場合の生物は、親培養検査の結果どおりに記載すべきである。

Copyright©1998 JAHIS V1.0

61

JHLDEX10.DOC 00/09/21

このフィールドは、親結果がOBR-29-親番号によって識別される場合のみ必要になる。
標準に検査結果セグメント(OBX)を使用してこの情報を伝達する方法もある。生物が複数存在する場合、OBX−4−サブIDで複数の生物種から個々を識別する。この場合、サブID Nを持つ最初のOBXは、N番目の微生物を識別する値を持つ。また、サブID Nを持つ後続のOBXはそれぞれ、この生物の感受性試験に使用する感受性値を持つ。
OBR-27 Quantity/timing 数量/タイミング (TQ) 00221
定義： 1回のサービスで施すサービスの数、そのサービスの繰り返し数に関する情報。これにより要求の継続時間を固定する。数量/タイミング解説参照。
OBR-28 Result copies to 結果配布先 (XCN) 00260
定義： 検査報告書を受け取る人。ローカルの取り決めによって、ID番号あるいは名前のいずれかを省略してもよい。報告書送付先として科別や病棟を指示してもよい。
OBR-29 Parent number 親番号 (CM) 00261
定義： ORC−8−親と同一。親子関係が存在する場合、このフィールドにより子供をその親に関連づける。たとえば、前回の検査(たとえば血液培養で展開された抗生物質感受性)によって展開された検査は、このフィールドに親(血液培養)の実施者オーダー番号を記録する必要がある。子オーダーの場合に、このフィールドが必要になる。
親フィールドには、成分が2つある。第1成分には親の依頼者オーダー番号が入る。第2成分はオプションであり、ここには親の実施者オーダー番号が入る。このフィールドは、副成分をもつ、依頼者オーダー番号成分と実施者オーダー番号成分の2つの成分で伝達される。
OBR-30 Transportation mode 患者移動モード (ID) 00262
定義： 適用可能な場合、患者を移動するかどうか(あるいは移動方法)。採りうる値に関して
は、テーブル0124−患者移動モード−を参照のこと
テーブル 0124 - Transportation mode 移動モード
Value
CART
PORT
WALK
WHLC

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

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

00265

00266

OBR-35 Transcriptionist 口述筆記者 ( CM) 00267
定義： 報告書の口述筆記を担当する人
OBR-36 Scheduled - date/time スケジュール日時 (TS) 00268
定義： 実施者がスケジュールした検査日時。このフィールドは、ある特定の検査をスケジュールして欲しいという要求に対する結果を表しており、これによりスケジュールされた検査日時を依頼者に通知することができる(結果専用)。
OBR-37 Number of sample containers 検体容器数 (NM) 01028
定義：受領検体容器の数。検体受領の検証のために使用、オーダーの全検体数とは異なるかもしれない。
OBR-38 Transport logistics of collected sample 採取検体搬送 (CE) 01029
定義：このフィールドは診断サービス実施者への検体到着で意味がある。これにより検査スケ
ジュールや結果に要する期間などが可能となる。例えば定期トラック便、郵便など。

Copyright©1998 JAHIS V1.0

62

JHLDEX10.DOC 00/09/21

OBR-39 Collector's comment 採取者コメント (CE) 01030
定義：検体に関する付加的コメント、例えば変性により凝固困難
OBR-40 Transport arrangement responsibility 搬送調整者 (CE) 01031
定義：予約検査などで検体搬送の手配などを行った者。例えば依頼者、実施者、患者など。
OBR-41 Transport arranged 搬送調整結果 (ID)
定義：検体搬送手配の結果状態。

01032

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

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

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

Description
Required必要
Not Required 不要
Unknown
不明

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

Copyright©1998 JAHIS V1.0

63

JHLDEX10.DOC 00/09/21

6.8 OBX - observation/result segment

検査結果セグメント

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

LEN
10
2
590
20
65536
60
10
5
5
2
1
20
26
200
60
80
60
1

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

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

RP/#

Y

Y/5
Y

Y

OBX attributes
ITEM#
00569
00570
00571
00572
00573
00574
00575
00576
00577
00578
00579
00580
00581
00582
00583
00584
00936

OBX属性
属性

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

OBXフィールド定義
フィールド定義
OBX-1 Set ID - observation simple セットID-単純検査 (SI) 00569
定義： 通し番号。ASTMとの互換性を維持するためのもの
OBX-2 Value type値型 (ID) 00570
定義: OBX内の検査結果値のフォーマット。値がCEである場合､結果はコード化入力値でなければならない。値型がTXまたはFTである場合、結果はテキスト群である。値型の検査で採りうる値はテーブル0125-値型に列記される(5.4データ型を参照)。たとえば、PNは成分区切り文
字により分離した6つの成分から成る。NMは有効な型であるが、通常数字として報告される検査では、結果の一部として非数値文字が報告されることが多いので(結果が測定器で計りきれないことを示すために>300を使う場合など)、文字列(ST)データ型を持つことがある。たとえば">300"では、">"は記号であり桁"300"は数値と考えられる。
以下を除くすべてのHL7データ型が有効である｡
CM: 特定のデータ型でないから､
CQ: OBX-5-検査値の単位は、OBX-6-単位に必ず明示的に指定されるから､SIシーケンスID: HL7メッセージセグメント以外に適用されないから｡
実際の検査値がOBXでは送られていないが、他のどこかに存在する場合、RP値(参照ポインタ)を使用しなければならない。たとえば、検査が画像(ドキュメント関連画像あるいは医学関連
画像)から成る場合、画像そのものはOBXで送ることができない。その場合送信システムは、
参照ポインタを送信するよう選択することができる。受信システム側は、ACR-NEMAなどの他の標準インターフェースにより、あるいは適切なデータベースサーバーにより実際の画像へアクセスする必要がある場合は、いつでもこの参照ポインタを使用することができる。

Copyright©1998 JAHIS V1.0

64

JHLDEX10.DOC 00/09/21

テーブル 0125 - Value type 値型
Value
AD
CE
CF
CK
CN
CP
CX
DT
ED
FT
MO
NM
PN
RP
SN
ST
TM
TN
TS
TX
XAD
XCN
XON
XPN
XTN

Description
Address
Coded Entry
Coded Element With Formatted Values
Composite ID With Check Digit
Composite ID And Name
Composite Price
Extended Composite ID With Check Digit
Date
Encapsulated Data
Formatted Text (Display)
Money
Numeric
Person Name
Reference Pointer
Structured Numeric
String Data.
Time
Telephone NumberTime Stamp (Date & Time)
Text Data (Display)
Extended Address
Extended Composite Name And Number For Persons
Extended Composite Name And Number For Organizations
Extended Person Number
Extended Telecommunications Number

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

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

定義： 検査項目を表す一意な識別子。例：5F190143002315151^HSV-1抗原。日本臨床病理学
会臨床検査項目分類コード体系に則りコーディングされた検査項目コードを使用(結果識別も含む)。検査結果コメントをセットする場合検査項目IDを接尾辞で修飾したコードを用いる。
検査結果コメントの扱いを参照。
大半のシステムでは、識別子は受信システムが検査情報を処理するために、他の検査属性を列記した検査項目マスタテーブルを参照するために使用される。検査IDと検査項目マスターテーブルとの関係は、請求記録中の課金コードと課金マスターテーブルの関係に類似している。
(マスターテーブルの更新方法についてはHL7 V2.3では第8章に記載されているが、日本での使用については今後の検討課題である。)
このフィールドの第1識別子にローカルコードを使用する場合、普遍的な識別子もあわせて送信することを強く推奨する。それにより、様々な提供者が同じサービスについてそれぞれ結果を送信してきた場合(たとえば病院検査室と検査センターが老人ホームに生化学データを報告
してきた場合)、受信側でそれらの結果を同じにすることができる。使用できる 普遍的な識別子には、国内においては前述の日本臨床病理学会のコードがあり、米国においてはLOINC
コードがあり検体検査結果と生理的変数(たとえば血圧、脈拍)が包含されている。(LOINCについては http:// www. mcis. duke. edu/ standards/ termcode/ loinc.htmを参照のこと) 神経生理学
検査に関しては、｢波形結果データ型｣およびASTM E1467の附属書X2を参照すること。
OBX-4 Observation sub-ID 検査サブID (ST) 00572
定義： 1つのOBRの下で編成された複数のOBXセグメントが同じ検査項目IDを持つ場合、それぞれのOBXセグメントを識別するのに使う。たとえば、胸部X線レポートには独立した3つの診断が含まれることがある。標準では、3つのOBXセグメント(1つの診断所見に1つのOBX
セグメント)が必要である。これらのOBXセグメントの1番目のサブIDに1、2番目のサブIDに2、および3番目のサブIDに3を入れることにより、HL7は、編集あるいは交換に際し各OBXセグメ
ントを一意に識別することができる。
サブ識別子は、外科病理学などのレポートで関連成分をグループ化するのにも使われる。外科
病理学レポートでは、1回の手術により得られた組織をすべて1つのレポートにまとめるということは昔からよくある。胆嚢および虫垂の検査を記述した単一の外科病理学レポートを考えてみる。このレポートは概ね図7−10に示すように転送されるだろう。

Copyright©1998 JAHIS V1.0

65

JHLDEX10.DOC 00/09/21

図 7-10.

Example of sub-identifier usage

OBR|1|||88304&SURG PATH REPORT...
OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM...
OBX|2|TX|88304&GDT|1|THIS IS A NORMAL GALLBLADDER...
OBX|3|TX|88304&MDT|1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLYNORMAL GALLBLADDER TISSUE...
OBX|4|CE|88364&IMP|1|M-00100^NML^SNM...
OBX|5|CE|88304&ANT|2|T66000^APPENDIX^SNM...
OBX|6|TX|88304&GDT|2|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX...
OBX|7|TX|88304&MDT|2|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORYCHANGE...
OBX|8|CE|88304&IMP|2|M-40000^INFLAMMATION NOS^SNM...

図7-10の例では、レポートの各成分に対して2つのセグメントがある(2つある組織のそれぞれに対して1つのセグメント)。このように、88304&ANTセグメントが2個存在する；88304&GDT
セグメントが2個存在する。88304&MDTセグメントが2個存在する。胆嚢に適用されるセグメ
ントはすべてサブ識別子として1を持つ。虫垂に適用されるセグメントはすべてサブ識別子｢2｣を持つ。
検査サブIDはその他の目的でグループ化する場合にも使用できる。それはいくつかの種類の体液摂取及び排泄のレポートを編成するのに使用することができる。たとえば、複数の静脈より採血を実施した場合、それぞれ、多くの個別の検査(OBXセグメント)、採取量、採取の型(血液、D5W、血漿など)、静脈の部位などが必要になる。つまりそれぞれの部位ごとに個別のOBX
セグメントを必要とする。複数の静脈部位による場合、HL7では、第1の静脈部位に関係する
OBXセグメントすべてに検査サブID｢1｣を割り当てることにより、それらのOBXセグメントを
論理上リンクすることができる。同様に、サブID2を割り当てることにより、第2の静脈部位に関して、すべてのOBXをリンクすることができる。複数の外科的ドレインが存在する場合に、その排泄に対しても同様のことができる。複数指定する必要がない場合、nullか1を使用すること。
OBX-5 Observation value 検査結果値 (*) 00573
定義： 検査実施者により検査された検査結果値。検査結果値はこのセグメント中のOBX−2−値型で設定されるデータ型に応じて表記される。このフィールドはOBXセグメントの必須
フィールドである。数値なのかあるいは短いテキストなのかどうかに拘らず、回答はASCII文字コードで記録されるものとする。
数値型の検査結果であっても比較演算子や接尾辞を持つ場合、値型が文字列STの場合と構造化数値SNの場合によって、検査結果値の表記が異なるので注意、例えば、ST型では100以上( >100 )や 2+であるが、SN型では >^100 や ^2^+ となる。可能な限りSN型を使用することを推奨する。
論理上独立している検査の報告
放射線検査や｢病歴・身体計測｣などの叙述的レポートの主要箇所は、個別のOBXセグメントとして報告される。また、論理上独立している個々の検査は、個別のOBXセグメントで報告すべきである；つまり、1個のOBXセグメントには、論理上独立している複数検査の 結果を含んではならない。この要求事項により、OBX−6−単位およびOBX−8−異常フラグ、およびOBX−9−確率の内容が明白に解釈ができるようになる。たとえば電解質およびバイタル
サイン・セットは、4つの個別のOBXセグメントとして報告されるだろう。2つの診断(うっ血性心不全と肺炎など)は、それが退院サマリの一部として報告されたのかあるいは胸部X線レ
ポートの一部として報告されたのかに拘らず、さらに2つの個別のOBXセグメントとして報告されるだろう。同様に、単一の細菌培養内で分離された2つの細菌性生物は、2つの個別のOBX
セグメントとして報告されるだろう。
1つのOBXセグメントで、独立した2つの診断 記述文 を報告することはできないが、2つの診断 記述文 がそれぞれ一部(修飾子)として一緒になって1つの診断記述文を構築するのであれば、定性値として複数回応答することができる(通常、反復区切り文字により分離されたCEデータ型として)。たとえば、右上葉(1つのコードとして記録される)と肺炎(別のコードとして記録される)の両方を1つのOBXセグメントで報告できるだろう。そのような複数の 値
は反復区切り文字により分離されるだろう。
共通の検査IDとサブIDを持つ複数のOBXセグメント

Copyright©1998 JAHIS V1.0

66

JHLDEX10.DOC 00/09/21

いくつかのシステムでは、単一の検査に複数データ型の 一部 が含まれることがある。よくある例は、数値結果の後にコード化注記(CE)が続くことである。この場合、論理検査情報は複数のOBXセグメントで送ることができる。たとえば、あるセグメントは、数値結果を表すための数値データ型あるいは文字列データ型であるが、もう1つのセグメントはコード化注記を表すCEデータ型である場合など。実施者が複数のコード化注記を報告しているとすると、その複数のコード化注記はすべて単一の論理検査情報を修正してしまうので、反復区切り文字で分離された1つのOBXセグメントで送信されるだろう。同じ検査IDとサブIDを持つ複数のOBX
セグメントは、最も重要なOBXセグメント(正常なフラグ/単位、および/あるいは、基準値および状態フラグを持つOBXセグメント)を最初に指定して、常に連続して送信すべきである。
OBX6〜12の値は、同じOBX−3−検査項目とOBX−4−検査サブIDを持つ後続のOBXセグメ
ントではnullとすべきである。置換または削除をする場合、同じ検査IDとサブIDを持つ複数の
OBXセグメントは1単位として扱われる。どれか1つが置換または削除されると、すべてが置
換される。
コード化値
OBXセグメントにCEデータ型の値が含まれる場合、検査はコードおよび(または)テキストの組み合わせとして保管される。(｢OBR 1｣の1番目と2番目のOBXセグメント、｢OBR 2｣の1番目と2番目のOBXセグメントに記述されている結果。)検査は、(推奨検査を表す)検査セット
ID、(診断を表す)診断コードか所見、または病理学レポートで使う部位、あるいは他の任意の種類のコード化結果などである。
コード化検査に保管された情報は必ずしもコード化する必要はない。たとえば、胸部X線診断がCEデータ型であったとしても、純粋テキストとして転送することができるだろう。この場
合は、たとえば以下のように記述して、 結果コード の第2成分としてテストを記録しなけ
ればならない。
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE.
しかし、個別の診断、指導などは、純粋テキストとして記録するとしても、個別の結果セグメントに記録すべきである。すなわち、うっ血性心不全と肺炎は、
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE AND PNEUMONIA|
ように送信するのでなく、以下のように送信すること。
OBX|1|CE|71020&IMP|1|^CONGESTIVE HEART FAILURE|
OBX|2|CE|71020&IMP|2|^PNEUMONIA|.
テキスト記述(成分2)の代わりに、あるいはテキスト記述(成分2)に加えて、コンピューターが理解し得るコードを含む完全コード化結果(成分1)を送信すればさらによい。
OBX-6 Units 単位 (CE) 00574
定義： 単位のデータ型はCEデータ型である。国内の臨床検査においては、現在普遍的な単位コード体系が定められていないので、検査結果に単位が付属する場合、必須フィールドとし、次のような成分で記載するものとする。
< 単位(ASCII)(ST) > ^ < 単位名称(漢字可)(ST) > ^ < コード体系名(L)(ST) >識別子成分またテキスト成分のいずれかは省略可能とする。
OBX-7 References range 基準値範囲 (ST) 00575
Components: 数値型データの場合の書式は次のようである:a) lower limit-upper limit(when both lower and upper limits are defined, e.g.,
for potassium 3.5 - 4.5)b) > lower limit(if no upper limit, e.g., >10)c) < upper limit(if no lower limit, e.g., <15)
文字型データの場合: 正常値をこのフィールドに記載する。
定義： 検査で有毒物質の量を計測する場合、範囲の上限により毒性限界を表す。検査で薬剤の量を計測する場合、下限により治療の期待できる最小量を表し、上限によりそれ以上の薬剤投与により通常副作用が発生し得ることを表す。
OBX-8 Abnormal flags 異常フラグ (ID) 00576
定義： 結果の正常状態を示すテーブルルックアップ。適用できる場合は、この値を送ることを強く推奨する。検査が抗生物質感受性の場合、解釈コードは次のとおりである： S＝敏感；
R＝耐性；I＝中間；MS＝少し敏感；VS＝過敏。(詳細については、ASTM 1238−調査−を参照)。採りうる値については、テーブル0078−異常フラグ−を参照。

Copyright©1998 JAHIS V1.0

67

JHLDEX10.DOC 00/09/21

検査室で、胸部X線あるいは微生物培養などのテキスト・レポートの正常状態を識別できる場
合、正常な場合はN、異常な場合はAとして報告すべきである。複数のコード(たとえば異常と悪化)を報告する場合は、反復区切り文字(たとえばA〜W)により分離されるだろう。
テーブル 0078
Value
space
L
H
LL
HH
<
>
N
A
AA
null
U
D
B
W
S
R
I
MS
VS

Abnormal flags 異常フラグ

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

Nature of abnormal testing 異常検査の特質

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

一般正常範囲OBX-11 Observ result status 検査結果状態 (ID) 00579
定義： 採りうるコードについては、テーブル0085−検査結果状態−を参照。このフィールドは、1つの検査項目についての、現在の結果完了状態を反映する
テーブル 0085 - Observation result status codes interpretation 検査結果状態
Value
C
D
F
I
P
R
S
X
U

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 臨床検査室の検体；結果保留
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. 結果状態を最終へ変更。結
果は変化しなかった(テストを転送しない) たとえば、放射線科により状態が事前から最終へ変更される

OBX-12 Effective date last obs normal value 最新正常値有効日付 (TS) 00580
定義： 測定方法の変更により、旧方式で得られた値が新規方式で得られた値と比較できなくなる場合、そのような測定方法の変更などを表す。

Copyright©1998 JAHIS V1.0

68

JHLDEX10.DOC 00/09/21

正常値または単位がない場合null。存在する場合、記録日付と対応するこの日付の変更。新規
結果と旧結果を区別するためにローカルシステムで新規検査項目IDに現IDを割り当てるべきかどうかを判断できるよう、受信システムは、結果をマニュアルで見直すようトリガーをかけるべきである
OBX-13 User defined access checks 使用者定義アクセス点検 (ST) 00581
定義： これにより実施者は、受信システムで検査を分類するのに使用する結果依存コードを記録できるようになる。
ほとんどの分類は固定の検査ID属性であり、関連検査マスタファイルで定義することができるので、このフィールドはめったに必要とされない。
しかし、受信システムが計算のやり直しを望まない場合がまれにあり、この場合そのような制御の仕方も検査結果値により変わることがある。たとえば抗酸菌感受性結果の場合である。生物、検体採取部位、あるいは患者アレルギー状態に応じて、安価な抗生物質の感受性結果だけ表示したいと思う望むシステムもあるだろう。送信部門側では、特権ユーザ(たとえば感染症の専門医)はすべての結果を閲覧し、非特権ユーザは生物が反応した(敏感だった) 所望の 抗生物質だけを閲覧できるよう、すべての感受性を送信したいと思う。HL7では、その他のケースも生じると想定している。
OBX-14 Date-time of the observation 検査日時 (TS) 00582
定義： 次の2つの状態で必要になる。まず、1つのレポートーヘッダー(OBR)の下で報告された複数の検査が互いに異なる日付を持つ場合である。これが起こりえるのは、同じセットのある測定と別の測定が異なる時間を持つ可能性がある、照会、負荷試験・シーケンス、あるいは
クリアランス検査の場合である。
次に、OBXセグメントを依頼者から実施者へ送る場合にも検査日時は必要である。この場合には、転送中の検査の日付は要求検査の日付とは何の関係もないだろう。フランスでは慣例として、要求側部門が、新規セットの検査要求に加えて、1セットの最終検査結果を送る。これ
らの検査の日付は実施者検査室にとって重要である。
どのような場合でも、検査日時は生理学的日時あるいは生理学的日時に最も近い日時である。
検体に対して行われるテストの場合は、該当日時は検体採集日時である。患者に対して直接行われる測定(たとえばX線画像、病歴、身体測定)の場合には、検査日時は測定が行われた日時である。
OBX-15 Producer's ID 実施者ID (CE) 00583
定義： 検査実施責任者の一意な識別子。たとえば検査結果が外部検査室により提供される場
合、実施者IDを明示的に報告すべきである。このフィールドがnullの場合、受信システム側は、送信施設が検査を実施したと仮定する。この情報が必要なのは、米国のCLIA規格を満たすためである。外注先検査センターをセットする。
OBX-16 Responsible observer 検査責任者 (XCN) 00584
定義： 要求された場合、検査に直接責任を負う個人(つまり検査を実行、もしくは検証した
人)の識別子。看護部門では、検査実施者は通常、検査(血圧測定)を実行した専門家である。検査室では、検査実施者は解析を実行・検証した医療技術者である。検査実施者を表すコードは
CEデータ型として記録される。ローカル・コードとしてコードを送る場合、OBX−15−実施
者IDと組み合わせた時に、一意にして明白でなければならない。
OBX-17 Observation method 検査方法 (CE) 00936
定義：検査項目案内などで公表している検査方法と異なる検査方法を実施した場合などはここに明示する。
OBX-18 Template indicator テンプレート識別 (CE)
定義：このOBXセグメントが、検査オーダー詳細OBR-4検査項目群の内容を定義するためのものか、検査結果か、両者をかねるものかを示す。とりうる値は、C-検査結果、D-検査項目定義、B-両者である。Dの場合は必須フィールドであるOBX-5やOBX-11はヌルでよい。この場合
OBX-2もヌルの場合が想定されるので注意。ここで定義されるOBR-4検査項目群の検査項目の組み合わせは直前のOBRに対してのみ有効であり、同一の定義であっても以降のOBRに対してはあらためてOBXを必要とする。

Copyright©1998 JAHIS V1.0

69

JHLDEX10.DOC 00/09/21

7. 医療情報交換規約運用指針

MERIT-9 での扱い

MERIT-9: Medical Record Image Text - Information Exchange

7.1 MML(Medical Mark-up Language)での臨床検査結果記述での臨床検査結果記述
医療情報交換規約運用指針MERIT-9(Medical Record Image Text - Information Exchange)では、SGMLに準拠
したMML(Medical Mark-up Language)を用いて記述されたカルテ情報や、すでに標準的規約の検討が進んでいる放射線画像や臨床検査を包括的に取り扱うものである。この中で、臨床検査結果はMML規約の
CLINICAL-ENCOUNTER-SECTION中のOBJECTIVE-SECTIONにおいて、外部ファイル参照として定義される。参照されるファイルはJAHIS臨床検査データ交換規約検査結果報告に準拠し、HL7 Ver2.3のORUメッセージでコーディングする。
MMLによる臨床検査結果の記述
TEST-RESULT TYPE=“LABORATORY”
MREF
CONTENT-TYPE=“APPLICATION/HL72.3-HL7ER2.3”
EXAM-DATE=“yyyymmdd”
REF=“ url (file://path name/file name.HL7) ”
上記のアトリビュートはすべて必須である。EXAM-DATEには検査日や検体採取日を記述しこれは検査
結果ファイル中の代表されるOBR-7と同値であること。REFには参照先ファイル名をURL標記で記述する。
ファイル名は互換性を考慮し英字で始まる英数字8文字以内とすることを推奨する。拡張子はHL7とする。

7.2 MERIT-9 MML

臨床検査結果

記述例< CPR-MML >< MML-INFORMATION-SECTION > ..... < /MML-INFORMATION-SECTION >< PATIENT-ID-SECTION > ..... < /PATIENT-ID-SECTION >< CLINICAL-ENCOUNTER-SECTION > .....
< OBJECTIVE-SECTION > .....
< TEST-RESULT TYPE=“LABORATRY” >< MREF CONTENT-TYPE=“APPLICATION/HL72.3-HL7ER2.3” EXAM-DATE=“19970523”
REF=“file://pid001/oal001.hl7” >------------------- HL7 ORU Message< MREF CONTENT-TYPE=“APPLICATION/HL72.3-HL7ER2.3” EXAM-DATE=“19970523”
REF=“file://pid001/oal002.hl7” >------------------- HL7 ORU Message< /TEST-RESULT >.....
< /OBJECTIVE-SECTION >.....
< PLAN-SECTION > .....
< TEST-ORDER ..... > ..... < /TEST-ORDER >.....
< /PLAN-SECTION >.....
< /CLINICAL-ENCOUNTER-SECTION >.....
< /CPR-MML >注： MML/MERIT-9の詳細については http://www.h.u-tokyo.ac.jp/mml/を参照のこと

Copyright©1998 JAHIS V1.0

70

JHLDEX10.DOC 00/09/21